Disclaimer: This post is for individuals, teams and organizations genuinely interested in Agile.
I am noticing a certain trend in software development where teams make their software development process mimic a production line by treating each software development activity as a separate station. Their “boards” make every activity a separate column. A number of teams do this in the name of implementing the Kanban Method while others do it because it represents what they are used to. Why is this the case?
Two reasons immediately come to mind (I’m sure you can think of more):
- Work items take more than a few days to complete
- Work items are acted upon in a sequential manner
If your work items consistently take more than a few days to complete, what actions is the team taking to address this? Have you asked yourselves why? Is the nature of the work such that working software cannot be completed in a few days? Everything has to take a few weeks or months? Is the team focused on too much stuff at the same time? Maybe everyone is working on their own unique items and is not working together (collaborating) to complete items in a timely manner? It is a known fact that the less work we have in progress, the more we get done and the less time it takes. In spite of this known fact, many organizations/teams/individuals fail woefully at limiting work in progress.
I still find teams that believe software development has to be sequential (in the small) just like a production line. Many have described this as mini-waterfall. Each role on the team represents its own “workstation” and for the work item to be completed, it needs to pass through all the workstations via hand-offs. A classic indicator of this is a team where the testers complain that they have no time to test in the Sprint (another reason why teams abandon time-boxes for Proto-Kanban). For example, a user story would “flow” in this manner:
Analysis -> Design -> Code -> Test -> Deploy
(The fact of the matter is that if it takes a few days to complete a user story, these activities would overlap to the point that making them explicit would provide little value.)
What if instead of having work move in a sequential manner we have all the roles performing their activities on the user story concurrently? What if the work item was the center of the universe with multiple actors acting on it at the same time? What could happen then?
There are some major implications with this approach. For starters, it would mean we focus multiple team members and roles on as few work items as is possible. A business analyst, engineer and tester (for example) all working together at the same time on the same thing. If you don’t think this is possible, let’s have a chat. Or perform a Google search. Or ask an Agile practitioner.
This is a fundamental shift in the way we traditionally approach how we work in software development. (In the first Kanban system I ever designed, it was a rule that more than one person should be working on a item that was in development. Team members and partners in the other departments initially found it strange as they were not used this but eventually came to appreciate this approach as it enabled us to deliver software more effectively.)
The feedback I receive from people when I bring topics like this up is that things are working just fine and hence they have no reason to do anything different. No reason to decrease the time it takes to complete user stories. No reason to change the way they work on their work items. In my opinion, these people have totally missed an important point about Agile (and Lean) and that is the relentless commitment to continuous improvement. The commitment to finding better ways to do our jobs even when the current ways seems to work well. The commitment to being the best we can be. These individuals, teams and organizations are completely missing a critical component of the Agile mindset.
So does your Agile process have to mimic a production line?