Scrum is good - but kanban is better
•Télécharger en tant que PPTX, PDF•
1 j'aime•514 vues
Scrum is a great way to start practising Agile. But it's not perfect. Are you struggling to get stories tested within the sprint? I sprint planning taking hours and making everyone miserable? These are the slides from the session I presented at Agile Cymru 2016, describing the experience of one team that moved from Scrum to Kanban.
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à Scrum is good - but kanban is better
Similaire à Scrum is good - but kanban is better (20)
Dernier
Dernier (20)
Scrum is good - but kanban is better
- 1. is good… Neal Champion Application Development Consultant, Microsoft …but Kanban is better
- 2. My Perspective • Based on personal experience – yours may differ • There are no right answers • Most significant impact of Agile is retrospection • Agile is mostly a cultural revolution • Culture is complex • Slow to change • Difficult to measure Team I learnt this with
- 4. Background of Scrum •Around since the mid-90s •Gateway drug to Agile •Easy to understand •Easy to implement •It works! •Has almost become synonymous with Agile •…but it’s not perfect
- 5. Problems we found with Scrum •Sprint Planning Hell •SqueezedTesting •Stories not completing in Sprint
- 7. Sprint Planning Hell •Developers unhappy to commit or estimate until they understand : • Detail of Requirements • Technical solution •Sprint Planning became: • Requirements Analysis • Design Meeting
- 9. SqueezedTesting • Testing cannot happen until the code is written • Any earlier overrun squeezes testers out the back of the sprint • Testers get the blame when stories aren’t ready
- 10. Story Overrun • Symptom of previous issues • Analysis and Design squeezed out of the front • Testing squeezed out of the back • Sprint just became development • Carried-over Stories make SprintVelocity harder to measure
- 11. Root Causes • Scrum does not differentiate between individuals’ skillsets • Scrum doesn’t acknowledge dependencies between tasks
- 13. Our First Kanban Flow •Acknowledgement that each story at least requires: • Analysis & Design – which we called Elaboration • Coding • Testing
- 14. Our Kanban Board
- 15. AWord aboutWIP •Work in Progress (WIP) should be limited •“Stop starting, start finishing” •Incomplete work is “wasted inventory” •Multi-tasking is bad!
- 16. Multi-Tasking Exercise • 1 • 2 • 3 • 4 • 5 • 6 • 7 • 8 • 9 • 10 • A • B • C • D • E • F • G • H • I • J • I • II • III • IV • V • VI • VII • VIII • IX • X
- 17. Definition of Done •Scrum often has a Definition of Done for a whole story •With Kanban, we had a DoD for each step in the process Elaborate • High level design • AcceptanceTest Criteria Dev • Feature complete • Unit tests met • Peer reviewed Test • AcceptanceTest Criteria met • NFT reqts met Review • Business Reqts met
- 18. #NoEstimates !!!
- 19. The Estimation Holy Wars •Estimating is a divisive topic! •We sized stories on the backlog in simplyT-shirt sizes •Following the Elaboration phase, we knew more, and re- estimated, using points
- 20. Valuing Stories
- 22. What we found •Coped better with variable story size •Coped better with urgent work - bug fixes, production issues •Elimination of Sprints allowed everyone to work continuously
- 23. Fit with Continuous Delivery •Scrum is a batch process •Kanban is a continuous process
- 24. Questions?
Notes de l'éditeur
- I currently work at Microsoft as a technical consultant, advising Microsoft customers on development matters. But that’s not what this session is about. My background: developer, then architect, then team lead. First read about agile in late 90s, instant recognition. Started practising Agile early 2000s, led Agile teams from 2006/7 on. Certified Scrum Master I do not have a magic wand. I am simply relating my experiences with a mature dev team In my opinion, they single most important thing about the Agile Revolution is retrospection. The application of the scientific method to how we work – have a theory, create an experiment to test it, look at the results ASK the Audience – why are people there?
- Hands up if: You’ve worked in, or closely with, a Scrum team You’ve had some issues with Scrum If you’ve used Kanban with a real team
- Jeff Sutherland and Ken Schwabe codified scrum in 1995 [They inherited the name ‘Scrum’ from the ground-breaking 1986 paper ‘The New New Product Development Game’ by Takeuchi and Nonaka] Terminology has entered mainstream - Backlog and Sprint are in common parlance
- Skip this if everyone familiar with Scrum
- The team was a mature Scrum team – we’d been running Scrum for several years, and with two week Sprints, that was a lot of Sprints. But our retrospectives kept raising the same issues
- Ref Joseph Petrine’s session on Pyschological Aspects of Estimating. Anything more than 90 minutes is wasted!
- Simple story (As a User I want to…) turned meeting into Requirements Analysis Tried asking analysts for more detailed requirements to bring to Sprint Planning This turned Sprint Planning into Design Meeting “Solution Design” brought to Sprint Planning – this required tech staff to do work outside the Sprint
- Not entirely relevant to my point, but it made me laugh.
- Relevant to the Dilbert cartoon – testers often end up being the bearers of bad news. And culturally, that is a hard job to do – no one likes to be the person who says “No”.
- Most development teams are development-centric, for obvious reasons. If the team has this focus on writing the code, everything else becomes a necessary evil. Scrum doesn’t really address this, imo Culturally, it’s important to get the whole team to focus on the end goal – well designed, well written and thoroughly tested shippable code, that has value Options for measuring velocity with carried over stories
- Actually, the original paper “The New New Product Development Game” by Takeuchi and Nonaka assumes a multi-disciplinary team handing over to each other’s areas of expertise. But I don’t think that Scrum, as most people implement it for software development, really takes individual skills into account The combination of these two problems led us to look at Kanban.
- The typical scrum board just divides activity into three – to do, doing, and done. This level of granularity is not detailed enough To understand the state of a story, you need to examine the tasks, and understand the connections and dependencies between them
- We also added Review as the final stage, so that the implementation could be checked against the original business requirements with the owner of them/the idea
- Should be familiar to anyone who has read anything about Kanban. But for those that haven’t, here’s some key points: Each step that requires some activity has a column Each column is divided in two – Active and Done Flow is left to right
- Give car maker analogy – making doors faster than they can be fitted results in a pile of doors, which is wasted inventory Scrum limits work in progress by selecting all the stories for the Sprint at Sprint planning. But that is based on estimates and incomplete knowledge; sometimes stories are bigger than expected, sometimes small. Kanban allows work to be pulled as people have capacity to do it.
- Do multi-tasking exercise here? Write down 3 columns – 1 to 10, A to J, I to X (roman); then turn the paper over and do them horizontally
- We had an fortnightly initiation meeting for new stories, and sized them in t-shirt size. That was good enough to figure if they were cost effective
- The Product owner was measured on two aspects of our site – engagement (how often people visited) and commercial (if we made any money from features). So all new work was assessed against these two criteria
- From this, the high value stories were prioritised. At this stage we didn’t worry too much about size – we wanted to do what was valuable / important. But we did include some small stories that could be picked up and done without taking too long, to give us a mix of effort required.
- Scrum is really not that good with dealing with bug fixes on production systems. With Kanban, we created a separate horizontal swim lane for bugs and other high priority production work. Within a Sprint, the elaboration is front loaded, and testing back loaded. Without the Sprint, everyone can work on tasks using their skills continously
- With Scrum, you typically only release at the end of the Sprint. This is at odds with the way the industry is moving, which is towards a model based on continuous delivery With Kanban, you can release each story as it is completed (assuming no cross dependencies) Our release process wasn’t mature enough to support Continuous Delivery, so we released once a month. A few days before the release, we looked at the stories that were ready to go, and decided on what was to be included, and what wasn’t. So the continuous Kanban development process fitted with a batch release process.