Anyone who has worked on any Agile project knows that it can be challenging to implement Agile. Pressures upstream, reluctant individuals, and organizational maturity can all play a role in derailing a smooth process. In most instances, we can overcome this through education, collaboration, inspection, and adaptation.
But not always.
In some projects and organizations, it is hard to achieve productive sprints, due to too many things beyond our control.
When Things Change Too Fast
Simply put, there are situations where there is too much change for traditional Agile/Scrum methodologies to work. The riskiest time to have a lot of change is during a sprint. This two (or so) week period is the time when developers should be able to get things done without fear of changes or new introductions that are beyond their own control.
Sometimes these last minute changes can be caused by delivery dates set outside of the Agile construct – if an item is due the 15th, but isn’t ready to go into a sprint on the first then it can’t get done unless it is added mid-sprint, or added while still incomplete.
Whatever the root cause, in these environments, preparing for the sprint timebox becomes a scramble. The consequence of being inadequately prepared is a not-quite-complete story that will likely have issues arise in-flight or during user acceptance testing.
With unprepared and ever-changing stories, many challenges invariably arise, such as:
- developer unproductivity
- quality issues
- developer burnout
- missed acceptance criteria
- buggy code
You get the idea. Projects with ever shifting requirements fail. Period.
The Need
What is needed to be successful with this kind of change is more flexible planning options, faster output, clearer focus, and transparency throughout the development cycle. The ideal process will do the following:
- lower process overhead
- use a simpler, pull-based process flow based on readiness of stories
- eliminate sprint preparation/deadlines
- implement planning flexibility and easy backlog reprioritization
- set work in Progress limits
- have continuous iteration
- eliminate key role dependencies
- utilize smaller groups, have shorter meetings
- have continuous delivery
The Solution: Lean Kanban
A good solution to address these problems is the Lean Kanban (Kanban adapted for lean development) approach. The general principle is that by eliminating the hard gate and timebox of a limited time sprint, you can stay nimble, if not completely agile. Instead of having sprint duration be the work limit, work is limited by how many stories are in progress at a given time.
To manage the work, you have a board – one that looks identical to a scrum board – showing what is going through development at the current moment in time. The main difference is that instead of closing out your sprint every two weeks, you just keep going.
This allows for changing priorities. There is freedom to reorder the priority of items in the backlog and greater flexibility in the process overall.
In order to be successful in Lean Kanban, it is important that you adapt your process from the usual Agile/Scrum processes. Specifically, you need to ensure:
- stories are ready
- teams are collaborating and communicating tightly
- teams are well facilitated
- there is data to track
If you do all of these things well, this is a solid process that can withstand a lot of chaos.
Defining Readiness Criteria
Since priorities are shifting, it is critical to create a Definition of Ready. This is the minimum amount of specification required before the developers can start working on a story. It is this definition that will ensure that nothing changes in flight. Nothing goes into development until the team agrees that it matches these criteria. And guess who determines the definition of ready? The team.
Things to consider when guiding your team and setting readiness criteria:
- Are design and prototyping done?
- Is acceptance criteria signed off by the product owner and/or client?
- Does the story meet INVEST criteria?
- Should there be any architecture or technical information attached to the story?
- Are there risks, dependencies or assumptions?
- Are we guaranteed there will be no changes until this story is shipped?
The bottom line is that the team should define what they need to have for an unhindered development process – then use this as the hard gate to determine what can be accepted by the team. The end result is that the team will ensure that this definition evolves to prevent misses and that items are ready going in and if not, everyone understands the inherent risks.
Swarm on It
Once items are ready, you should then control what is in flight. Just like determining how many points should go into a sprint, you will need to determine how many stories can be worked on simultaneously. It can be beneficial to move to smaller 4-person teams (we call them swarms), to enable greater collaboration and limit the number of stories in flight. Consider doing fewer stories than the number of developers on the team. This can mean that you have two or more developers working on a single story at once, increasing the speed at which items flow across the board. Do what works. Inspect and Adapt.
Facilitation
With the smaller swarms, you can also consider having a special facilitator role. The facilitator will be the servant-leader of the swarm, helping to remove obstacles and improve cohesion, and ideally also filling the business analyst role and writing stories. Whether you can do this or not will depend on the skillsets of the people on your team as well as the vastness of your backlog. Facilitating a small swarm is easier than scrum mastering because there are no sprint ceremonies and a smaller team means generally fewer obstacles. If you do have talented enough people, this can provide a greater linking between the story specifications and the swarms – and allows for real-time answers to requirements questions without having to get a product owner whose time is generally very limited.
Planning, Reviews and Retrospectives
Keep in mind there are no scrum ceremonies to introduce, review and retrospect your processes. You will still want to have some kind of planning and reviewing processes, as well as time for retrospectives. There are a couple of ways you can do this. If your stories are grouped together under feature-sized epics, consider having epic introductions (like sprint planning but for a single epic without a timebox), and then epic reviews and epic retrospectives when these features are complete. These replace the related sprint ceremonies, but now revolve around a larger functional portion of an app. It actually makes a lot of sense to do it this way: you introduce the larger set of functionality allowing for questions in the beginning, you review it all with the product owner(s) when it is completed, and then you look back in a retrospective to see what did and didn’t work when developing that feature.
If you don’t have those kinds of epics, look to have more frequent and shorter intros and reviews for stories (you could even append to your daily standups), and then possibly have a set time for retrospectives every couple of weeks or so to allow you to inspect and adapt for what works best for your team and in your environment.
Reporting
With Kanban, we can’t assign story points because we don’t have a sprint into which can track them. In scrum, your burndown rate is story points per sprint. Not having this heuristic can make tracking burndown and progress – not to mention planning – a little trickier. The key heuristic now is the cycle time of work in progress, or how long it takes on average to complete each story. The emphasis will begin to move to writing stories that are similar in size so that you can track based on average size.
One of the primary reports you can rely on is the “Cumulative Flow” chart. This shows how many days an average story takes. Using the rolling average along with the standard deviation will give you an idea how long it will take. The lower you can get the SD, the more accurately you can predict the number of stories you can get done in a fixed amount of time.
Conclusion
Keeping in mind the Agile Manifesto, a core principle of Agile is responding to change – and some environments have more change than others. In these types of environments, one thing you can look at is using the Lean Kanban methodology to keep teams small, eliminate sprint timeboxes, and accommodate frequent backlog priority changes.
