Scrum is a great development framework for teams focused on developing a product. If the framework is followed, the product owner will see clarified requirements, a production-ready implementation, and have a stable velocity with which to plan, at the end of the sprint. However, if the framework is not followed, and if the framework is not congruent with the actual workload and organizational environment, it may be beneficial to consider other framework options (after attempts to right the issues under Scrum have been unsuccessful).
A typical set of problems with the Scrum framework arises when the product transitions to a maintenance phase in the context of a large organization. The problem includes issues such as priority changes mid-sprint, incongruent processes between teams, unfocused work, and sprints not completing.
Priority changes can affect a Scrum team's velocity, ability to complete a sprint, and planning. Production issues may change the team's plan and incomplete work may accumulate. Organization-wide objectives or mandates may also affect the team's plan once the product has been coupled with other dependent products in the larger organization. Once the sprints become harder to complete, planning is affected because the team's velocity is unstable.
Once a team transitions to a maintenance phase, the team may have turned over support or deployments to another group. Environment changes may also be handled differently. Often, different groups within an organization are not yet operating with compatible development processes. The Scrum team may need to wait for or artificially break down a story in ways that affect the story's ability to complete within the sprint.
The Scrum team may experience a shift in the type of work required, and notice the focus of their team is not as narrow as it once was. Once a product is introduced to a larger integration of other products, the focus may broaden, other groups may introduce priorities, and the potential for interruptions in the sprint increases.
These issues can compound and make it difficult for a Scrum team to complete sprints. While there may be solutions to remain with Scrum (protecting the team and plan from interruptions, prioritizing better, pull from a good ScrumMaster notebook, etc.), these solutions won't always solve the problem completely.
An alternative approach may be to modify the Scrum team's use of the Scrum framework. While the major goals of agile and lean development still apply, and while Scrum still applies, a slight change can be made to introduce the ability for allowing more frequent changes, allowing for incongruent processes, and allowing for a broad focus of work.
Scrumban is a combination of the Scrum framework and Kanban. Information on Scrum, Kanban, and Scrumban is readily available and can prove why the approaches are successful.
If Scrumban has been identified as an option for your team, consider the following approach for transitioning your Scrum team to Scrumban.
Sell Scrumban
The first win is to get your leadership team familiar with and set up for an approval of the new framework. There are differences with a framework that incorporates Kanban practices, and the leadership team will need to feel comfortable with the changes.
During your pitch, cover the following topics to help influence the decision: Current problems team faces with Scrum, solution options, pulling work, the value stream, Kanban, and lastly Scrumban. Lean principles should also be incorporated throughout the discussion.
The current problems should be identified as areas with which Scrum has difficulty helping. A team often facing priority changes during a sprint, incongruent processes between the Scrum team and external teams in the organization, broad objectives, and incomplete sprints are typical issues maintenance teams face under Scrum. These problems may be solved by protecting the team, or with a more influential Product Owner, but these issues can go beyond the reach of the ScrumMaster and Product Owner.
The options should include ideas shuch as allowing for more frequent changes during the sprint, allowing for incongruent processes in the near term, and allowing for unfocused and broad objectives.
Once the problems and their potential solutions are identified, ensure the team understands the subtle difference between pulling work and pushing work. Highlight that pushing work task by task onto the team only allows the team to focus on those individual tasks. Pulling work gives the team more ability to view their work in the context of the larger system, and where it can make improvements. Pulling work is a basic lean software development principle and a fundamental practice in Kanban.
The value stream is not a focus in Scrum. However, Kanban allows you to easily see the value stream. Ensure the leadership team understands the concept of the value stream, and the importance of optimizing it. Visual control over the value stream is the lean principle the team should understand the most. Show how to identify ways of optimizing the value stream by using examples.
Next, cover the basics of Kanban. Walk through a brief scenario. Show how it covers the solution options identified earlier. Make sure the leadership team sees the difference between measuring Scrum and measuring Kanban (burn down vs. cycle time).
Lastly, incorporate Kanban into your current Scrum framework. Show how you would like to start with small changes and leave it to the team when more changes are introduced. Start with a team board change and tracking cycle time for each backlog item type (or size).
Once the leadership team has agreed to the framework changes, introduce the Scrum team to the idea. Get their feedback, answer their concerns, and propose to start during the next sprint. Since Kanban can be used with your current process, it is possible to introduce with little lead time.
Create Board
After the team has agreed to the new framework, create the current value stream on a team board. For example, use the back of your current Scrum team board and make one column for each step in your SDLC from the start until your definition of done is reached.
Use this board in the final step discussed next.
Walk Through A Sprint
Finally, simulate and walk through a sprint with the Scrum team. Show how the backlog items appear on the board. Note the differences in the board, and how the previous tasks in Scrum planning are now left up to the team members to lead themselves. Give the team the feeling they have already been through a sprint with the new framework to help ease them into the next sprint.
Using the approach discussed here, a team facing situational issues with their Scrum framework can start Scrumban as an ongoing evolution until their product development and organization align.
Nice article on Scrumban !
ReplyDelete