Warning: Table './devblogsdb/cache_page' is marked as crashed and last (automatic?) repair failed query: SELECT data, created, headers, expire, serialized FROM cache_page WHERE cid = 'http://www.softdevblogs.com/?q=aggregator/categories/5&page=2' in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc on line 135

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 729

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 730

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 731

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 732
Software Development Blogs: Programming, Software Testing, Agile, Project Management
Skip to content

Software Development Blogs: Programming, Software Testing, Agile Project Management

Methods & Tools

Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!

Process Management
warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/common.inc on line 153.

SPaMCAST 392 – Mix Tape 2009, Lister, Chemuturi, Brennan

SPaMCAST Logo

www.spamcast.net

Listen Now

Subscribe on iTunes

I am still traveling for the next two weeks. The trip is a mixture of vacation and a board meeting but that does not mean you will have to forego your weekly SPaMCAST.  In place of our normal format, I am posting a mix tape of the answers to the “If you could change two things” question I have been asking interviewees for nearly ten years.  This week on SPaMCAST 392 we feature our top downloaded podcasts from the year 2009:

SPaMCAST 51 – Tim Lister on Adrenaline Junkies and Template Zombies

http://bit.ly/1WERtk5

Tim discussed ending the estimating charade.  Tim stated it would be better if we recognized estimating as goal setting. Secondly, he noted that a lot of outsourcing has overshot its mark and reduced our organizational capabilities.

SPaMCAST 67 – Murali Chemuturi on Software Estimation Best Practices, Tools & Techniques

http://bit.ly/1MHDzeJ

Murali used his wishes to state that estimators need a better grasp and understanding the concepts of productivity and scheduling.

SPaMCAST 69 – Kevin Brennan on Business Analysis

http://bit.ly/1WERB2V

Kevin answered a different question and discussed the message he would share with a C-Level executive to describe why business analysis is important to them.

If you enjoyed the snippets please use the links to listen to the whole interviews.  Next week 2010!


Categories: Process Management

SPaMCAST 392 – Mix Tape 2009, Lister, Chemuturi, Brennan

Software Process and Measurement Cast - Sun, 05/01/2016 - 22:00

I am still traveling for the next two weeks. The trip is a mixture of vacation and a board meeting but that does not mean you will have to forego your weekly SPaMCAST.  In place of our normal format, I am posting a mix tape of the answers to the “If you could change two things” question I have been asking interviewees for nearly ten years.  This week on SPaMCAST 392 we feature our top downloaded podcasts from the year 2009:

SPaMCAST 51 - Tim Lister on Adrenaline Junkies and Template Zombies

http://bit.ly/1WERtk5

Tim discussed ending the estimating charade.  Tim stated it would be better if we recognized estimating as goal setting. Secondly, he noted that a lot of outsourcing has overshot its mark and reduced our organizational capabilities.

SPaMCAST 67 - Murali Chemuturi on Software Estimation Best Practices, Tools & Techniques

http://bit.ly/1MHDzeJ

Murali used his wishes to state that estimators need a better grasp and understanding the concepts of productivity and scheduling.

SPaMCAST 69 - Kevin Brennan on Business Analysis

http://bit.ly/1WERB2V

Kevin answered a different question and discussed the message he would share with a C-Level executive to describe why business analysis is important to them.

If you enjoyed the snippets please use the links to listen to the whole interviews.  Next week 2010! 

Categories: Process Management

Attributes Of An Agile Coach

A coach is much like a honey bee...

A coach is much like a honey bee…

I strongly believe that coaches are not managers or Scrum Masters.  Coaches are a unique mixture of attributes, including being a listener, a learner, a mediator and an evangelist. A deficit in any these attributes will reduce a coach’s effectiveness.

A good coach is a listener.  A coach listens by making a conscious effort to hear not only the words that the other person is saying but, more importantly, trying to understand the complete message being sent. A coach listens to obtain information, to understand and to learn.

A good coach is a learner.  There are two related reasons that being a learner is important.  Agile is continually evolving, therefore the value of what you know now will erode quickly. Secondly, a coach is much like a honey bee, transferring ideas and techniques from one project or organization to another. A coach must actively seek out and learn new techniques and concepts to pollinate new teams and organizations. Without the ability to continually learn, the utility a coach can provide will also erode.

