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
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.
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
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.