As Agile has matured and gained traction as the dominant approach to software and product development, many different frameworks have emerged to add some flesh to the spirit of the Agile Manifesto. While these principles started a revolution in the way we work and bring value to customers, they are still “big ideas.” Frameworks have helped transform the big ideas into something actionable and reproducible. This subway map from Agile Alliance shows the many influences and practices involved in being Agile, not just doing things in an Agile way.
Let’s look at two frameworks Dev Technology uses a lot in our contract delivery for the federal market: Scrum and Kanban. How do you decide which one fits a project best?
Kanban is a lightweight and flexible framework. It focuses on maximizing flow, making work visible, and eliminating waste and blockers. Limiting work in progress (WIP) is a key enabler for maximizing flow. When using WIP limits, the team agrees to restrict the number of tasks at one or more specific phase to ensure they don’t get stuck, visually reminding the team to combine efforts on tasks and avoid “clogs” in the process, moving more items to Done quickly.
Teams can apply these principles with minimal training and gradually refine their processes and approach. To do this, the team should already have a culture of learning and improvement. Kanban also works best when the team understands the scope of work, believes risks are relatively known, and minimizes external dependencies. When most of the tasks require similar effort, metrics provide reliable insight into team performance. That’s not to say Kanban can’t work in other situations, but these elements are good success indicators.
In our experience, Kanban works well in fluid environments, like service delivery. For example, Dev often uses Kanban for customer service and production support teams, which have frequently changing priorities. Kanban has the flexibility to adapt to constant reprioritization introduced by service interruptions without the overhead of meetings to stop and start a sprint or development increment. While Kanban can work for completely green field development efforts, we prefer frameworks that include more structure and process in these cases.
One framework that provides process and structure is Scrum. This framework emphasizes value deliveryon a regular cadence – producing something, getting feedback, and using the feedback to produce something more. Teams often receive formal training in Scrum because the ideas introduce a new way of working. Scrum incorporates many of the techniques and values from Kanban, like visible work, flow, and eliminating blockers, but Scrum also includes five ceremonies and three artifacts to support the team in their efforts. These ceremonies focus the team, helping them embody the principles of the Agile Manifesto, such as collaborating, delivering value, and responding to feedback, with commitments to outputs that ultimately deliver value.
Dev recommends Scrum for projects with defined objectives or a big vision, like software development. These projects include complex or new work, unknown risks, and tend to be feature-oriented. Unlike Kanban, the work may be difficult for the team to break down into similar sized chunks. The Sprint structure helps the customer and the team break the work into manageable groups of features with “just enough” planning and documentation to move forward while maintaining flexibility to align with changes in future business requirements.
Scrum and Kanban are two of the possible frameworks teams can use to deliver software in Agile ways. Keep an eye out for future posts that will explore hybrid models, like Scrumban, and other schools of thought, like SAFe from Scaled Agile.
But remember – the framework isn’t the point – the point is to use the framework to enable more business agility and value delivery. Be Agile, Do Agile, and do great things.
Want more? Listen to Joyce discuss Kanban vs Scrum in her accompanying DevCast with John Janek.
Joyce Carr Schwab