A good coach is a mediator. Conflict that leads to decisions is part and parcel of team life.  Sometimes these decisions and interactions are hard.  A coach plays the role of a mediator who facilitates negotiation to help team members reach a mutually satisfactory solution to their problems, without compulsion. Coaches that can’t mediate tend to revert to management compulsion, which will not only reduce the effectiveness of the coach, but may also injure the team.

 A good coach has to be an evangelist. Lean and Agile focus on only doing the work that delivers business value. Helping a team or an organization embrace Agile techniques effectively means personally embracing and helping the organization embrace the underlying philosophy of Agile.  A coach needs believe in the philosophy so that they can champion and shepherd the journey along the “new way.”  Not being willing to evangelize for the underlying philosophies of Agile will lead to crappy Agile.

Each of the attributes of a good coach – listening, learning, mediation and evangelism – are all required.  Deficits in any will hurt the coaches ability to coach and will reduce the effectiveness of the team.  The attributes that good coaches acquire and foster will increase the ability of teams and organizations ability to deliver value.


Categories: Process Management

The Product Samurai Strategy Canvas

Xebia Blog - Fri, 04/29/2016 - 16:00
"May you live in interesting times" said Feng Menglong in 1627, and it's never been a more fitting expression than today. With companies leapfrogging in the age of disruption to change the way they work and the business models that they use. Scrum has brought us autonomous hyper productive teams that can quadruple your output,

Agile Coach or Scrum Master

OLYMPUS DIGITAL CAMERAWhat’s the difference between an Agile coach and a scrum master? A quick internet search returns a variety of competing opinions (and a lot of ads for training classes).  This is not an arbitrary question – these terms have a great deal of power to set expectations for behavior. While some of the components of the roles are similar, the two roles are different in at least one major way –  scope.

Both Agile coaches and scrum masters help teams.  Both roles are tasked with helping Agile teams use Agile values and practices to deliver value to the organization.  Agile coaches and scrum masters use similar techniques to guide, facilitate, and coach teams so that they learn and use Agile techniques, confront delivery problems as they occur, and work together as a well-oiled unit.  If we stopped here the two roles would be the same. However, the scope of the two roles is different.

Agile coaches typically pursue the implementation of an organizational vision of Agile, or are tasked with delivering external knowledge and expertise to a team.  In both cases the coach is external and is not a member any specific project team. In order to effect change from the outside the project, the coach needs a broader exposure to Agile roles than a typical scrum master.  A coach should have played all of roles on an Agile team multiple times. They have the gravitas to influence without direct authority and from outside the team. They interact with a team or teams, and then let the team synthesize and internalize the advice. The Agile coach is typically the voice of Agile at an organizational level.  This generally requires broader exposure and experience with Agile techniques, which is why many organizations use external consultants to play this role. The need for an Agile coach is generally transitory, specifically they are needed when external injections of knowledge or energy is necessary to help ensure the application of Agile continues to evolve.

On the other hand, the scrum master is the team’s tactical coach (scrum defines the team as the scrum master, product owner and the development team). He/she facilitates the team’s use of Agile techniques and helps to protect the team from the outside world. Scrum masters are the voice of the process at the team level.  Scrum masters are a critical member of every Agile team. The team’s need for a scrum master is not transitory because they evolve together as a team.

The role of an Agile coach and that of scrum master have similarities, but also significant differences.


Categories: Process Management

Coach or Manager?

20130520-220059.jpg

Are you a coach or a manager? Most traditional, hierarchical IT organizations use managers to plan, organize and control work. Managers make decisions with greater or lesser collaboration, based on their management style. A coach is a different thing entirely. Coaches exist to assist a team to reach its full potential. In the world of empowered employees and self-managed teams, a coach is an enabler, a guide, and a leader.

A coach enables her team by suggesting areas for self-improvement, ideas for using tools and techniques and facilities improving team. The goal of coaching is to help the team become more effective in delivering value to the organization. The act of coaching requires the ability to interact and facilitate both how individuals and groups work within the team.

When a coach provides guidance, they are using their gravitas to influence the direction of the team. In organizations that rely on control environments, the manager will tell the team the correct direction with the expectation that telling and doing are sequential acts. A coach provides direction and uses her influence to get the team to internalize that direction. The internalized direction may well reflect a synthesis of the team’s knowledge and the coach’s advice.

The ability to enable and guide is a function of being a leader. Kevin Kruse, author of Employee Engagement 2.0, defines leadership as “a process of social influence, which maximizes the efforts of others, towards the achievement of a goal.” The definition does not include the primary tenants of the definition of a manager, control and positional authority, but rather is focused on getting the most from the team through influence.

