Agile Development with Kanban
One of my favorite methods of doing Agile development is with Kanban. The process is simple, fluid, and easily communicates project information to stakeholders. Kanban allows us to move to a Just-In-Time (JIT) method, which let’s face it – everyone wants everything today, now.
Kanban Dependency Management
So you switch over to Kanban, you create all your stories, you’re ready to begin tracking your tempo, and you realize your stories don’t move fluidly at all. You notice everything moves from column to column together. This is a dependency problem. All the stories rely on each other so nothing can move until everything moves.
Dealing with Architectural Dependencies in Kanban
The crux of any good development is sound architecture, and it’s even more important in Kanban. Having sound decoupling allows for development to occur in parallel while minimizing risk of mismatching development. Teams that struggle with this fail to understand the important of interfaces and how creating these important software contracts allows for clear, concise, and concurrent development to occur. By providing a proxy through the creation of an interface, we can establish a decoupling that allows for parallel independent development occur.
When interfaces are established appropriately the risk is all aligned to the re-coupling of the comments. When it goes well we can build things like the space station. When it goes wrong, we end up with things like the Mars Climate Orbiter. As long as everyone implements the interface design and tests against the interface, the risk of re-coupling is minimized to external factors.
When interfaces are appropriately managed we can build very large objects utilizing independent modules. The ISS for instance consists of 15 pressurized modules and many others.
How to Create an Interface
While the technical creation is generally pretty straightforward, the bigger concern is eliciting the right requirements. To create an interface properly, all stakeholders need to be at the table to provide input and allow the architect and/or architecture team to develop the workflows for how data needs to move through it. I’m a personal believer that software design is better by dictatorship than by committee. This is due to the fact that committees have the potential to water everything down leading to a weaker overall system due to the need to compromise. A dictatorship in software design will usually optimize one path leaving other weaker paths that can be optimized and hardened individually later on. I generally find the second more desirable and easier to work with as I rather do one thing well than do everything mediocre.
Once all the workflows are identified, the interface can be laid out and the input and output communicated. Teams can then build and test their side of the interface interaction assuming the other side will do the right thing. At this point the Kanban boards can deal with the integration fluidly. Modifications due to integration testing can just be slotted – probably into an expedited swimlane, but at least still slotted – without negatively impacting the overall tempo. This is due to the fact that the work remains fluid by not marrying the development work on both sides of the interface.