Defects is probably the number 1 waste in software development. This is not a new thing, it has been a major problem ever since the software crisis was coined four decades ago. Creating software that works is hard. Creating software that works and does what the customer wants it to do is even harder. And with team members fighting as best as they can to meet a tight deadline, things get really difficult. I believe Kanban, combined with XP practices can help teams deliver high quality software at a reliable and sustainable pace.
A call for craftsmanship
It is not uncommon to see projects struggle with high defect rates late on in the development cycle. Tracking down bugs in a system test environment may be hard, time-consuming and expensive. As a continuous stream of defects hit the project environment, focus is moved away from building new features. Testers get fed up by having to report errors that should have been detected earlier in the process, and the situation is not any better for developers: Stress level is rising as yet more defect are reported and the release date is approaching (1):
As the pressure is rising, developers do less testing. This results in more errors leading to more stress, which again leads to less testing, leading to even more bugs and so on and so on… It’s time to slow down!
Slow down to go fast – limit work in progress
It is not uncommon see software developers rush straight into coding a user story, doing little or no design at all, and using only their own interpretations of a user story as guidelines for development. This could be dangerous for several reasons:
- The developed story may not be consistent with what the customer has ordered
- Developers are pushing new features into test at a rate testers can’t keep up with, causing an uneven workload in the system
The time that was saved by over-eager developers who started coding early on stories will soon be lost, and most likely more so. Limiting work in progress and focus on software craftsmanship can help remedy this problem, hence:
Kanban combined with XP practices can help us deliver high quality software at a sustainable and reliable pace.
Limiting work in progress is a really powerful technique and it is a key driver for change. When you starting it several interesting things start happening:
- It detects problems in your workflow and force you to do something about these problems
- It limits the amount of multitasking, thus removing the amount of context switching needed
- It creates natural slack in your system allowing your team members to work at a sustainable pace
- And last but not least: It creates a balanced flow of work through your process
The goal is to maximize the throughput of value, not to have workers pushing themselves at a 100 % all the time.
But visualizing the work and limiting work in progress alone is not enough. If our team is busy fighting fires, correcting errors from earlier steps in the process or from sloppy work delivered in previous iterations, they will have limited time to build new features. To fix this we must try to raise the quality of the work delivered from every step in our process. Solid XP techniques like TDD and pair programming can help us achieve this.
Invest in quality early – Make the right product
We can improve predictability in our process by investing in quality early in the process. In the Kanban board below we have a specify queue before development. The output from this step should be a set of acceptance tests. These tests work as a functional specification for developers and will help them to make the right product. Ideally these tests should be developed by testers/customers in collaboration with developer(s). This may have the following positive effects:
- Improved balance in the workload
- Increased chance of delivering the right product
- Increased automatic test coverage (or at least possibility of such)
But this is common sense, you might say. In theory yes. In practice no. Doing the right thing, performing good craftsmanship, requires a lot of discipline. Some people are able to do this even in an environment with few or no rules at all, “doing whatever”. But a few of us could benefit from having a process that “guides” us in our daily work.
The illustration above shows a business analyst (BA) and a developer working together to do just in time planning and specification of acceptance tests for story. This is quite different from how for example scrum teams work, where a sprint is started with an extensive sprint planning meeting. The goal of this meeting is for the team to commit to delivering a set of stories within x weeks. There is nothing wrong with this approach, this one is just a little bit different: Instead of doing one big meeting, planning multiple stories at once, we delay the planning until just before we start coding the story. Just in time (JIT) is of course one of the two ground pillars in TPS.
Now, the pair should focus on finding all the acceptance tests they can with the knowledge they have at the time. The developers coding on the story can now use these tests as a foundation for building the software that fulfills the requirements. It is preferable to have these tests as executable tests, f.ex in Fitnesse or Cucumber. If they are, they can be run as part of the automatic build and thus free up time for testers to do more exploratory testing, load tests and so forth.
Make the product right
Acceptance test driven development may help you deliver the right product. But you also need to make sure that you make the code right. If your team is using XP practices like TDD, pair programming and continuous integration you improve the chance of this happening.
A user story in the Specify Done column is the signal for developer(s) to start coding the story. The tests work as specification, guiding the developers in making the right code. The board above shows two developers pairing up to code a user story using TDD . When the pair finds a missing requirement they add a failing acceptance test, adding to the already existing set of tests. Steve Freeman and Nat Pryce refers to this as a double TDD loop (2)
Going into details about why you should use TDD in your daily work is beyond the scope of this article, there are tons of great material available online. But TDD done right will keep your code clean and well factored. It will also give you an automated test suite running as part of your build. Both of these will improve your confidence and make you able to change code more quickly. It will most likely slow you down initially, but in the long run it enables you to go faster so that you can add new features at a reliable and sustainable pace.
Back to our board, the card is moved into the “Development done” column when all tests (both acceptance tests and unit tests) are green, the code is checked into the version control system, built on a continuous integration server and deployed to a proper test environment.
Get them features fully tested
A card moved into the development done column is the signal for the test team to pull the card into system test. Having system test as an explicit step in our workflow has several benefits:
- Features and bugs get fully tested by a test team as part of the process
Finding bugs in a system test environment is cheaper than finding bugs in an acceptance test environment. When we have system test as part of our process and having a limit on the amount of tests, we will raise the quality of the code we deploy to the acceptance test environment.
- Stable system test environment
Since we only deploy a few new features and/or bugs on each deploy we never overload our test environment with loads of new features or bugs. This means that system test remains relatively stable since we do our best in checking that newly developed features or newly fixed bugs is implemented correctly before we deploy new code to the environment. A stable test environment means less maintenance work, which again will free up developers to do value-adding work.
The Kanban board above shows the team working to get a feature through system test. It also shows an example of swarming behavior, a key characteristic of a Kanban system. Since we are at capacity in “Specify”, “Development” and “System test” the team needs to finish testing of “User story 2” before they can start any new work. This is a very effective way of getting features or bugs finished.
Close the customer feedback loop
Only when features are moved all the way to production can we understand the actual business value of the features delivered. So if you can: Deliver features to production frequently.
You may discover that this can be hard to achieve, and that it may require changes in your architecture. In a complex enterprise environment we can only achieve this by breaking dependencies between components and systems. This is not done overnight, but by taking small steps doing small improvements we can get there in the long run.
The Kanban board above shows user acceptance test and release to production incorporated as part of the process. This will give us quick customer feedback on the features we deliver. We can use this information to plan which features to deliver next.
Kanban is not the goal – Creating value is
Having a Kanban system is not the goal, creating value for the business is. But Kanban can help raise our awareness about how we implement software and guide us to solve systemic issues that happens as we progress. Making the process explicit can help train teams into practicing good craftsmanship. After a while the explicit knowledge will turn into tacit knowledge, the maturity level of the team will increase. A team of experts (see the Dreyfus model) probably don’t need a Kanban system in order to deliver quality software at a sustainable pace. And remember: Customers do not pay us for doing Kanban. They pay us for delivering software that works, software that provides value for the users of it.
- Test Driven Development By Example – Kent Beck
- Growing Object Oriented Software Guided By Tests – Steve Freeman and Nat Pryce