Is your team ready for iteration-less development?

In the last few weeks, I have found myself frequently being asked "What do we need do to move to a continuous flow model?". The question comes from members in teams using SCRUM-style sprints or iterations considering moving towards Kanban-style continuous flow. The answer I give to the question depends on the questioner's response to the questions below:

What problem(s) are you trying to solve?

It is quite possible that the pain experienced by the team are simply problems being driven to the surface. Ideally, these problems should be solved not avoided. And the problems may continue to exist regardless of the process used.

Is iteration-less development right for your team?

In some circles iteration-based agile delivery is touted as being a 'stepping-stone' to the 'true' agile of iteration-less development. I disagree. While it is true that the discipline and practices encouraged by delivery iterations are necessary for iteration-less delivery to work well, I see them both as equally effective, just with different pro's and con's.

For example, if your team really values all team members having a good shared understanding of the requirement to be worked on, this is facilitated well by a SCRUM-like approach due to the team planning methods used. This  shared understanding is not supported quite so well by a continuous flow model of delivery.

But if the team is mainly working on items of similar sizes, and/or with rapidly changing priorities, then iteration-less development is a good fit.  And there is plenty of grey areas in between.

Are you already using a visual control (Kanban) board?

I have found that 'walking the board' in stand-ups is infintely more useful than routinely answering the standard 3 questions:

1. What did you do yesterday?
2. What will you do today?
3. Are there any impediments in your way?

Being accustomed to monitoring the flow and progress of items across the board, and knowing how to identify and resolve bottlenecks is a valuable practice.

Do you have defined exit criteria for the states on the visual control board documented and agreed (within your team)?

Ambiguity in the meaning of the states in the visual control board can cause confusion and discord within the team.

Are you using (and adhering to) Work In Process (WIP) limits?

I have a rule of thumb:

"The WIP limit for a state column in a Visual Control Board should be no higher than one less than the number of specialists who focus on the activities in a column."

For example: In a team with 3 QA-oriented team members, the WIP limit on the 'in-test' column should be one.

This forces the team to greater collaboration as they work together on an item and forces the work to be broken down to allow it to be parallelised amoung team members.

One of the goals of continuous flow is to reduce the cycle time of a requirement, to flow it from start to finish in as short a time as possible.  A key element of this is the ability for multiple team members to work on a requirement concurrently.  Without this ability, there is the danger of a mini-waterfall approach for each requirement, and this could lead to nudging closer to a 'no-process' style of delivery.

Adhering to a WIP limit highlights queues and other process problems.  These issues, now they are visible, ideally should be resolved before considering a process change.

Do you routinely have multiple team members working concurrently on the same requirement?

This question is very similar to the previous one, but it is important to establish if this is common practice or not.

Ideally, a 4-day requirement could be broken down into 3 development tasks and 2 QA tasks.  If a development team was to 'swarm' this, then it could be completed in 2 calendar days.  When multiple team members tackle a requirement concurrently, then cycle time can be reduced, and requirements can flow from started to completed to deployed more rapidly.

Swarming requirements helps to alleviate variation in workload, times of high and low demand.  Evening out this flow is beneficial when looking towards a continuous flow model.

Are your requirements consistently sized?

If requirements are consistently sized, then questions of priority, schedule, and delivery date are easy to answer and predict - giving stakeholders at either end of the chain confidence.

For example, if your team can routinely complete 4 requirements per week, and a requirement is ranked 5th in the backlog, the stakeholder can be confident that their requirement will be delivered in 2-3 weeks.

Are you routinely delivering high quality, functionally complete, items at the end of each iteration?

For a feature to be properly complete, when it is delivered it should be defect-free and fully functional.  Software development is one of those disciplines where the pareto principle is true: 80% of the functionality takes 20% of the effort and the remaining 20% takes 80% of the effort.  So called "feature-polishing", latent defects, and technical debt all sabotage the ability of a team to deliver at a consistent rate.  These things can be remain hidden for a few iterations, but eventually the team's rate of delivery will drop markedly.

Adopting the following practices may "slow down" the team, but will help the team to be able to deliver at a consistent pace indefinitely:

• Refactoring during development to keep technical debt low
• Resolving defects as close to injection point as possible and keeping the known defect rate low
• Pushing each requirement to fully scope complete and verifying this before saying 'it is done'.

Do you have a continuous delivery mechanism in place?

One of the motivations behind continuous flow, is being able to deliver features into production as soon as they are deemed production ready.  A continuous delivery mechanism is an essential element of this.  Even if this mechanism simply compiles the software, deploys it to the QA environment, and runs the automated tests - it provides the fast feedback that is so valuable in an agile environment.

In conclusion

Whether the team opts for iteration-less, or iteration-driven delivery depends on a number of factors, none of them being "agile maturity".   Any of the disciplines discussed above can contribute to successful, productive delivery regardless of which approach your team uses to deliver software.


Good luck!