Your team is getting ready to start with Kanban or perhaps they already have been using Kanban. In either case, they begin to think, “How do we implement good technical practices using a Kanban approach?” Good technical practice implementation in Scrum is common. This is a result of these practices being originally implemented in the […]
Your team is getting ready to start with Kanban or perhaps they already have been using Kanban. In either case, they begin to think, “How do we implement good technical practices using a Kanban approach?”
Good technical practice implementation in Scrum is common. This is a result of these practices being originally implemented in the similar iterative approach of eXtreme Programming (XP). Less discussion, however, has occurred about these in Kanban, though as you’ll see integration is not that difficult conceptually. Like any practice a team chooses to follow, implementing it may be challenging as each practice requires a shift in mindset.
Most teams using a Kanban approach have a column that represents “in development” (along with a queue corresponding to the ready state for that column). Technical practices such as Pair Programming, Continuous Integration, Unit Testing, and Test-Driven Development (TDD) really don’t require any change to the layout of your board. If you had manual testing in place of unit testing, which is a prerequisite to TDD, you might find that this column will be eliminated or altered. Some of these may update your Kanban board’s policies, so that they can be explicitly understood.
Let’s pick-up where manual testing comes into play. Much of the manual testing performed on Agile teams becomes exploratory in nature; finding those edge cases that are outside the normal realm of thought. When this becomes extensive enough that the team needs a ‘phase’ in their workflow where this occurs, a set of columns for this exploratory testing and its associated ‘ready’ queue can be established.
When teams use Behavior Driven Development (BDD) / Acceptance Test-Driven Development (ATDD), they may find that any form of functional test columns get translated into more of a story verification column. Since this is a form of automation that is integrated into a team’s Continuous Integration pipeline, the prior ‘ready’ queue may also disappear. What may be added to the board is the simultaneous state of defining the specification in the language of your BDD/ATDD tool (Gherkin, for example, in Cucumber). There would be a subsequent policy applied to this state that the specification was written so it is ready to execute against the code.
Once a team moves to using Continuous Delivery, many queues may disappear or change order. For example, the deployment ready queue is likely to become unnecessary. The Product Owner approval may occur AFTER the product has been deployed into production (with the feature(s) of the implemented user story turned off via toggles). Once the Product Owner approves the story, the toggle turns this feature set on. Another item that may be needed at this point is a holding space for features that were not approved or need removal.
Determining how your Kanban system will look is driven by your team’s choices in how they want to flow work through the system. As automation is used more, one will find queues can be removed. When decisions get pushed forward in the process, it may be beneficial to capture these as new states on your board.
This blog post is part of our upcoming “Scrum vs. Kanban” series, triggered by a working session at one of Excella’s Agile Coaching Circle’s offsite meetings. We explored our experiences with and thoughts about the Scrum Framework and Kanban Method, identifying a series of themes that would enhance the knowledge and understanding of our colleagues. We are pleased to share those lessons with you.
Agile coaching is what we love to do. There is nothing better than seeing a...
Agile experts think great product owners act as entrepreneurs for their product. Product owners and...