A coach is a guide and a leader. These attributes are inter-related and self-reinforcing. A coach rarely needs to leverage the techniques of a manager – planning, organizing and directing – rather they rely on influence and team peer-pressure. Are you a manager or a coach? The distinction is stark. Is your role to help the team maximize its value through a process of facilitation? If the answer is yes, then you are a coach.


Categories: Process Management

Software Development Conferences Forecast April 2016

From the Editor of Methods & Tools - Tue, 04/26/2016 - 10:09
Here is a list of software development related conferences and events on Agile project management ( Scrum, Lean, Kanban), software testing and software quality, software architecture, programming (Java, .NET, JavaScript, Ruby, Python, PHP), DevOps and databases (NoSQL, MySQL, etc.) that will take place in the coming weeks and that have media partnerships with the Methods […]

Solving Agile portfolio planning for Lawns 'R' Us

Xebia Blog - Mon, 04/25/2016 - 09:28
Agile portfolio planning is a great (chief) product owner tool to plan and trace initiatives across various teams. Implementing it can be difficult and cumbersome at times. This post explores the number one critical success factor to do Agile portfolio planning right; Outcome oriented decision making. Outcome goals are valuable for streamlining your Agile portfolio

SPaMCAST 391 – Mix Tape 2007 – 2008, McKnight, Iwanicki, Goldsmith

SPaMCAST Logo

http://www.spamcast.net

Listen Now

Subscribe on iTunes

The first full Software Process and Measurement Cast posted on January 29th, 2007.  When the first cast posted we were on an every other week schedule whereas today we post weekly.  Over the next few weeks, I will be traveling.  The trip is a mixture of vacation and a board meeting but that does not mean you will have to forego your weekly SPaMCAST.  In place of our normal format, I will post a mixtape of the answers to the “If you could change two things” question I have been asking interviewees for nearly ten years.

SPaMCAST 391 will feature our top downloaded podcasts from the years of 2007 and 2008:

SPaMCAST 2 – Will McKnight on Process and Product Quality Assurance

Will used his wishes to talk about the need for an organizational process focus and the guidance to sustain process improvement.

SPaMCAST 4 – Stasia Iwanicki on Six Sigma

Stasia used her first wish to address requirements capture, development, and management.  Her second wish was for better measurement for supporting the software development process.

SPaMCAST 49 – Robin Goldsmith on Requirements

Robin used his wishes to discuss the need to capture and validate the real business requirements which lead to better systems.

If you enjoyed the snippets please use the links to listen to the whole interviews.  Next week 2009!


Categories: Process Management

SPaMCAST 391 – Mix Tape 2007 – 2008, McKnight, Iwanicki, Goldsmith

Software Process and Measurement Cast - Sun, 04/24/2016 - 22:00

The first full Software Process and Measurement Cast posted on January 29th, 2007. When the first cast posted we were on an every other week schedule whereas today we post weekly. Over the next few weeks, I will be traveling. The trip is a mixture of vacation and a board meeting but that does not mean you will have to forego your weekly SPaMCAST. In place of our normal format, I will post a mixtape of the answers to the “If you could change two things” question I have been asking interviewees for nearly ten years.

SPaMCAST 391 will feature our top downloaded podcasts from the years of 2007 and 2008:

SPaMCAST 2 – Will McKnight on Process and Product Quality Assurance

http://bit.ly/1VBujvS

Will used his wishes to talk about the need for an organizational process focus and the guidance to sustain process improvement.

SPaMCAST 4 - Stasia Iwanicki on Six Sigma

http://bit.ly/1WdJnOP

Stasia used her first wish to address requirements capture, development, and management. Her second wish was for better measurement for supporting the software development process.

SPaMCAST 49 – Robin Goldsmith on Requirements

http://bit.ly/23ZC9Av

Robin used his wishes to discuss the need to capture and validate the real business requirements which lead to better systems.

If you enjoyed the snippets please use the links to listen to the whole interviews. Next week 2009!

Categories: Process Management

Stand Up Meetings

Preparing for a Daily Stand Up

Preparing for a Daily Stand Up

**The Re-Read of Commitment: A Novel About Managing Project Risk will resume when I get back from vacation in May. In the meantime, please enjoy this rerun.**

__

The daily stand-up meeting is the easiest Agile practice to adopt and the easiest to get wrong.  In order to get it right, we need to understand the basic process and the most common variants. These include interacting with task lists/boards and distributed team members. The basic process is blindingly simple.

  • The team gathers on a daily basis.
  • Each team member answers three basic questions:
    • What tasks did I complete since the last meeting;
    • What tasks do I intend to complete before the next meeting, and
    • What are the issues blocking my progress.
  • The meeting ends, team members return to work OR discuss other items.

