Adopting Agile in the Pursuit of Growth
Everyone involved even tangentially in software development has heard the word “agile.” The C-suite executives might say “we need to become more agile” or “is that vendor more agile than the others?” It’s a common word in this realm, but what does it really mean, how is it achieved, and what should companies consider before adopting agile? Agile is essentially a set of principles for the organization. As the company makes decisions about its technology and processes, it can check those decisions against the agile philosophy to make sure there’s alignment. Over time, the idea is for the entire team to lean towards the “agile” way of doing things, which might include how to dynamically respond to changing conditions and the need for software that improves the user experience.
The idea of “agility” has spread beyond its roots in software development to become a methodology that’s followed by all sorts of companies and departments.
Two of the core ways to reach an agile state are the Scrum and Kanban methods/approaches.
Scrum’s Core Features
From the rugby word “scrum” comes one agile methodology that’s arguably the most popular. A rugby scrum involves many players interlocking their arms together so they move as a single unit towards the opposing team’s side. It’s a metaphor for the agile method where cross-functional teams need to come together in a structured way.
Within Scrum there are different types of work known as “Sprints” which detail how the teams are supposed to work with purpose and order. They’re described as follows:
- “Sprint planning”— involves the team estimating the work involved and fully committing to all of the necessary tasks.
- The “Daily Scrum” which simply involves team members providing daily updates on progress. This keeps everyone informed and also presents an ideal time to talk about any roadblocks.
- “Sprint review”— a gathering period where all the stakeholders can analyze the work completed in the sprint.
- “Retrospective”— As the term implies, this is the time to review the entire sprint at its conclusion and then pull insights, with the goal of the continual process and workflow improvement.
- “Backlog refinement”— This part of Scrum entails setting aside time to review the backlog and determine the most appropriate next Sprints in the pipeline.
Compared to other approaches such as Kanban, Scrum is fairly fixed in terms of its better suited to a schedule of Sprints and projects instead of a “continuous flow” model. It’s ideal for groups that have defined backlogs. Project managers that want to reach agile states with Scrum need to embrace scheduling and understand the system works best when nothing out-of-scope should be introduced in a later Sprint.
Kanban’s Capabilities
There are no “time boxes” or iterations with Kanban, instead it’s an iterative method, one that pushes for continual improvement that happens over time. Getting the most out of Kanban requires a company to enable real-time communication and to engage in work with full transparency. Every team member needs to stay informed and have unrestricted access to the right information.
Items for work are visually shown on Kanban boards, which provide staff to quickly see how work tasks are progressing. There are four main principles for Kanban:
- Work visualization—visual workflows that promote efficiency because they’re simple and direct, often showing just “to do”, “in progress,” and “done.” Turning work into visual components makes it easy for all the team members to gauge when others are at capacity or able to take on more work.
- Limiting work-in-progress—the team should set limits for work-in-progress amounts with the goal of preventing waste and roadblocks
- Focus on flow—Kanban is a continuous flow style that relies on many small “wins” of projects
- Learning from experience—Kanban’s flow is fluid, so there’s always a need to review projects and find improvements. The method encourages teams to learn from past failures and successes and then to quickly move to the next project.
Kanban is both agile and a “lean” approach where one of the primary goals is to “cut the fat” found in redundant processes and any tasks that are wasteful or don’t improve efficiency. Conducting Kanban effectively requires a quality team that’s empowered and willing to work as a cohesive unit to reach shared goals.
A drawback of Kanban is it is ill-suited to new teams, whether it’s a group new to agile or simply recent hires. Its relative lack of requirements and rules does not typically provide enough structure for new teams that might struggle.
Key Differences – Considerations for Agile Adoption
Change can happen more freely with Kanban, so it’s likely a better choice for teams that frequently change specs or requirements as well as situations that are rapidly evolving and might require change. Scrum is a more defined approach, with Sprints that set goals and tasks and a more formalized review process. Kanban is ideal for projects with a number of different priorities, while Scrum is suited for teams that have stable priorities.
Productivity within each approach is measured differently. Kanban looks at the “cycle time” or time required to complete a project from beginning to end (the “cycle.) Scrum reviews productivity by measuring the velocity at which the team completes Sprints.
Companies looking for the best path forward to agile are finding some success with combining elements of Kanban and Scrum, as they found the two approaches are not mutually exclusive. For example, a team might use a Scrum approach to define roles and deliverables but use a Kanban-style way to visualize the workflows. Firms should avoid rigidity in their agile style because it goes against the main tenets of “agility”, and consider the benefits of both Scrum and Kanban as transformation tools.
