Flow based development – focus on finishing

A little history: Scrum, KanBan and DevOps

Over the past 15 years, the IT industry has taken to working ‘agile’, often by introducing Scrum. Scrum is development process, which creates a cadence of sprints that last a few weeks each. User stories are used to determine the work to be done. These user stories are planned, committed, built and delivered. There is also room to evaluate the work, the object being to improve together.

Over the past 5 years, there have been some big developments in how fast software can be delivered. Thanks to the DevOps movement, we adapted our thinking and actions so that we can deliver software in a fully automated way. The obstacles were removed and we can now deliver new software immediately, once it’s ready and accepted by users.

The combination of Agile thinking and DevOps opportunities for immediate delivery caused a further evolution in the manufacturing process in IT: the arrival of KanBan. KanBan divides the manufacturing process into phases and limits the amount of work that may be done in each phase. Using KanBan, a limit is created to the amount of work in progress.

There’s an underlying, deeper philosophy to KanBan, known as the Theory of Constraints (ToC). This theory focuses on the lead time of the work and aims to reduce it.

Fast delivery to your clients is always a good idea.

How long is the wait before you get your result?

According to ToC, the basis for reducing lead time lies in limiting the number of things that must be done simultaneously. This is exactly what KanBan does: limiting the work in progress. The effectiveness of KanBan is proven by Little’s Law, which states that

lead time = work in progress x flow rate

In other words: if you have tasks that each take 2 days of work (flow rate), you’ll be finished in 6 days (lead time) if 3 of the tasks are still work in progress. And: if you’re asked to do something extra, it will be 8 days before you’re finished, because your work in progress has increased to 4.

How do you do this as a team?

Now that we know it’s best not to do too much simultaneously and not to have too much work in progress, how do we get organised as a team? A team can create optimal flow if it takes the following steps:

1. Make your development process visible.
2. Determine which part is the ‘work in progress’.
3. Determine the limit for the work in progress.

These 3 steps will give you an overview of what is going on. But you need more to ensure a good flow: new work can only be started if the work in progress is finished. That way you make sure the work will be ‘pulled’ through the system, as it were, and you’ll have a so-called pull system. This approach is known as Flow Based Development.

From team to process

Teams usually consist of specialists who each have their own specific knowledge and skills. There’s usually no overlap because the work is too specialist. The danger here is that it may create ‘wait states’: one specialist waiting for another to finish before he or she can move on. Specialists within a team should learn to collaborate in such a way that they can deliver the work together, properly and on time.

Sometimes one specialist has nothing to do because other things need to be finished first. The biggest pitfall here is to start doing ‘other work’ that seems useful. This will increase the work in progress and therefore the lead time. It is better to go for a Swarming tactic as a team.

What this means is that people should be prepared to help each other even in areas they are not specialised in. In short, you need real teamwork, not a collection of individuals. In addition, teams should divide the tasks in a smart way, thus ensuring that each specialist can keep working and that all the tasks are attuned to one another.

In this respect it’s also important to check the way specifications are made. Within a team of specialists there should be room for them to find a solution to a given problem. A format of watertight user stories specifying that a button should be placed on a web page will result in a situation where not every team member can work on the request. Defining a problem in such a way that there’s room for the team to function optimally: that is the basis for successful Flow Based Development.

Flow Based Development

Flow based development focuses on reducing the lead time between start and use. The process is executed by a team of specialists responsible for finding a solution that works, its technical implementation, and putting it into operation.

Placing limits on work in progress enables fast delivery of any work that has started. This process can be made visible, and the data it produces can be used to forecast and think in scenarios. That way planning will also be faster and more efficient.

Like to know more ?

If you like to have a conversation or need support on flow based development, you can always contact me