This is the barest bones version of a stand-up meeting.  The meeting is typically attended by the whole team; which includes the scrum master/coach, the product owner and all other team members.  Arguably while the product owner is not a required participant based on the published Scrum guidelines, their central role makes them an important contributor to the meeting when questions about direction come up. I advise team members to discuss whether the product owner will participate (highly recommended) when they develop the Agile team charter and add participation to the team norms.

The most common process addition is the inclusion of a task list/board, either as a physical list often found on the wall of a team room or virtually through the use of a software tool. The team will use the board to guide the discussion.  The tasks they talk about should be on the wall or in the tool.  Sometimes teams adopt a rule that the team members do not work on items not on the wall (or tool). The task list focuses the team and provides visual feedback as tasks change status.

  • You will need to add the following steps to the process when using a list or board:
  • Ensure that all participants can see and interact with the list during the stand-up and throughout the day.
  • Update the board or tool in as close to real time as possible.

Lists and boards can get out of sync with reality.  Out-of-sync tools deliver bad information and can lead to work failing through the cracks.  When tools or task list are used they must be kept up to-date. Each team member must keep his or her tasks up-to-date.  This is not the scrum master/coaches role; they are not project administrators.

Distributed Teams

Distributed teams, teams where one or more team members are in a different location, present several challenges, including time zones, accents, organization affiliation and sometimes language. In general, the stand-up meeting should be basically the same, regardless of the participant’s location. Typically, what does change are the tools needed to make the meeting effective. Videoconference or good teleconference equipment is an absolute must, as is access to the task list (a virtual tool is useful).

You will need to add the following steps to the process when the team is distributed:

  • Ensure that everyone on the team can see and hear each other.  This typically means securing or scheduling video or teleconferencing facilities.
  • Ensure that all participants can see and interact with the list during the stand-up and throughout the day.
  • Update the board or tool in as close to real time as possible.

Techniques that are effective making daily stand-ups work for distributed teams include:

  • Deal with the time zone issue. There are two primary options to deal with time zones. The first is to keep the team members within three or four time zones of each other. Given typical sourcing options, this tends to be difficult. A second option is to rotate the time for the stand-up meeting from sprint to sprint so that everyone loses a similar amount of sleep (share the pain option). One usable solution that can be tried when distributed teams can’t overlap is to have one team member (rotate) staying late or coming in early to overlap work times.
  • Identify and attack blockers between stand-ups. Typically, on distributed teams, all parties will not work at the same time. Team members should be counseled to communicate blockers to the team as soon as they are discovered so that something discovered late in the day in one time zone does not affect the team in a different time zone that might just be starting to work. One group I worked with had stand-ups twice each day (at the beginning of the day and at the end of the day) to ensure continuous communication.
  • Push status outside the stand-up. A solution suggested by Matt Hauser is to have the team answer the classic three questions (What did you do yesterday? What will you do today? Is there anything blocking your progress?) on a WIKI for everyone on the team to read before the stand-up meeting. This helps focus the meeting on planning or dealing with issues.
  • Vary the question set being asked. The process of varying the question set keeps the team focused on communication rather than giving a memorized speech. This technique can be used for non-distributed teams as well as distributed teams. For example ask:
    • Is anyone stuck?
    • Does anyone need help?
    • What did not get competed yesterday?
    • Is there anything everyone should know?
  • Ensure that everyone is standing. This is code for making sure that everyone is paying attention and staying focused. Standing is just one technique for helping team members stay focused. Other tips include banning cell phones and side conversations.
  • Make sure the meeting stays “crisp.” Stand-up meetings by definition are short and to the point. The team needs to ensure that the meeting stays as disciplined as possible. All team members should show up on time and be prepared to discuss their role in the project. Discussion includes the willingness to ask for help and to provide help to team members.
  • Use a physical status wall. While the term “distributed” screams tool usage, using a physical wall helps to focus the team. The simplicity of a physical wall takes the complexity of tool usage off the table so the focus can be on communication. Use of a physical wall in a distributed environment will mean using video to moving tasks on the wall (after the fact a picture can be provided to the team). If video is not available, use a tool that EVERYONE has access to. Keep tools as simple as possible.
  • Don’t stop doing stand-ups. Stand-up meetings are a critical communication and planning event, not doing stand-ups for a distributed team is an indicator that the organization should go back to project manager/plan-based methods.
  • Like any other distributed team meeting, having good telecommunication/video tools is not only important, it is a prerequisite. If team members can’t hear each other, they CAN’T communicate.

