Working in cells – A pattern to limit work in progress in a software development environment
Software development requires analysis, design, development and testing to verify that all is as we expect it to be. These activities could be done by one person but not very often, most organisations have different specialists who carry out these activities and as the technology grows we have various types of developers.
When we have multiple people carrying out these activities we get in situations where everyone is focused on their part of the work and not on the whole. Why is this a problem? Let’s look at some typical flow of development and testing, in this scenario we assume the team is working on stories as shown below S23 to S26. As you can see in Table 1 each person in the team is focused on their part leading to starting more and taking longer to finish the stories.
The cells in the Table 1 are colour coded to show the activity (development or testing), X signifies a defect that is found on a story.
Time ———————————————————————————————–> | |||||||||||||
WIP ↓ | S23 | X | X | D | |||||||||
S24 | X | ||||||||||||
S25 | X | ||||||||||||
S26 | |||||||||||||
Key | Develop | Test | Defect | X | Blocked | X | Done | D | |||||
Table 1 – Focused on my job
This is as the result of thinking,
As a developer my job is to start developing the next story as soon as the story is ready for test.
As a tester my job is to find all the defects to make sure no stories go through with defects.
As a manager my job is to make sure that all my team members are busy doing work.
Let’s challenge this thinking: do we value busy-ness or do we value shorter time to complete each story and for the team to increase their delivery rate. The counter-intuitive truth is that by focusing on one story we will finish the story quicker and we complete more stories as well.
When we hand off the story between team members and the story comes back because it fails the testing and as a tester I have to create a bug or bugs and then hand back the story to the developer we have created task switching delay and because as a developer or the tester I started on the next story I have increased the work in progress meaning longer queues even more delays and more opportunities for multitasking.
This is also as the result of our mindset in how we are designing and managing the work as leaders we believe that the work is deterministic and a developer can do all the required development the test specialist and check and then we can deploy and release. Software development is not deterministic and we can’t know in advance we will only find out through iterative and incremental delivery and evolving the system. Furthermore, separating the testing from development is inspecting for quality as opposed to building quality in the work from the start. When developers and testers work together and we use behaviour and test driven development practices we start by building quality in from the start.
How does working in cells address the above?
Create a cell say of one developer and one test specialist or two developers and two testers, and let’s call them cell A. Cell A has one mission to pick up the next most important story, develop, test and deploy it and get it to ‘Done’ in the shortest sustainable time.
No more switching between stories or handing off from developer to test we are both working on the same story with the same shared goal of getting the story over the line. By considering both perspectives we develop better products sooner.
We can’t ignore blockers
A side effect of working in cells is the increased focus that we get in picking a story and finishing it, so what happens when we get blocked? Before working in cells we would have flagged this and picked up the next story now we are forcing ourselves to address problems rather than putting them to one side.
Now we need to address problems ideally fix the root cause or find a workaround for now and address the root cause if the root cause needs considerable time.
Conclusion
To accelerate your software delivery, focus on finishing one story before starting the next.
Acknowledge that software development is not deterministic and you need to think and act differently.
Consider working in cells to further accelerate software delivery, although initially things may feel slower because we are focused on finishing the work rather than starting.
And when we are blocked we stop and fix what is blocking us rather than letting this work item age and start a new piece of work.
Here is the results of applying the above pattern with one of the teams.
