Case study of implementation and adaptation of Kanban processes onto a software development team.

1. Little bits of cardboard A study of a project using Kanban processes

2. New infrastructure project Unknown and rapidly emerging requirements. Architecture evolved as the project progressed. New clients for the product meant rapidly emerging requirements The application had to be deployed ASAP to meet contractual obligations Details

3. The project was at a standstill, cards were not moving across the board. Large numbers of cards clogged the board and the team felt paralysed. It was difficult to prioritise, as the backlog was so big and undefined 4 months of development work done with no production deployment of any code. Problems

4. The board before Story card Ready for test Test failed In test Backlog Signed off Blocked In Dev Ready for Dev Story card Story card Story card Story card Story card Story card Story card Story card Story card Story card Story card Story card Story card Story card Story card Story card Story card Story card Story card Story card Story card Story card Story card Story card Story card Story card Story card Story card Story card Story card Jim Jim Mel Mel Tom A story board can provide a lot of information about a team and how it is performing. The team board had a lot of signals about were problems were occuring

5. Problems Story card Ready for test Test failed In test Backlog Blocked In Dev Ready for Dev Large backlog column: The backlog column contained upcoming stories for the entire project Competing priorities meant the development effort wasn’t focused Stand ups tended to focus on backlog items that hadn’t even made the “Ready for Dev” – (current sprint) column. Time was spent estimating and planning on stories that never ended up getting prioritised Story card Story card Story card Story card Story card Story card Story card Story card Story card Story card Story card Story card Story card Story card Story card Story card Story card Story card Story card Story card Story card Jim Jim Mel Mel Tom

6. In Dev Story card Story card Story card Story card Jim Jim Mel Mel Tom Problems Team members were deployed across multiple cards, they found it frustrating and difficult to focus on getting things done.

8. The reasons for this were varied, but there was a lack of ownership or urgencyStory card Story card

9. After a few different approaches were discussed, we trialled a Lean/Kanban approach/process This helped us focus on our constraints and get back to getting things done. What we did next

11. We started by limiting WIP (Work in progress) on the swim lanes, including the “In analysis” and “ready for Dev” lanes How we got there

12. Limiting WIP Story card Ready for test 2 Ready for Sign off 3 In Analysis 2 Ready for Dev 2 In test 2 Signed off Parking lot In Dev 2 Something to talk about tomorrow Story card Story card Story card Story card Story card Story card Story card Story card Story card Story card Ben Tom Mel Jim Cards on the lanes limited to available pairs in the sprint. New cards are demand pulled into the lanes to reach capacity as cards are completed and moved across. Developers only allowed to be on ONE card This ensured the cards coming through were really the “highest” priority Helped minimise discussion and pre-work on low priority cards

13. Worked out what the bare minimum was to get our “first” production release out, even if it meant the application was feature poor. This was what is termed a “MMF” or “Minimum marketable feature” Allowed us to target incremental delivery rather than “big bang” if nothing else, this helped prove the “Path to Production” getting early feedback on performance across all your environments in invaluable. “Please, just let us release something!”

14. Release token/card Story card Ready for test 2 Ready for Sign off 3 In Analysis 2 Ready for Dev 2 In test 2 Signed off Parking lot In Dev 2 Something to talk about tomorrow Story card Story card Story card Story card Story card Story card Story card Story card Story card Ben Tom Mel Jim Release Card Tom JT We introduced a “Release” token which followed the last of the cards in the MMF across the board. This card behaved just as any other card did, occupying slots and requiring owners Any card that followed the release card was not checked into the main trunk until after the release card was “signed off” – which meant deployed We released when we had enough, not at the “end” of a sprint cycle.

15. Reducing clutter/confusion Story card Story card Story card Story card Story card Story card Story card Story card Mel Jim Ready for test 2 Ready for Sign off 3 In Analysis 2 Ready for Dev 2 In test 2 Signed off Parking lot In Dev 2 Something to talk about tomorrow Reduced the amount of clutter that was on the board by removing the backlog column Backlog items were removed and placed out of immediate sight Removed the blocked column, changed how “blocked cards were dealt with” Blocked cards had to find an owner, and therefore a swimlane, or were deprioritised

16. Adding buffers Story card Story card Story card Story card Story card Story card Story card Story card Mel Jim Ready for test 2 Ready for Sign off 3 In Analysis 2 Ready for Dev 2 In test 2 Signed off Parking lot In Dev 2 Something to talk about tomorrow We got excited about removing lanes so; We removed the test failed lane and created a buffer zone above “In Dev”. These cards were considered the highest priority in that lane. Buffers added to other lanes as well, these helped create strong signals of constraints in the system that needed to be acted upon.

17. Sprint cycle and release cycle were “uncoupled” Planning was done, as required, not by timetables Retained sprint cadence for “retros” and “demos” Team aggressively split cards to look for smallest item of “business value” Having limited “fixed backlog” meant we could react very quickly to change Rolled technical stories into stories that deliver business value forced us to change course slowly and justify changes, also reduced Technical debt What changed

18. Delivering a constant stream of small but valuable stuff into production every week is VERY motivating. Splitting stories can reveal just how little business value certain aspects of stories contain We almost never get through everything that was “planned” We almost always ended up doing stories that weren’t “planned” Just-in-time stories can enable the business to leave decision of what’s important to the last possible moment. Trying to deliver everything to everyone can lead to delivering nothing at all to anyone What did we learn?

19. Simplifies workflow Reduces confusion Encourages small incremental releases Accepts and encourages change Teams with highly flexible backlogs (BAU, support) are ideal candidates for Kanban Allows teams to focus on their constraints and support them Is motivating to developers Forces prioritisation by limiting WIP Works well for new product development teams Take home message

20. Thank you