The stand-up meeting is a simple meeting that Agile teams hold on a daily basis to plan and synchronize activities.  Adding lists and tools can make the meeting more effective by focusing team effort, BUT adding lists and tools means that the team needs to keep them up to date and use them!  If we add complications such as distributing the team, virtual tools become a necessity. I have had to ask more than one team what value they were getting from a stand-up if part of the team couldn’t hear and participate.


Categories: Process Management

Metrics:  5 Productivity Usage and Calculation Mistakes

The more complex the door, the lower the 'door' productivity.

The more complex the door, the lower the ‘door’ productivity – but not always.

While productivity is a simple calculation, there are a few mistakes organizations tend to make.  The five most common mistakes reduce the usefulness of measuring productivity, or worse can cause organizations to make poor decisions based on bad numbers.  The five most common usage and calculation mistakes are:

1.      Calculating productivity using inputs as outputs.  Productivity is the ratio of output created per unit of input.  For example, if a factory created widgets then labor productivity would be calculated as widgets per hour. A common software productivity metric is function points per person.  Inverting the equation would yield a metric of people per function point which make very little sense.  Solution: Repeat after me, productivity is output divided by input (a bit of snark).  Other metrics use an output as a driver to predict usage of resources.  For example, we calculate delivery rate (answers how fast the process delivers) by dividing calendar time by output.

2.      Using aggregate or average productivity for concrete planning. Productivity averages are often a useful tool for portfolio planning. Portfolio planning occurs when organizations know few of the details about a piece of work.  Solution: In software development and maintenance, never use an organization-level productivity number to set specific goals for a project, sprint or feature.    

3.      Labor productivity is a loose proxy measure for some types of change.  Not all process improvements have a direct impact on labor productivity.  For example, Total Factor Productivity (TFP) would be a better measure to assess the impact of the adoption of Scrum. While we may see the echoes of the of changes in labor or capital productivity, we would be ascribing the impact to the wrong factors which could lead us to try other changes that may not have positive impacts. Solution: Most software development and maintenance organizations will not spend the time and effort needed to measure TFP. Continue using labor or capital productivity to evaluate changes, but in addition evaluate how directly the productivity measures the change.  Understanding how closely the proxy tracks the changes will help the analyst judge the change or alert him or her to search for other impacts.  

4.      Productivity may only be loosely tied to delivered value. Productivity is a measure of raw, non-defective output, not whether that output useful or sellable.  If a software team delivers a product that does not hit the mark or is not adopted in the marketplace, they may have been highly efficient even though their output is less valuable than anticipated.  Solution: Measure both value and productivity to provide a complete view of performance.

5.      Comparing productivity across teams undervalues technical complexity. One piece of software is often significantly more or less complex than another.  Technical complexity often varies not only between applications but within sections of code inside applications.  The more complex the code or business problem, the lower the productivity (complexity increases the amount of effort needed to create an output).  Solution: Each application should evaluate and determine its own productivity based on measuring delivered results. When teams use productivity as a planning tool they should tune the anticipated performance based on the predicted level of technical and business complexity.

Faster, better, cheaper has been the mantra of many a CFO and CIO.  Understanding and improving productivity is one of the tools available to improve performance.  In order to effectively use productivity as a tool, we need to make sure we calculate it correctly and understand that the metric provides a single point of view.  Productivity is a measure  of how effectively an organization transforms inputs into outputs; no more, no less. Productivity metrics provide the most value when coupled with other metrics such as value, speed, and complexity to generate a holistic view of the value delivery chain. 


Categories: Process Management

Software Development Linkopedia April 2016

From the Editor of Methods & Tools - Wed, 04/20/2016 - 09:07
Here is our monthly selection of knowledge on programming, software testing and project management. This month you will find some interesting information and opinions about scaling Agile, Test-Driven Development, recruiting developers, managing technical debt, distributed teams, breaking the rules, test automation, Agile metrics and machine learning. Web site: Agile Scaling Knowledgebase Blog: What do you […]

Metrics: 5 Behaviors Caused By Improper Productivity Measurement

Kafka Statue

Are you measuring a team effort?

