Evolving a process for product development - from "X" to "X-ban" #lkuk14
•Download as PPTX, PDF•
1 like•1,287 views
The principles and practices of Kanban provide a “metaprocess” that helps you define useful experimental changes to your initial process that, if they prove successful, are adopted permanently into the evolving practice. So if you are trying to apply a named process in your development team, but frustrated by a patchy track record of performance improvement, consider the alternative: xBan it! This session draws out the lessons learned from working with a product development team that had recently adopted Scrum, though only to a quite shallow extent because of constraints that derived from the business context. Improving this process could have followed the classical approach of defining the “process gaps” between the actual and the assumed “ideal” process, the gaps becoming backlog items in as a “Transformation Backlog” which, when implemented would eventually result in the desired process being achieved. However we took a different approach. We decided to “x-ban” our process in other words use Kanban to attain evolutionary changes that we kept only if we were confident they resulted in improvements. The proposed changes came from the team themselves rather from a gap analysis and the rate of change was steady rather than rapid. Nevertheless the results were encouraging and reasonably surprising (the process is more Scrum-like now than when I arrived for example!), and it’s a route I’d recommend to others looking for effective improvement of development processes.
Recommended
Recommended
More Related Content
More from Andy Carmichael
More from Andy Carmichael (9)
Recently uploaded
Recently uploaded (20)
Evolving a process for product development - from "X" to "X-ban" #lkuk14
- 1. X-Ban the process! (How a Product Team is improving value delivery rate with Kanban) Dr Andy Carmichael Head of Agile Services, Clearvision-CM.com @andycarmich - #lkuk14
- 2. Why is this relevant to me? • Job title: Head of Agile Services, Clearvision (since May 2013) • Role: Development Manager; Product Owner for Spectrum ALM* • Nominally a Scrum development process when I arrived • Spectrum 1.0 released January 2014 • Spectrum 1.2 released Autumn 2014 We needed a process that would allow us to deliver the next most important product feature to quality… faster *spectrumALM.com
- 4. Key concern over this time… How do we improve our development processes to meet the business imperatives? • Speed • Agility • Efficiency • Responsiveness • Forecasting Two typical approaches to improving process 1. Pick a new one … migrate to it 2. Start here … improve (x-ban) it!
- 5. Identify the problems • Retrospectives and reflection • Feedback loops • Purpose & Focus
- 6. Improvement • Improvements suffer the J-Curve syndrome • Small step improvements (Kaizen) may alleviate deep dips in performance • Radical change might also be needed (Kaikaku) but may not “stick” • Kanban is an IMPROVEMENT method based on the Lean flow paradigm
- 7. E.G. – Scrumban – Xanpan (XP-ban) – Princeban? – DSDMban? What does ‘X’ban mean • Is it a “pick and mix”? • Is it a specific set of practices from both sources? • Is it the same in every implementation?
- 8. What is Scrum? Source: http://www.controlchaos.com Max 1 month Potentially shippable increment every Sprint
- 9. • Rules (Scrum Guide) • Roles Scrum: an “Empirical Process Framework” (Scrum Master, Product Owner, Dev Team) • Rites (Planning, Stand-up, Retro, Review, Sprint) • Artifacts – The evolving “Increment” – The Backlog • The rules are “immutable” • If it’s not all Scrum, it’s not Scrum (Scrum-but)* • Not specific about technical practice but … • Requires “potentially shippable increment” every Sprint (< 1 month) * “There are no flavours of Scrum” Jem D’jelal
- 10. What is Kanban?
- 11. What is the Kanban Method*? A framework for process change (a metaprocess?) 1. See work as FLOW (Kanban Lens) 2. Start from here (roles, responsibilities, process) 3. Make work and policies visible (e.g. board, WIP limits) Make validated changes (e.g. change WIP limits or DoD) Viewpoint Principles Practices *cf. a kanban; a kanban system; the Kanban Method
- 12. Make work and policies visible • Where did we start? • Visibility of work (and policies) • Awareness of interruptions
- 13. So what is Scrumban? • Portmanteau word coined by Corey Ladas (Scrumban, Modus Cooperandi Lean Series, 2008) • The evolution of a process that would take place if a team was using Scrum and adopted Kanban Also used in the community to mean a method made from aspects of Scrum and Kanban (less usefully!)
- 14. Some of Ladas’s expectations of what could happen to a Scrum process… • Specialisation in teams • efficiency without loss of focus in continuous delivery of features • balance between self-organisation and workflow specialisation • Relaxation / disappearance of the time-boxed iteration (Sprint) • varying cadences for different functions according to need • “batch and queue buys you nothing” • Scope of the workflow expands • not just development/test but “concept to cash” • Limiting WIP with small buffers • towards the ideal of one piece flow • defined workflows, flexible hand-over – the “bucket brigade”
- 15. Single piece flow… variable handover
- 16. A recent tweet from @corey_ladas
- 17. Understanding flow… and lack of it
- 18. How has our process evolved? • From “user stories” to “epics and stories” (above the epic?) • Limits on WIP – less, more, less • Staff liquidity and roles • Emphasis on cadence • Reviews with stakeholders (monthly – queue replenishment) • Retrospectives monthly (moving to the other fortnight!) • Deliveries – moving from batches to “when ready” as CI/CD improves • Forecasting still elusive… why? does it matter??
- 19. From “Scrum-BUT” to quite Scrum-like? • Cadence – • renewed emphasis on the monthly cycle (was 4 weekly) • Roles – • Product Owner role clearer, • still no Scrum Master • Staff Liquidity emphasis • rather than cross-functional team members • Potentially shippable increment • on the completion of any Epic • moving to Octopus builds
- 20. Change did not come quickly! • Reflection • Consensus • Shared understanding • More courage required (just do it... undo it if necessary) • Change based on evidence sticks better • Saying is not communicating
- 21. How can you x-ban your process?
- 22. Kanban: Twitter Version Essence of Kanban see flow start here with visible work & policies validate improvements Also see: "How to Adopt Kanban" @andycarmich
- 23. X-Ban the process! (How a Product Team is improving value delivery rate with Kanban) Dr Andy Carmichael Head of Agile Services, Clearvision-cm.com @andycarmich - #lkuk14
Editor's Notes
- Evolving a process for product development from X to Xban Andy Carmichael @andycarmich The principles and practices of Kanban provide a “metaprocess” that helps you define useful experimental changes to your initial process that, if they prove successful, are adopted permanently into the evolving practice. So if you are trying to apply a named process in your development team, but frustrated by a patchy track record of performance improvement, consider the alternative: xBan it! This session will draw out the lessons learned from experience of working with a product development team that had recently adopted Scrum, though only to a quite shallow extent because of constraints that derived from the business context. Improving this process could have followed the classical approach of defining the “process gaps” between the actual and the assumed “ideal” process, the gaps becoming backlog items in as a “Transformation Backlog” which, when implemented would eventually result in the desired process being achieved. However we took a different approach. We decided to “xban” our process in other words use Kanban to attain evolutionary changes that we kept only if we were confident they resulted in improvements. The proposed changes came from the team themselves rather from a gap analysis and the rate of change was steady rather than rapid. Nevertheless the results were encouraging and reasonably surprising (the process is more Scrum-like now than when I arrived for example!) and it’s a route I’d recommend to others looking for effective improvement of development processes.
- Scrumban, Xanpan (XP-ban) - even Prince-ban and DSDM-ban - have all been used as portmanteau words to explain the journeys from a particular named process or framework to a continually evolving and improving process, guided by the principles and practices of Kanban. If you are trying to apply a named process but frustrated by a patchy track-record of improvement, consider the alternative: x-Ban it! When I was asked in early 2013 if I would work with a product development team, they had just adopted Scrum (a matter of weeks before). Their process, like most I’ve reviewed from teams claiming to use Scrum, was not compliant with a large number of Scrum rules. It was pragmatic, constrained, variably applied and ripe for improvement... but it certainly wasn’t Scrum. We had two choices - apply Scrum rules as soon as possible (defining the backlog of necessary changes and a timetable to apply them), or “x-Ban” it (use Kanban to attain evolutionary changes that we kept only if we were confident they resulted in improvements). We did the latter. This session will draw out the lessons learned from this experience, sharing what worked - and didn’t work - for us, and general principles that others can apply on a similar journey. It has taken much longer to adopt some practices than I expected, the current process is quite different than I expected 18 months ago (it’s more Scrum-like now than when I arrived for example!), but it is a route I would recommend to others. Start x-Banning your process now!
- Hybrid processwords like “Scrumban” and others people use like Xanpan (XPban), Princeban, DSDMban, even Waterfallban are not so much hybrid processes (elements of Scrum with elements of Kanban for example), but rather descriptions of how development processes can change as the Kanban Method is used to transform the process or framework through continuous improvement. Let’s look at Scrum, Kanban and Scrumban in more detail
- What most people think of when you say Kanban. More columns. WIP limits. Visible policies. Classes of service
- Don’t just learn methods from tools vendors and the method’s critics. Learn from the authors first.
- At least for a time both methods fully in play. Ladas imagined one trajectory – others are possible (more likely?