I was thinking what the title of this blog post could be, I had couple of options to select from and decided to use a title that uses Disciplined Agile (DA 2.0) Lifecycle. Other options for titles were:
- Moving From Scrum to Kanban
- From High Performing Scrum Teams to Hyper Performing Kanban
The bottom line is that at some point you may want to move away from Time boxes to a flow of work and service oriented teams and improve performance and throughput without massive and sudden organisational change. As always, I only share my experience and this may not apply to all situations, context is important.
Another reason that I selected “Moving from Basic DAD Scrum Based LifeCycle to Continues Delivery (Kanban Based) Lifecycle” as the title, was that for many it is a question mark how to navigate through DAD life cycles. and I think this blog post could be one of the ways to navigate.
Context:
- A Delivery Team started with Type A Scrum with 2 weeks Sprints. After a while, they deploy their solution to production and continue with new development while maintaining the solution on production.
- the Delivery Team is cross functional, but it also uses expertise from outside of the team. Expertise are either within the same organisation or they are external.
- there are dependencies to external specialities such as system engineers, deployment managers and other stakeholders.
- other teams are depended to this Delivery Team as well. For example Support and Maintenance team will need the delivery team for 3rd level support and they must be able to meet their SLA.
- After a while, the delivery team and all other involved parties grew to 25+ members and several Product Owners.
- the team started to not only working on new development, but also on refactoring current solution, making small adjustment or changes on ad-hoc bases, and fixing reported incidents on production.
- the Delivery Team is operation within project based company, their product owners are at Client side. And Every 3-6 months there is a new budget for future development.
It took a while for client and The Delivery Team to get use to basic agile concepts, and learning is ongoing. However, after a while both Client and the Delivery team started to take retrospective and continues delivery more seriously. And an ongoing improvement momentum started. One of the improvements was about making sure that Stories are in Ready Shape before committing to them. Therefore added to their definition of Done they have also defined Definition of Ready with INVEST criteria explicitly defined. They have also take Definition of Done more seriously and made sure that they meet DoD at all times - No Excuse. Not Meeting DoD created several stressors to the whole system that caused improvements. They have also started to monitor their Continues Delivery Maturity Model and agreed with Product Owner to create more improvement stories in the backlog.
After a while, they found themselves in a Scrum Type B as more refinement, Spikes, Look Ahead Planning, and POC’s was put in place. Then, they started to implement some of the Advanced Scrum Patters to increase their performance. They learned that Scrum is not about Velocity but it is about Positive Acceleration in Velocity (Delta Velocity of each Sprint), They realised that an Accelerating Team soon outperforms a team with flatline Velocity. Physics 101. Therefore, they identified and selected patters that enables acceleration and started to apply them one by one.
As the team had high turn over, they decided to do something about it and keep the team as stable as possible, therefore they decided to implement Happiness Metrics into their Retrospective and aggressively implement what they agreed on. Happiness Metrics was not only about Being Happy! But it was about Job Satisfaction. After Several rounds of Retrospective, they realised that what makes the team unhappy, or what the team suggests to do in order to improve happiness are all related to Purpose, Autonomy and Mastery. they all wanted to do a good job that they are proud of and wanted to improve their skills so they stay relevant and feel significant.
They also started to set higher Goals based on past performance and past Velocity. They looked into the past Velocity and Set a new goal based on that (Yesterday’s Weather pattern). However, at first they saw their Velocity increased without real impact to their performance, and this was because of the fact that in the past they have not measured all the activities they were doing, so some work was measured as Story Points while others were done without even a ticket on the wall or in their JIRA. But when they started to capture everything and measure everything then Velocity increased, now it was time to do real improvement to increase REAL throughput.
To prevent Story Point Inflation, they set Reference Stories and started to calibrate their estimation. They selected 2 three story Points story, 2 five story point stories, and 2 eight story point stories.
Next they started to look to each improvement as an experiment. They started to use Kaizen Pulse Pattern. If an improvement met its goal then they set it as a standard, and tried to improve on top of that, Else they discarded the improvement and rethought again. They use Scrumming the Scrum pattern to make sure they have backlog of experimental improvements in place with time-boxed.
Next, they started to apply "Swarming: One Piece Continuous Flow” pattern and committed to less stories to be able to finish them. While improving, they started to commit to more stories as well. One of their challenges was interruptions from Product Owners, Deployment Managers, Support Managers and many more. Therefore they started to use another pattern to handle these interruptions (Interrupt Pattern: Illigitimus Non Interrupts) And they set Interrupt Pattern rules:
- The team creates a buffer for unexpected items based on historical data.
- All requests must go through the Product Owner for triage. The Product Owner will give some items low priority if there is no perceived value relative to the business plan. Many other items will be pushed to subsequent Sprints even if they have immediate value. A few items are critical and must be done in the current Sprint, so they are put into the interrupt buffer by the Product Owner.
- If the buffer starts to overflow, the team must automatically abort, the Sprint must be re-planned, and management is notified that dates will slip.
Another challenge they had was bad programming practices. Very Large Classes, not following coding standards, no code reviews, minimum refactoring, known bugs were not resolved and etc. So, they agreed to apply Clean Code pattern. And they reduced known bugs from 100+ to Zero in short period of time. And decided to never let it go beyond 10.
To create another level of acceleration, they started to apply “Teams that Finish Early Accelerate Faster” pattern in combination with all other patterns that they have applied so far. This last improvement, created a pull system for the team, as they started to commit less and started to pull more work from the backlog before the end of the sprint. Until this time, none of the team members (including Product Owners) were comfortable with committing less and pulling work. But, after couple of Sprint, everyone was talking about Pulling work. It became a standard way of working and Pull get into the daily vocabulary.
To monitor their progress they started to experiment with High Performing Metrics and changed the Daily Scrum. They did not go through each team member and they stopped answering what I have done yesterday and what I am going to do today and what obstacle I have. Instead, Scrum Master, started to go through Sprint Backlog items from the top (high priority) and asked the following questions:
- What we have done on this Stay since yesterday?
- Different members started to talk and shared what they have done.
- Since, they pulled less work, therefore there was more time to explain what was done, and this increased other team members awareness of what work was done and what changes other team members have done to the system. Increasing Knowledge Sharing and Awareness of the team.
- Then Scrum Master, Asked How many story points did we do on this story yesterday?
- As more people were aware, therefore more people could estimate - similar to Planning and refinement sessions.
- Scrum Master Collected these numbers on the board, for later use in statistics.
- Then Scrum Master asked what we will do on this story today?
- And if there is any Risk for this story that we will need to pay attention to ?
The focus during Daily Scrum (Coordination Standup Meeting) went from individuals to actual work. Collected numbers feed several Metrics automatically, and generated result based on the following formulas which could be used for Retrospective:
- Velocity: ∑ of original estimates of all accepted work
- Work Capacity: The sum of all work reported during the Sprint, whether the Backlog Item toward which the work was applied finished or not.
- Focus Factor: Velocity ÷ Work Capacity
- Percentage of Adopted Work: ∑(Original Estimates of Adopted Work) ÷ (Original Commitment for the Sprint)
- Percentage of Found Work: ∑(Total Work Reported Per Card - Original Estimate) ÷ (Original Commitment for the Sprint)
- Accuracy of Estimation: 1-(∑ (Estimate Deltas) ÷ Total Forecast)
- Accuracy of Forecast or Commit: (∑Original Estimates) ÷ ∑ (∑ Original Estimates + ∑Adopted Work + ∑Found Work)
- Targeted Value Increase (TVI+), Productivity Improvement: Current Sprint’s Velocity ÷ Original Velocity
- Success at Scale: For each Point on the Fibonacci Scale (Fp), the formula is: (∑ No. Accepted Attempts of scale Fp) ÷(No. of All Attempts of scale Fp)
- Win/Loss Record: Each Sprint is a Win only if: a) A minimum of 80% of the Original Forecast is Accepted and b) Found + Adopted Work During the Sprint remains at 20% or less of the Original Forecast.
This allowed the team to see how much work they could commit, how much work was adopted during the sprint, how much work was found - meaning estimations were more optimistic during planning /refinement session. And give them a chance to ask why and what could we do to reduce the gaps.
Other Metrics they have started to collect and monitor were:
- Sprint Burn-Down chart
- Open Defect Trend
- Defect Resolution Lead Time
- Closed and Open Defect Statistical Distribution
- Continues Deliver Maturity Model Assessment
- Release Burn-Down Chart
- Ticket Lead Time: From acceptance to Backlog to Delivery.
- Ticket Business Analysis Lead Time: From Submission to Idea Backlog to acceptance to Development Backlog.
- Cumulative Flow Diagram: Measuring and Showing amount of tickets in Idea & Analysis, Backlog, Done(Ready For Production), Completed in Prod.
With all of these improvement, now team was at its pick performance. They started to observe and identified a fact, they realised that time-box was a waste for them at this stage. It turn out that there were stories that they could work on at the last day of the Sprint, but nobody started them because they were sure that they will not be able to finish them by the next day. Sometimes it happens to all team members and sometimes to a few of them.
So, they decided to move to Scrum Type C, where there are more overlapping Sprints. Hence more preparation for the next sprint and more focus on Story Readiness. However this was not enough either, therefore instead of focusing on reducing the gap between Adopted Work and Planned (committed work), they decided to increase this gap by increasing their Buffer. they started to Commit even less and less at planning session. they committed only enough that most (and not every one) were engaged in working. Such a increase in Buffer and committing less allowed them to increase Pulling Frequency.
Next, they agreed with Product Owner on pulling work that they could not finish by end of the sprint. They did that only at the last 1-2 days of the sprint, and only if all other committed work was already done.
Then, they added maintenance work and other activities that were not in the Scrum backlog to their work. Therefore they needed different Streams of development with different cadences. In order to be transparent and more effective, they had to clearly define how they deal with each work item at every stream of development, and therefore they started to created Explicit Rules.
Then, they agreed with other Domain Experts and 3rd parties to create a Kanban between them. So, Delivery team could request for a service and 3rd parties could deliver the service within a defined set of rules. Such an agreement also allowed all parties to focus on Overall Lead time of work. Later on they added a Discovery Kanban for business and Marketing , so they can also created new service request and only after evaluation of the risk and preparation, then team pulls the new ideas into the Sprint.
Adding SLA based maintenance to the equation allowed them to define clearer Classes of Service. Therefore by this time, they defined upstream Kanban for business, and down stream Kanban for other 3rd parties such as Operation engineers. The last step was agreeing with all stakeholders to move completely to a Continues Delivery and Kanban model for the Delivery Team. And after completing that step, they created a network of Kanbans to operate even faster than before.
They all lived happily ever after :)
 |
| The Kanban board designs here are very simple example, just for the sake of this blog post to show how this team created network of Kanbans, and not an actual useful design. |
Comments