Productivity is used to evaluate how efficiently an organization converts inputs into outputs.  However, productivity measures can and often are misapplied for a variety of reasons ranging from simple misunderstanding to gaming the system. Many misapplications of productivity measurement cause organizational behavior problems both from leaders and employees.  Five of the most common productivity-related behavioral problems are:

  1. Attributing team efforts to individuals.  Most software development and maintenance activities are team efforts. Productivity measures usually reflect the output of the teams doing the work, and can’t be ascribed to an individual.  However, there is often a chronic need to ascribe team output, whether good and bad, to an individual.  For example, often productivity data is used in an individual’s review and evaluation. This can lead to everyone trying to game the metric.  The solution for this issue is just not to fall prey to using a team metric to measure an individual.     
  2. Measuring productivity can reduce productivity.  Measurement of productivity requires time and effort to count the inputs and outputs of a system. If an organization does not measure productivity they could either create more output with the effort they would have used to measure productivity or reduce payroll, in either case leading to an increasing productivity.  If the measurement of productivity is not directly tied to process improvement or cost avoidance it will have no return on investment. Avoid overhead that does not deliver significant ROI. The solution is to use productivity measures as part of process improvement or cost reduction program.
  3. Gold plating an output to increase productivity.  One of the most famous adages in management circles is that “you get what you measure.”  Holding teams or individuals accountable for productivity above all else will lead to pressure to add features even if not asked for in order to increase the development output.  This is often referred to as gold plating. Gold plating leads to delivering more functionality than needed often at the expense of needs that are higher value.  One fix I recommend is measuring productivity, value and customer satisfaction to ensure teams have more than a one-dimensional view of their performance. 
  4. Optimizing local processes without regard to the overall system. The focus of any system is to deliver the most value possible and to improve over time.  Maximizing the efficiency of a part of a system may not translate to the whole system becoming more efficient. For example, I recently observed a large organization with multiple software teams that efficiently developed software.  After developing and testing the software, the operations/implementation group performed a review and security testing prior to putting the implementation into production.  The operations team had a six-month backlog.  While waiting for review, two changes in the last month had to be withdrawn because the market need had changed before they ever made it to production. At the same time, a process improvement team was looking at ways to increase development productivity. Making the software development process any more efficient would only exacerbate the implementation group bottleneck.  In the end, the organization reallocated three development teams to support the implementation function in working through the backlog and streamlining the process.  As we identified when in our Re-read Saturday of The Goal, systems only increase output if you improve the throughput of the bottlenecks in the system.
  5. What doesn’t get measured gets overused?  Some organizations that focus on measuring productivity get very good at finding and utilizing resources that don’t influence the input side of the equation.  A classic issue is under-reporting of effort in time accounting.  For example, many organizations cap salaried employee’s time entry at 40 hours per week, even though they are often working 60 hours or more. The overtime is effectively hidden and because it considered free. Therefore, there is often little pressure to measure the overtime (until people start quitting).  Any resource that is considered free will be overused.

The last two behavioral issues are often the most common and can occur even when organizations don’t explicitly measure productivity. Every organization, whether they explicitly measure productivity or not, wants software development to deliver more functionality and cost less.  Organizations that don’t take a systems thinking view  can actually increase cost and reduce real productivity hurting the long term efficiency of the organization when they are trying to have the opposite impact. 


Categories: Process Management

Testing Promises with Mocha

Xebia Blog - Tue, 04/19/2016 - 21:03
If you test Javascript promises with Mocha, there are several styles you can use to write your tests. If you follow the Mocha docs on testing asynchronous code you risk writing 'evergreen' tests. Evergreen tests never fail, even if your code is broken. That is something you clearly do not want to happen. So what

Sprint Planning for Agile Teams That Have Lots of Interruptions

Mike Cohn's Blog - Tue, 04/19/2016 - 15:00

Many teams have at least a moderate ability to plan and control their time. They're able to say, "We will work on these things over the coming sprint," and have a somewhat reasonable expectation of that being the case.

And that's the type of team we encounter in much of the Scrum literature--the literature that says to plan a sprint and keep change out.

But what should teams do when change cannot be kept out of a sprint?

In this post, I want to address this topic for two different types of teams:

  • A team that has occasional, but not excessive, interruptions
  • A team that is highly interrupt-driven
Planning with a Moderate Margin of Safety

Many teams will benefit from including a moderate amount of safety into each sprint. Basically, these teams should not assume they can keep all changes out of the sprint. For example, a team might want to leave room when planning a sprint for things like:

  • Fixing critical operational issues, such as a server going down
  • Fixing high-severity bugs
  • Doing first- or second-level tech support

There could be many other similar examples. Consider your own environment. You want to try to set a high threshold for what constitutes a worthy interruption to a sprint. Teams really do best when they have large blocks of dedicated time that will not be interrupted.

