Kanban : optimising for predictability
•Download as PPTX, PDF•
1 like•3,375 views
How to turn small tasks into a predictable flow of deliverables and use lean principles to experiment, measure and learn in the process.
Recommended
Recommended
More Related Content
What's hot
What's hot (19)
Similar to Kanban : optimising for predictability
Similar to Kanban : optimising for predictability (20)
More from Nexer Digital
More from Nexer Digital (20)
Recently uploaded
Recently uploaded (20)
Kanban : optimising for predictability
- 2. Topics Principles & Definitions Visualising workflow Limiting work in progress (WIP) Measuring & Reporting Continuous improvement Benefits to Kanban Q&A (if I can)
- 3. Topics Principles & Definitions Visualising workflow Limiting work in progress (WIP) Measuring & Reporting Continuous improvement Benefits to Kanban Q&A (if I can) LEAN
- 4. Principles & Definitions “A methodology for managing the flow of work to allow for evolutionary change” Is based on visualisation Follows a pull not push principle Believes in constraining the process to improve predictability and quality Has continuous improvement at its core
- 7. Visualising workflow A set of columns that are defined by the team
- 8. Visualising workflow They are activities and not job roles
- 9. Visualising workflow Work in progress
- 10. Visualising workflow Work done (in the buffer)
- 15. Visualising workflow “Houston we have a problem!”
- 16. Visualising workflow WIP limits / constraints
- 17. Limiting WIP Following a lean principle Kanban limits the work in progress to encourage a JIT delivery of features from one stage to the next
- 18. Limiting WIP Limits can be controversial in is almost certainly why Kanban adoption fails. Some calculations can be done as a starting point for how teams should set their limits – DEVELOPMENT = ½ of development resources • This encourages paired programming, better training and knowledge share amongst the team and ultimately better quality code – ANALYSIS/ELABORATION = ½ of development limit – TESTING = 2/3 of development limit – DEPLOYMENT = 1
- 19. Limiting WIP Limits can be controversial in is almost certainly why Kanban adoption fails. Some calculations can be done as a starting point for how teams should set their limits – DEVELOPMENT = ½ of development resources • This encourages paired programming, better training and knowledge share amongst the Agencies = team and ultimately better quality code – ANALYSIS/ELABORATION = ½ of development limit – TESTING = 2/3 of development limit – DEPLOYMENT = 1 3 stories for every 4 devs.
- 22. Limiting WIP: Example BA or Dev resource could help to test to clear this bottleneck
- 23. Limiting WIP: Example Pull = Flow
- 24. Measuring & Reporting We use Cumulative Flow Diagrams to assess: – Bottlenecks – Lead time – Cycle time From these we can determine where we need to address issues in quality, invest in training or add additional resources to the team Reporting is done daily so we start seeing feedback very quickly
- 26. Continuous Improvement Continuous improvement is about polishing with tiny changes. It is not about drastic changes to processes and systems. It can be project specific in terms of tools or resources. It could be more generic, such as knowledge sharing and fostering a culture of collaboration. The following are the things that I believe can make the biggest impact…
- 27. Continuous Improvement: CI Get as close to one click deployments as you can Train a DevOps team to be responsible for regular deployments Consider innovative approached to infrastructure making it easy to setup and teardown environments Invest in automated testing at both unit and functional levels that can be executed at deployment Focus on zero downtime deployments
- 28. Continuous Improvement: T-shaped People Its important to embrace that we can all do more than our job title – – – – As a BA I can do some testing. I could even do a little bit of HTML!! Our designers can do HTML Our HTML people can do some designing Our developers could test each others code
- 29. Continuous Improvement: T-shaped People Its important to embrace that we can all do more than our job title – – – – As a BA I can do some testing. I could even do a little bit of HTML!! Our designers can do HTML Our HTML people can do some designing Our developers could test each others code All of you could do my job, it’s easy ;-)
- 30. Benefits to Kanban The output of deliverables becomes predictable – Which means forecasting becomes predictable – In theory the process also becomes scalable to increase predictable outputs It breaks down walls and encourages ‘team delivery’ – Everyone is focused in shipping features, not just the guy at the end of the process It encourages greater collaboration and innovation – Teams focus on finding leaner ways of doing things that take less time or cost less
- 31. Q&A If we have time...
Editor's Notes
- A lightening lunch presentation by Jamie Clouting (Technical Consultant) to Sigma UK. December 2013.
- Quote is from the BABOK Agile Extension.It’s important for the team to see the board and understand the state of play. I personally prefer physical boards but this can have issues for teams that are in different locations.RH columns have to pull from the left. LH columns can not push to the right.
- This is a board based on some photos of Kanban boards at Yahoo.Image from: http://www.agileproductdesign.com/blog/2009/kanban_over_simplified.html
- If you have used Trello or other project management tools you’ll have seen something like this.
- We have a column for stories. These can be considered “Waiting to play”.The team should define what these are. Do we need design, architecture, research etc?
- These activities do not have a one-to-one mapping to an individual’s job titles – this will become clearer when we discuss limiting WIP.
- Cards that are in progress are above the line (or sometimes in a left hand sub-column) as you’ll see later.
- Work that is done and is ready to be ‘pulled’ is sat in the buffer below the line (or in the right hand sub-column).
- I personally count this as the time it takes a story to get into the first phase of the cycle. Based on this example it would be 4 days.
- Cycle time is measured from the time it takes to get from the first phase of the process to done. In this case 14 days.Why is this important? Because I know for every story that goes on the bottom of my backlog it will take 4 days to get to the top and once in progress it’ll take 14 days to get to done. This means I can plan, set expectations and have a good idea of the revenue associated to this story.
- Sometimes 18 days is too long. We find a bug. An API we’re dependant on changes and we need to react. It becomes our #1 priority.
- We set some limits of how many stories can be in any column at a time. Lets look at this now…
- This one here is done. The one behind it is having the light bulbs fitted. Behind that the doors, behind that the wheels.They probably come off the production line at one every 20mins…
- This maths is a stab in the dark. If you don’t know where to start, start with what you have now… which is probably 1 resource = 1 card and make a plan to change this asap.
- Paired programming is amazing but we’re not google. 3 stories per 4 devs probably gives a ‘senior’ dev the ability to float between the team giving support where needed.
- Here is our example Kanban board
- Bottlenecks in test is preventing anything downstream from progressing. This is not a time for Analysis and Dev to pat themselves on the back. The team need to configure themselves in a way that means they can support the test function, on the understanding that this may take extra time as it’s not their area of expertise.
- We’ve supported the testing function by switching the focus of some of the team from their primary skill area to a secondary skill area.
- The impact is that everyone downstream can now pull a card.
- Metrics allow us to track our progress and see the impact on bottlenecks. It also allows us to see the impact of making improvements.
- Flow can be measured using CFDs or Cumulative Flow Diagrams. These diagrams can be really useful when attempting to analyse flow through the board and identifying areas for improvement.The following diagram shows a simple but accurate example of how a CFD can be used to show the amount of tasks in each lane over the duration of the project. we can see that at the beginning of the project the backlog was large (to-do), the in progress work was very small and there was no work completed. On days 6, 11, 20 and 24 deployments were made pushing work from in progress to done.
- This is something that we should be thinking about regularly. What have we learnt in the past, what could we improve.Why do we do things the way we do them now?Can we do them betterCan we train people to do things better
- This is probably the number one are to invest in if you want to BE agile. I’m not talking about saying we DO agile. Forrester asked companies “how long does it take to get 1 line of changed code into production?” from this they were able to determine true agility.DevOps: http://en.wikipedia.org/wiki/DevOpsGDS – Regular Releases Reduce Risk http://digital.cabinetoffice.gov.uk/2012/11/02/regular-releases-reduce-risk/
- Chris would draw this better but I came up wit this…
- *grins*
- For us as an agency the benefits are around predictable billing.To a team like GDS its about being able to do maths on the number of stories you have to do and understanding when they will be finished, predicting what will make it into each release with some degree of certainty. Etc.