Once a team has decided to gamble on the idea that an agile approach will at least be better than the controlled chaos of the status quo, the terminology of Agile starts to take on a new significance. Suddenly what was simply a manager telling people what to do and a team trying to get all the work done on time becomes a minefield of new labels, processes, roles and tools. This can be intimidating to managers and team members alike.
If you would like a refresher on agile, you might want to take a look at the Agile Manifesto, where the basic principles of agile are laid out by the people who codified the concept. For more details about the two approaches discussed in this essay, you can visit Scrum Methodology and Everyday Kanban, two sites that provide a good overview of Scrum and Kanban. You can also review some of the other articles published here at SitePoint on agile approaches to workflow management.
Choosing a Process
One of the first decisions that come up is which flavor of agile is the most appropriate for the team.
There are many popular approaches that have been formalized, in addition to the custom flavors a many companies end up adopting.
There can be a strong impulse toward choosing the approach that offers the fewest differences from what hasn't really been working so far.
For some companies, "getting agile" means sprinkling a few new titles and terms around without really changing how the work gets done, and calling it agile. It's worth giving your team a chance to follow a legitimate agile workflow first, all the while paying attention to what works and for whom.
Two of the most popular approaches to agile workflow are Scrum and Kanban. Since they are both agile, there are many similarities between the processes and tools you use when implementing either. But Scrum and Kanban provide a different set of advantages that are optimized for different applications.
Iterations or Slices
While both Scrum and Kanban are legitimate and complete ways to structure an agile process, and there are advantages (and disadvantages to choosing either one over the other,) it is worth starting out with the pure form of either approach before trying to customize them.
Both approaches have evolved and matured over the years, and no matter how deep you are into the weeds of your own office jungle, it is unlikely that your project requirements are outside the scope of what they have been designed to handle.
For teams looking to release new versions of a product on a regular schedule, while adapting to a constantly changing marketplace, Scrum is an excellent choice.
Scrum combines a clear set of roles, rituals and artifacts that can be adopted and used immediately.
Scrum is versatile enough to handle teams as small as five and can span organizations consisting of thousands.
It supports autonomy for the developers, transparency for the managers and accountability for the organization as a whole.
By having the team commit to an agreed contract for a time-limited sprint and then iterate based on how well things went, Scrum allows the team to adapt continuously without hindering the self-direction of every member of the team.
Teams operating in a service mode often prefer Kanban over Scrum.
While Scrum is optimized to deliver iterations of a product to customers on a regular basis, Kanban supports a constant stream of independent improvements and optimizations.
One of the key strengths of Kanban is that it focuses on controlling the amount of work the team has in progress at any point in time.
While both Scrum and Kanban benefit from clearly defined stories that can be completed and delivered independently, Scrum leaves it up to the team to decide how much to work on simultaneously, while Kanban focuses on limiting the number of items the team has in progress.
The difference may seem subtle, especially when looking at a Kanban board and a Scrum board side by side.
A key distinguishing factor is that Scrum measures sustainable levels of productivity in terms of the team's velocity, and controls for how many agile points a team will commit to during a sprint.
Kanban controls for sustainable work in progress and limits the number of stories the team will commit to working on at the same time.
Transparency
Both Scrum and Kanban have adopted the practice of a daily stand-up meeting during which members of the team report on what they've done since the last stand-up, what they plan to do before the next one and whether they have any blockers preventing them from working to their fullest capacity. In both approaches, the developers are the only ones who are supposed to report during a stand-up, while product owners and managers pay attention and use the time immediately after stand-up to follow up on specific issues.
Scrum gives the team an entire sprint to decide how to self-manage the work before reflection while Kanban carefully monitors the workflow through the team every time a new story is started.
This has significant implications for the way that managers, product owners and developers work together.
With Kanban, the team can adjust the work in progress level dynamically to avoid idle or overworked developers, and that is something that can be tracked by management.
In Scrum, the team self-adjusts work in progress based on the number of stories they have committed to the sprint, with the goal of making every story meet their agreed definition of done.
Rhythm
The rhythm of Scrum is agreed to by the team based on the type of work being done, and usually falls into sprints of two to four weeks.
Every sprint, the team undergoes a set of rituals to demonstrate the value they have provided, learn from what worked well and what could have gone better. Then they commit to a new set of stories for the next sprint.
Because Scrum is patterned around time-based iterations, the rituals are baked into the process.
Kanban iterations are much more flexible.
In Kanban, the decision for when to pause the workflow for the sake of reflection and agreement can be triggered by date, by milestone, or by other metrics agreed to by the team before the work begins.
The risk for a Kanban team is that the irregularity of the process might encourage them to skip or give little attention to the reflection necessary to help the agile process iterate and improve.
Making Agile Work
It's important for your team to consider carefully which approach makes the most sense, given what you're trying to accomplish.
If you're developing products, you might find that Scrum is a more likely choice. If you're providing services, you might find Kanban suits you better.
Different teams in different circumstances call for different approaches.
Fortunately, at the core of agile is the expectation that your team will learn from what is working so you can make decisions about what to maintain and what to change as you adapt in an agile manner.
Once a team has worked effectively in an agile manner long enough to know its own rhythms, it is possible for a legitimate agile process to adapt to a wide variety of implementations.
But the self-awareness necessary to take advantage of the versatility of agile should not be considered a license to pick and choose aspects of agile from one approach or another, and try to create something new from the start.
I recommend that you give your preferred flavor of agile a try in its purest form for several cycles before you decide whether it is right for you.
If you're doing it conscientiously, there will always be an opportunity to reflect and reconsider your approach at the next retrospective.
Which approach does your team use for software development or project management? Tell us which approach you think is better in the comments below.
M. David GreenI've worked as a Web Engineer, Writer, Communications Manager, and Marketing Director at companies such as Apple, Salon.com, StumbleUpon, and Moovweb. My research into the Social Science of Telecommunications at UC Berkeley, and while earning MBA in Organizational Behavior, showed me that the human instinct to network is vital enough to thrive in any medium that allows one person to connect to another.