To accommodate work like this, all a team needs to do is leave a bit of buffer when planning the sprint. Let’s see how that works.

The Three Things That Must Go into Each Sprint

I think of a sprint as containing three things: corporate overhead, and plannable and unplanned time. I think of this graphically as shown in Figure 1.

Figure 1:

Corporate overhead is that time that goes towards things like all-company meetings, answering emails from your past project, attending the HR sensitivity training and so on. Some of these activities may be necessary, but in many organizations, they consume a lot of time.

I put Scrum meetings (planning, daily scrum, etc.) in the corporate overhead category as well.

Plannable time is the second thing that goes into a sprint. This is the time that belongs collectively to the team.

But the team does not want to fill the entire remainder of the sprint with plannable time. The team needs to acknowledge the need to leave room for some amount of unplanned time.

Unplanned time goes towards three things:

  • Emergencies
  • Tasks that will get bigger than the team thinks
  • Tasks that no one thinks of during the sprint planning meeting
The Appropriate Percentages

I’m frequently asked what percentages teams should use for each of the three categories. I can’t answer that. But I can tell you how to figure it out:

After each sprint, consider how well the unplanned time the team allocated matched the unplanned time the team needed for the sprint. And then adjust up or down a bit for the next sprint. This is not something a team can ever get perfect.

Instead, it’s a game of averages. The team needs to save the right amount of time for unplanned tasks on average. Then some sprints will have more unplanned tasks occur and some sprints will have fewer.

When fewer occur, the team should get ahead on their work. so they’re prepared for when more unplanned tasks occur.

What to Do When a Team Is Highly Interrupt-Driven

The preceding advice works well for the majority of agile teams--those that are only interrupted a moderate amount. Some teams, however, are highly interrupt-driven.

Again, I want to resist putting actual percentages on the regions in Figure 1, but I’m describing a situation in which the area of “unplanned time” becomes much larger than shown.

I actually want to talk about the cases in which unplanned time becomes the dominant of the three areas. Such teams are highly interrupt-driven.

These teams still want to include space in their sprints for unplanned time. But there are usually a few other things you may want to consider if you are on a highly interrupt-driven team.

First, you may want to adjust your sprint length. One option is to go with a long sprint length. Increasing sprint length has the benefit of making the rate of interruption more predictable because the variance will not be so great from sprint to sprint.

To see how that works, imagine you chose a one-year sprint. (Don’t do that!) It’s easy to imagine with such long sprints, the fluctuations a team faces with short sprints will wash out. Sure, this year (this sprint) might have more interruptions than last year (last sprint), but it’s such a long period that the team has time to recover from any excessive fluctuations.

The other option is to go with short, one-week sprints and just live with the unpredictability. The team will be less able to assure bosses “we will be done with this” by a given period, but I find that to be a worthwhile tradeoff.

Second, a highly interrupt-driven team should make sprint planning a very lightweight activity.

Sprint planning should be a quick effort to grab a few things the team thinks it can do in the coming week, and that’s that. It should be a very minimal effort--15 or 30 minutes for many teams.

To illustrate this, think about planning a party, and imagine a spectrum with planning a wedding reception on one end. That’s some serious party planning. At the other end of the spectrum is inviting some friends over tonight to watch the big game on TV. To plan that, I’m going to check the fridge for beer and order a pizza. That’s a different level of party planning.

Sprint planning for a highly interrupt-driven team should be much more like the latter--quick, easy and just enough to be successful.

What Do You Do?

How do you handle interruptions on your agile team? Please share your thoughts in the comments below.

Experimenteren kun je leren

Xebia Blog - Mon, 04/18/2016 - 17:04
Validated learning: het leren door een initieel idee uit te voeren en daarna de resultaten te meten. Deze manier van experimenteren is de primaire filosofie achter Lean Startup en veel van het Agile gedachtegoed zoals het op dit moment wordt toegepast. In wendbare organisaties moet je experimenteren om te kunnen voldoen aan de veranderende markt

Experimenteren kun je leren

Xebia Blog - Mon, 04/18/2016 - 17:04

pdcaValidated learning: het leren door een initieel idee uit te voeren en daarna de resultaten te meten. Deze manier van experimenteren is de primaire filosofie achter Lean Startup en veel van het Agile gedachtegoed zoals het op dit moment wordt toegepast.

