I have always followed a prescribed set of processes that each engagement regardless of type must go through. Whether building a house or designing a new operating system extensive amounts of time were spent identifying scope, defining activity sequencing, writing project plans, resource estimating, and budgeting. Entire days were set aside for report writing, and change management was the de facto standard. And nothing was built until everything was in place and approved.
Agile methodologies (and specifically Scrum) changed all that by throwing out many of the tenants I lived by. Resource utilization was forgotten. Project planning, in large part, was tossed aside. The customer, once completely removed, now became an integral part of the team helping to guide development and decision making. The top-down management model for project execution was rejected in favor of self-organization and shared accountability. Agile focused on building actual pieces of working code every 2-4 weeks which meant that the customer started seeing delivery right away instead of waiting some excruciating amount of time. Best of all, it worked! I witnessed projects being completed in half the time, at 70% of the previous cost. Project quality was vastly improved and the customer, who had been involved in every aspect of development, now became an advocate for both the project and the team. I was blown away.
A few years later, my world shifted once again when I learned about the time management process known as Kanban. And it’s the combination of project management, Scrum and Kanban that I now feel are the trifecta by which all others practices will be measured.
Developed from Lean manufacturing practices, Kanban helps to determine what to produce, when to produce it and how much of it to build. Where traditional methodologies “push” work along to the next phase, Kanban “pulls” the work forward based on customer demand. By its very nature, Agile deconstructs big problems into smaller, more consumable chunks. This very solution makes it ineffective for long term planning. Kanban, meanwhile, increases visibility, handles interruptions and speeds the flow of work. It assists Scrum development by helping to identify bottlenecks and does a better job of managing workflow.
For a primer on Kanban, look here. To see how these three work together, read on:
Both Scrum and Kanban provide rules on how you should perform your work. An immediate difference between these two methodologies is the number of rules they impose.
Scrum is quite prescriptive and has a vast set of rules. Here are just a few:
- 1. The Product backlog is created and managed by the Product owner
- 2. Teams must be cross functional
- 3. The team’s work cannot be interrupted during sprints
- 4. The team’s work is time boxed
- 5. There’s a daily scrum meeting, where the team answers to 3 questions
- 6. Progress is measured using a burn down chart
- 7. Teams do a demo to stakeholders at the end of each sprint
- 23. (This goes on and on.)
Kanban is much more open than Scrum, and it has only a couple of rules:
- 1. Visualize your workflow
- 2. Limit your Work in Progress
Now, being such an open methodology, it tends to be adapted depending on the environment. For instance, Toyota defined 6 rules for its process. In fact, you can add all rules of Scrum to Kanban, and still have a sound methodology – with 25 rules!
A direct consequence of this difference in rules is the way the work items are handled across time.
In Scrum, you select the work you’ll be doing for the next sprint beforehand. You then lock the sprint, do all the work, and after a couple of weeks – the usual sprint duration – your queue is empty.
Typical flow of a Scrum process
In Kanban, all that’s limited is the size of the queues, called the Work In Progress limit. This means that you can change the items in the queues at any time, and that there’s no “sprint end”. The work just keeps flowing.
Kanban flow, with a WIP limit of 3 for the To Do, and 2 for the Ongoing
Which to pick?
The answer to this question is, as always, it depends.
If you’re doing feature development, which relies heavily on stakeholders’ feedback and if the developers need to focus to do a good job, then go with Scrum. The sprint lock and the end of sprint demos to stakeholders are invaluable in this scenario.
On the other hand, if your work is more reactive, and you cannot lock your backlog for a couple of weeks, use Kanban. It’s a great methodology for Maintenance teams that need to adapt to customer input on a daily basis.
Better yet, learn lessons from both models, and adapt them to fit the unique needs of your organization.
Where does Project Management fit in?
A project, by its very definition has a beginning and an end (schedule). It has specific objectives (scope) to be met and has a budget (cost). The nature of scrum allows us to manage these types of projects more closely and have better visibility and ultimately accountability. These types of projects are those that require us to allocate budget to a defined amount of work. With every iteration of a sprint, every feature in the sprint needs to be estimated and when completed compared to actuals so that we can assess and manage the remaining work based on the remaining budget.
For those types of endeavors where we allocate work to a defined budget (i.e., yearly budget for product maintenance or enhancements) Kanban would be the preferred approach. In this scenario, Kanban allows you to streamline and improve the process so that you can squeeze out more features against the allotted budget. Because it is the process that is the focus and budget is readily available, some practitioners no longer estimate. In fact, some argue that eliminating the need to estimate is one way to improve the process!
Who Does What?
Specific roles play a function here too. Traditionally, the project manager is a leader, a decision maker, a planner, someone who manages the project and the team and is the person accountable to the business for accomplishing the project objectives. The Scrum Master’s role is more that of coach and facilitator, a role that sits between the project and the customer. The Scrum Master doesn’t manage the team that produces the work; instead, he supports the product owner, coaches the team, and makes sure that Scrum processes are adhered to. The Scrum Master is responsible for the Scrum process, its correct and continuous implementation, and the maximization of its benefits.
These projects still need someone who is responsible to the business side of the equation. Someone can report to senior leadership on progress and project health, who can assign resources and someone who can remove road blocks for the team doing the actual work. And while the Scrum process doesn’t worry about budget and risk someone does need to own those too.
The End Game
By combining these three methodologies you’ll produce rapid software development from highly interactive teams. As mentioned before, quality drastically increases as does efficiency and customer satisfaction. Mature teams will be able to accelerate the delivery of a better product and can sustain that delivery model. You achieve visibility, reliability and happier, more productive teams. What could be better than that?
Until next time,
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License