AgileCamp 2014 Track 5: Visual Roadmapping with Kanban
6 likes1,242 views
Visual Roadmapping with Kanban describes the company's journey from a waterfall to iterative to Kanban-based process. They initially implemented a basic Kanban system to visualize workflow, but found disconnects between product management and engineering. Subsequent versions separated planning from execution, added a roadmap board, and limited work-in-progress. This improved throughput, reduced cycle times, and allowed for continuous delivery of frequent, high-value releases planned collaboratively across functions. While initially scary, Kanban provided operational and business benefits through greater transparency, trust, and self-regulation of workflow.
AgileCamp 2014 Track 5: Visual Roadmapping with Kanban
- 1. Visual Roadmapping with Kanban Mahesh Singh Co-founder/ SVP – Product, Digité, Inc. Visualization is Enlightenment!
- 2. Agenda In the Beginning… Roadmapping Challenges! Enter Kanban – What is Kanban? Visualize – WIP Limits – Manage Flow Evolution of our adoption of Kanban Simple Sophisticated Tiered Kanban – The Good, The Scary, The Beautiful Q&A
- 3. Planning for the Next Release…. How we were…3 © Digite, Inc.
- 4. Waterfall – 2002-2006 4 © Digite, Inc.
- 5. Iterative – 2007 - 2010 IR1 IR2 IR 3 5 © Digite, Inc.
- 6. Our Release Schedule © Digite, Inc. 6 3 Releases per year 2 Minor 1 Major We thought we had it pretty good!
- 7. But behind the scene…7 © Digite, Inc.
- 8. What was going to be the “Next Release”?! © Digite, Inc. 8
- 9. Product Management could not “Define” © Digite, Inc. 9 Large backlog that was not very visible Different functions clamoring for priority PM and Engg teams busy with completing the last release Multiple versions of MRD/ PRD across stakeholders PM was challenged to scope/ share/ get agreement on the next release!
- 10. Engineering could not “Commit…” © Digite, Inc. 10 Almost all functions – Dev/ QA/ PM/ Support – pulled into testing Automated Testing was “insufficient”/ significant overhead in manual testing Busy with fixing bugs in the last release PM was expected to deliver “frozen specs” before they could start working Engg too busy to plan and commit! Commitments made could not be kept.
- 11. Management/ Sales Wanted to “Do More” © Digite, Inc. 11 “Development is not fast enough” “Productivity is low” “Quality is bad” “Product does not meet market need” “Can we do this one more thing?” Management/ Sales were frustrated!
- 12. Overall situation ….. Release Planning a Very Costly Process! A LOT OF EFFORT before Use Cases or Epics/ User Stories made it to the Backlog! When we spoke to our customers and other Bay Area companies, we realized we were not alone! Getting from Vision/ Roadmap to User Stories in a Backlog is a lot of work – and is usually not very organized! 12 © Digite, Inc.
- 13. Roadmapping is Challenging So many “good points” to implement!
- 14. Roadmapping Challenges High Demand Inflow – there are simply too many ideas/ suggestions coming in with every interaction Varied Sources/ Perspectives Management is unable to understand why features are not coming out fast enough Sales/ Customers have trouble understanding why one small feature cannot be done. Also, Sales usually finds every feature suggestion from the customer to be logical AND high priority! Getting all stakeholders to converge on scope and priority Giving representation to all sides, including Engineering
- 15. The Answers Product Management is Trying to Give Management/ Sales What do we build – this sprint, this release, this quarter, year? How to avoid stuffing more features into the pipeline?? What the Dev team can really deliver each cycle Engineering What do we work on?? Can we get some bandwidth for refactoring? Support Can we give some attention to existing customers?! Can we FOCUS on the TOP few?!
- 16. Kanban to the Rescue! How we turned around…16 © Digite, Inc.
- 17. Our Kanban Journey Decision to build SwiftKanban – April 2010 A fair bit of reading up! Discussions with several thought leaders – David Anderson, Masa K Maeda, Jim Benson, Al Shalloway, Yuval Yeret.. Kanban training – Q4, 2010 We started using it as soon as we launched Beta 17 © Digite, Inc.
- 18. Key Principles of Kanban Visualize Flow Limit WIP Manage Flow Make Policies Explicit Implement Feedback Loops Improve Collaboratively, Evolve Experimentally (using models and the scientific method)
- 19. Kanban Foundation Principles Start with what you do now Agree to pursue incremental, evolutionary change Respect the current process, roles, responsibilities & titles
- 20. Benefits we sought from Kanban © Digite, Inc. 20 Smoother Flow Greater Throughput Continuous (more frequent) delivery Faster Time to Market Greater Visibility Greater Understanding and Agreement within the Company We were EXCITED! We were raring to go!
- 21. First version of our Kanban – As Is (2010- 11) © Digite, Inc. 21
- 22. Iterative + Kanban – 2010 - 2011 22 © Digite, Inc.
- 23. Iterative + Kanban – 2010 - 2011 23 © Digite, Inc.
- 24. Retrospective Findings © Digite, Inc. 24 Disconnect between PM and Engg persisted Frequently changing requirements/ user stories Frequently changing priority Committed users stories getting dropped User stories developed were incomplete Development and Automation challenges Automation not visible, not synchronized with development Code review sporadic Release cadence not clear Engg called upon to do interrupt-driven work
- 25. Version 2 of our Kanban (2011-2012) Greater Attention to Planning/ Scoping © Digite, Inc. 25
- 26. © Digite, Inc. 26 Version 2 of our Kanban (2011-2012) Separate Dev with Details of Automation/ Review/ Deployment
- 27. © Digite, Inc. 27 Version 2 of our Kanban (2011-2012) All Engg Activity put on Board
- 28. © Digite, Inc. 28 Version 3 of our Kanban (2012-2013) Roadmapping in a separate board
- 29. © Digite, Inc. 29 Version 3 of our Kanban (2012-Present) Execution separated from Planning/ Spec- ing
- 30. Version 4: Simplified Roadmap Board (2013- 2014)
- 31. Visual Backlog (by Aging) (2013-2014)
- 32. Additional Process Changes © Digite, Inc. 32 “Monthly Prioritization Meeting” with leadership team on Roadmap Board Access to leadership to all boards. CEO/ Sales/ Support look at the board to see when they can expect a feature to be released
- 33. “The shorter the Project, the more planning it needs.” – old (Project Management) Jungle saying…! The Impact…33 © Digite, Inc.
- 34. Cumulative Flow Diagram (Minus backlog/ archive) Jan – Dec, 2013 (11 Releases) 11 Releases made during 2012! 18-24 planned for 2013. 34 © Digite, Inc.
- 35. Cumulative Flow Diagram (Minus backlog/ archive) May, 13 – Apr, 2014) 8-9 Release
- 36. Average Cycle Time of User Stories 300% Reduction in Cycle Time thru a combination of factors! 36 © Digite, Inc.
- 38. The Good Visual Backlog – WIIFM Factor Visual Board – Establish Trust Throughput – Team‟s real delivery capacity. No they can‟t deliver more. BUT they can deliver MORE OFTEN! WIP Limit – It can‟t be done. Period. OR – what are you willing to take out? Class of Service – Cost of Delay focus (charts)/ Refactoring Blocking – Where are things stuck? I am stuck and I need HELP! Continuous Delivery - Last Responsible Minute Prioritization/ Frequent Value Delivery Control Charts/ Statistics – Better ability to forecast, build simulation models, predict organization performance Committing to release scope vs. Making a Release when there are enough Commits
- 39. The Good Visual Backlog – WIIFM Factor.
- 40. The Good Visual Board – Establish Trust
- 41. The Good Throughput – Team‟s real delivery capacity. No they can‟t deliver more. BUT they can deliver MORE OFTEN!
- 42. The Good WIP Limit – It can‟t be done. Period. OR – what are you willing to take out?
- 43. The Good Class of Service – Some level Cost of Delay focus/ More Refactoring than ever before!
- 44. The Good Blocking – Where are things stuck? I am stuck and I need HELP!
- 45. The Good Continuous Delivery - Last Responsible Minute Prioritization/ Frequent Value Delivery
- 46. The Good Control Charts/ Statistics – Better ability to forecast, build simulation models, predict organization performance
- 47. The Good Committing to Release Scope up-front vs. Making a Release when there are enough Commits! (And Make as many releases as possible!)
- 48. The Scary. And the Beautiful! The Scary Pull – Engg Team has say in what they will take and how soon they will deliver Lack of buckets – „Our next release will be …umm‟ Lack of committed scope – “We WILL get all this by the next month!” The Beautiful Operational Benefits Business Benefits Self-Regulating – Everyone Participates
- 49. The Beautiful! Operational Benefits Feature visibility throughout the cycle – from concept to deployment Greater representation for all types of requirements (strategic tactical technical debt related) Greater representation for all functions - non-sales/marketing including Support/ Engg! Better PM and Engg Collaboration - Commitment by Engg teams based on joint-planning/ Work on “truly relevant” requirements by PM team Up to “the last responsible moment” Prioritization by sales/ mgmt/ customers Focus on Test Automation and Continuous Deployment Overall Quality/ Stability of Product Complete change in management style! Focus on value/ customer sat rather than estimates, productivity, NEXT RELEASE!! 49 © Digite, Inc.
- 50. The Beautiful! Business Benefits Faster time to market Faster feedback loops Better overall product/ market fit Improved sales/ customer expectation management Customer Satisfaction/ Growth! Deliver VALUE! 50 © Digite, Inc.
- 51. The Beautiful! Sales/ Customer/ Engg – PM Management – PM
- 52. Q&A Contact Information [email protected] @maheshsingh Learn more at www.swiftkanban.com www.digite.com Connect with us Twitter - @swiftkanban/ @digite Facebook – www.facebook.com/digite Blogs and Articles The Principles of Kanban Method Kanban Applied to Software Development Personal Kanban Scrumban Kanban vs. Scrum 10 example Kanban boards Explaining Cumulative Flow Diagrams Your Family, Agile, and You Kanban Communities Kanban Dev Group Lean Agile Group Lean Development Kanban-Ops IT Kanban 52 © Digite, Inc. About usAbout Kanban
Editor's Notes
- #21: Our initial expectations were low – we were unsure of what we would get with the use of Kanban.However, we felt we should get the ‘usual benefits of kanban’
- #22: Initial board – We started with what we had (this is not an exact representation – but it is close enough)We ran with that for about 8 months. And then things started to fall in place….Challenges – Cards were not getting to the Ready Queue – because PM thought they were not ready!Cards that were in the ready queue were not moving because Engg thought they were not ready! Cards were moving back from Ready to the Backlog because we discovered they were too big/ too complex to be taken up at that time.All of the Work being done by the PM team (and Engineering) PRIOR to the board was not being represented.So, we decided we needed to change that.
- #26: Separation of Planning (scoping/ estimation/ specing) from Execution (Dev/ QA)Specific columns for to recognize work already being done – but not in an organized manner. Greater pressure on PM/ Engg to collaborate early on – and estimate, get final prioritization and commit to it.The visual nature of the environment – combined with business rules we put in place – ensured that these steps got done!
- #27: We also detailed the workflow and we introduced changes in the Engineering processes to ensure thatJUnits were being written/ executed Functional Test Automation was being done by the developers before the task moved to QA.Code Review was being done – both product code and automation code
- #28: Most importantly, we realized that we were already doing a lot of the work that was not being shown on the board correctly. These included sudden customer requests for db scripts for them to extract data from our SaaS DB for reporting purposes. And we finally added a separate lane for the regular maintenance and refactoring work being done by Engineering.However – there was still a lot of pre-release planning work that PM was doing that was being done outside the system.PLUS – we needed a better way to analyze our priorities and define our backlog. What did we need to differentiate? What technology related enhancements needed to be done? What were the competition up to?So, we built the Roadmapping board.
- #29: We then went further upstream – and are now tracking our overall roadmap analysis on a higher level Kanban boardAnyone can contribute an ideaPut into buckets of Table Stakes, Catch-up, Differentiator/ Cool Stuff,HygieneEach release should ideally have a mix of each of these cards
- #30: Every time we start a key initiative – a new lane might get added to the board to track it separately. Once the work is done, it can be dropped.