In wendbare organisaties moet je experimenteren om te kunnen voldoen aan de veranderende markt behoefte. Een goed experiment kan ongelooflijk waardevol zijn, mits goed uitgevoerd. En hier zit meteen een veel voorkomend probleem: het experiment wordt niet goed afgerond. Er wordt wel een proef gedaan, maar daar zit vaak geen goede hypothese achter en de lessen worden niet of nauwelijks meegenomen. Ik heb gemerkt dat, om een hoger lerend vermogen in de organisatie te krijgen, het handig om een vaste structuur aan te houden voor experimenten.

Er zijn veel structuren die goed werken. Toyota (of Kanban) Kata vind ik persoonlijk heel erg fijn, maar ook de “gewone” Plan-Do-Check-Act werkt erg goed. Die structuur voor een staat met een simpel voorbeeld hieronder uitgelegd:

  1. Hypothese

Welk probleem ga je oplossen? En hoe wil je dat gaan doen?

Als het hele team vanuit huis inbelt voor de stand up dan worden we niet minder effectief dan als iedereen aanwezig is en kunnen we beter omgaan met thuiswerkdagen

  1. Voorspelling van de uitkomsten

Wat is je verwachting van de uitkomsten? Wat ga je zien?

Geen lagere productiviteit, hogere score op team happiness omdat mensen vanuit huis kunnen werken

  1. Experiment

Op welke manier ga je toetsen of je het probleem kunt oplossen? Is dit experiment ook safe to fail?

De komende zes weken belt iedereen in vanuit huis voor de stand up. We scoren in de retrospective op productiviteit en happiness. Daarna doen we zes weken de stand up samen op kantoor

  1. Observaties

Verzamel zo veel mogelijk data tijdens je experiment. Wat zie je gebeuren?

Het opzetten van de call duurt erg lang (10-15 minuten). Het is lastig iedereen aan het woord te laten. Bij het inbellen kunnen we het gewone board niet gebruiken omdat niemand post-its kan verhangen.

A well designed experiment is as likely to fail as it is to succeed – Free to Don Reinertsen

 Dit is vast niet het beste experiment dat geformuleerd kan worden. Maar daar gaat het niet om. Waar het om gaat is dat het leerproces ontstaat bij de verschillen tussen de voorspelling en de observaties. Het is dus belangrijk om allebei deze stappen te doen en bewust stil te staan bij het leerproces wat daarop volgt. Op basis van je observaties kun je een nieuw experiment formuleren voor nieuwe verbeteringen.

Hoe doe jij je experimenten? Ik ben benieuwd naar wat goed werkt in jouw organisatie.

 

SPaMCAST 390 – Vinay Patankar, Agile Value and Lean Start-ups

SPaMCAST Logo

http://www.spamcast.net

Listen Now

Subscribe on iTunes

The Software Process and Measurement Cast 390 features our interview with Vinay Patankar.  We discussed his start up Process Street and the path Vinay and his partner took in order to embrace agile because it delivered value, not just because it was cool.  We also discussed how Agile fits or helps in a lean start-up and the lessons Vinay wants to pass on to others.

Vinay’s Bio:

Vinay Patankar is the co-founder and CEO of Process Street, the simplest way to manage your teams recurring processes and workflows. Easily set up new clients, onboard employees and manage content publishing with Process Street.

Process Street is a venture-backed SaaS company and AngelPad alum with numerous fortune 500 clients.

When not running Process Street, Vinay loves to travel and spent 4 years as a digital nomad roaming the globe running different internet businesses. He enjoys food, fitness and talking shop.

Twitter: @vinayp10

Re-Read Saturday News

We continue the read Commitment – Novel About Managing Project Risk by Maassen, Matts, and Geary.  Buy your copy today and read along (use the link to support the podcast). This week we tackle Chapters Three which explores visualization, knowledge options and focusing on outcomes. Visit the Software Process and Measurement Blog to catchup on past installments of Re-Read Saturday.

Upcoming Events

I will be at the QAI Quest 2016 in Chicago beginning April 18th through April 22nd.  I will be teaching a full day class on Agile Estimation on April 18 and presenting Budgeting, Estimating, Planning and #NoEstimates: They ALL Make Sense for Agile Testing! on Wednesday, April 20th.  Register now!

I will be speaking at the CMMI Institute’s Capability Counts 2016 Conference in Annapolis, Maryland, May 10th and 11th. Register Now!

Next SPaMCAST

The next three weeks will feature mix tapes with the “if you could fix two things” questions from the top downloads of 2007/08, 2009 and 2010.  I will be doing a bit of vacationing and all the while researching, writing content and editing new interviews for the sprint to episode 400 and beyond.

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, for you or your team.” Support SPaMCAST by buying the book here. Available in English and Chinese.


Categories: Process Management