In my final installment of this blog series, I discuss the mechanics of different Agile frameworks, how they work, and why they function better for different types of work intake. This article builds on the previous blog entries, so if you have not done so already, I would suggest reading the series from the beginning, starting with The Business Value of Agile, followed by Recognizing Agile Antipatterns, and finally Transforming All Levels of the Organization. These previous entries provide context for how the organization benefits from Agile, and what actions are required for an organization to get the full benefit of the Transformation. This context will better help the reader understand why the frameworks are built the way they are and the value that comes from successful implementation.
Choosing a Framework
If you are an Agilist in a company, and you have been assigned to a brand-new team, part of chartering that team involves helping the team choose an Agile framework to operate within. There are two things that a team must consider when selecting a framework to use:
- Work intake predictability. Is there a product roadmap? Would it be fair to say that the team will have a sense of what they will be working on and where the work will be coming from? Or is this more of a service-oriented team, where the team has been chartered to respond and resolve requests coming from people or systems on demand?
- Solution predictability. Is the work that the team receives fairly repeatable, or does it require significant discovery work and is usually a one-off endeavor?
There is a myriad of frameworks in the industry that a team can choose from, but I am going to focus on Scrum and Kanban for the purposes of this article, as they are the most widely used by far. Broadly speaking, both of these frameworks can be used by any team regardless of the type of work they do; there is no hard-and-fast rule that says you must use one or the other, but they do offer more or less benefit based on the above criteria. In general, Scrum tends to work better for teams that have a predictable work intake and non-repeatable solutions. Teams like this might be software feature development teams, teams implementing new programs or standards in an organization, or teams building experimental vehicles. Kanban is usually more effective for an unpredictable work intake, where solutions are more repeatable. Teams that benefit the most from Kanban tend to be teams that perform activities such as system performance monitoring, customer support, network device lifecycle management, or manufacturing.
The industry is saturated with resources describing what Scrum and Kanban are, so I will be focusing less on explaining what the artifacts of these frameworks are and more on the way that these frameworks deliver the kind of value described in my previous entries.
Let’s say you work with a team that has chosen to implement Scrum, since they do a lot of project work where their work intake has a well-ordered backlog but the outcome of the work is uncertain. In the case of Scrum, the mission of the team is to deliver the highest possible value to the business at a sustainable pace. Since this work usually involves brand-new features that are being developed to solve a need, feedback loops are required to make sure that the work being done is actually solving that need in the best way.
At its heart, Agile is about inspection and adaptation with the purpose of achieving the maximum value for the investment. This value is realized by pivoting when needed, just as the McVickers pivoted from making wallpaper cleaner to making Play-Doh based on shifting market needs, as described in my entry on the Business Value of Agile. The feedback loops of Scrum are based upon two cadences: the Sprint, and the day.
In Scrum, a “Sprint” is a predefined timebox that the team has to complete their stated goals. At the beginning of the Sprint, the team will plan to do certain activities based on statements of customer need called “user stories.” These user stories contain the persona that the feature is being built for, what the feature is, and the reason or value that the outcome of that development will deliver. This ceremony initiates two feedback loops: inspection/adaptation of the product being built, and inspection/adaptation of the way that the team is building it. After the team has completed their Sprint of work, two events take place. The first event is the closing of the feedback loop of the product. This is called a Sprint Review, and is a chance for the team to demo to stakeholders, receive stakeholder feedback, and change the scope of their product backlog based on that feedback. After the Sprint Review, the Sprint Retrospective occurs based on a reflection of how the Sprint went, and how the team wants to inspect and adapt on the way that they work. The Retrospective closes the feedback loop of the process.
The daily feedback loop both starts and ends with the daily standup. This standup meeting allows the team to plan for the day, and make sure they are getting out of each other’s way, not doing duplicate work, and ensuring that each team member is not blocked from delivering on the Sprint commitments.
An example of this might be a team that starts to build out a user story such as “As an open source application developer, I would like an API endpoint that accepts data fields A, B, and C, so that I can integrate my application with your system, and my customers are able to use your functionality, thereby generating more app sales.” After refining this story, the team goes into planning and figures out how they are going to go about building this endpoint. They work on the functionality throughout the Sprint, syncing daily to ensure that they are not blocked from progress, and finally demo to the stakeholder in the Sprint Review. The stakeholder says that this endpoint is exactly what they were looking for, but it doesn’t look like there’s validation in place to make the inputs numeric-only. The stakeholder then requests if the team might be able to implement this functionality. The team says absolutely, we can create another story and work on it in a future Sprint. The product backlog is altered to reflect this new priority, and the Review ends. The stakeholders leave, and the Retrospective begins. The team then asks questions such as “Could we have anticipated, somehow, that numeric-only fields was going to be a requirement? Also, I noticed that a couple team members worked late on a couple days this Sprint to get this done. How can we keep this from happening in the future? Did we underestimate, or misunderstand the story?”
Scrum operates on the philosophy that it’s much cheaper, easier, and valuable to pivot an endeavor frequently as needed. In fact, the buzz-phrase “fail fast” is referring to this type of system. Wouldn’t you rather discover that you are building the wrong thing days or weeks into the effort, rather than months or even years? Scrum was created to ensure that the most valuable thing that the team can feasibly produce is being built at any given time. In order to achieve this outcome, the daily standup, Sprint Planning, Sprint Review, and Sprint Retrospective events are all required to open and close those feedback loops.
Where Scrum focuses on frequent feedback loops to maximize value, Kanban is all about efficiency. Since the team doesn’t know where the work is coming from or when, Kanban focuses on the delivery engine itself. There is no Sprint boundary in Kanban, because it is very difficult to anticipate when the work will come, and at what volume. For this reason, the constraint to support sustainable pace lies not with a calendar boundary, but with a work in progress limiter.
Kanban was created by Taiichi Ohno at Toyota in the early 1940s. This system was originally designed for the manufacturing sector in response to the excessive waste and part inventory, as well as lack of product customizability generated in factories that utilized the continuous manufacturing model of the never-ending assembly line. In the factory, Kanban was used to determine when a part needed to be picked up by a different assembly line by hanging a “Kan” (sign) onto a “Ban” (board). The next workstation would pick up the Kan, and use that card as permission to begin work on the part described on the card. This decreased manufacturing inventory waste, as there were fewer unused parts that would be taking up space, due to only manufacturing what was needed for the customer order. This also enabled greater customization of customer orders by limiting the buffer time it would take to transition the lines to produce different product. A process was used called Kaizen (translating literally to change-good). During a Kaizen session, workers and engineers would inspect the delivery process and make changes to improve efficiency, such as relocating assembly lines next to each other, eliminating processes that added waste, and implementing processes that added quality.
This framework was brought into the realm of software development in the early 2000s, and it works wonderfully for teams that do not have a consistent work intake. Much like the Toyota factories, teams will take “Kan” usually in the form of tickets, requests, or work items, and use those as permission to work. These tickets will be placed on a task board that visualizes the workflow of the team. With a team adding new network appliances to a data center, the flow might look like this: requisition > rack and stack > install firmware > push device config through Nautobot > execute performance testing > hand off to Operations team. As with factory assembly lines, there is only so much a team can work on at the same time on any one of these states before the system breaks. This is enforced by work-in-progress limiters per column on the board. These work-in-progress limiters act to visualize bottlenecks in the process, and to find the team’s predictable pace. If tickets are piling up in one of the states, let’s say the “install firmware” state, the team might have a Kaizen session to figure out if there is a way to make this process more efficient through automation, or executing Compliance processes quicker. The team can then raise and lower work-in-progress limiters to accommodate staffing, dependencies, and task time as needed, until the system reaches equilibrium.
A Word About Constraints
When picking an Agile framework to implement, it is tempting to select only the practices that look attractive or exciting and exclude practices that may be difficult to execute. Usually, practices that teams sometimes try to exclude are the constraints: the Sprint boundary if using Scrum and the work-in-progress limiters if using Kanban. People often do not want to implement these constraints because they are uncomfortable when teams bump up against them. They are also the most valuable of the processes in these frameworks.
These constraints give the team a very important capability: the ability to say “no” or “not yet” to stakeholder randomization.
In Scrum, a team with a predictable velocity measured by how many story points the team completes within the Sprint boundary, is able to communicate to stakeholders how long a project or a set of capabilities will take with a good degree of accuracy. When a stakeholder comes to the team and requests something to go faster, or contain more scope, the team can push back and state that they can definitely take something in during the next Sprint, but something else must come off the table. In this way, the team can maintain sustainable pace without falling into a “hero culture” of getting it done at all costs.
In Kanban, a team with a consistent Lead Time and Cycle Time can state that tickets will be completed at a certain rate, and that the input queue is fluid, and ordered such that the highest priority tickets come first. This pushes the negotiation to the different stakeholders and requestors to figure out amongst themselves what the priority should be, and the team can keep producing at their pace. Other teams simply follow the first-in-first-out model. Either way, the team works at a sustainable pace, and if the needs of the organization exceed the capabilities of the team, then the conversation is systems oriented (how and where do more people need to be staffed, or what systems need to change?) thereby raising the capability of the team and still keeping the sustainable pace, rather than asking the team to work nights and weekends, and other silliness like that.
By choosing to ignore the constraints prescribed in Scrum and Kanban, you are choosing to let stakeholders dictate your pace and compromise your work-life balance, as there is no data to refer to when pushing back on unreasonable requests. Embrace the constraint, and it will save you.
SAFe (Scaled Agile Framework)
Sometimes companies, particularly large ones, will have initiatives that span Sprints, quarters, or even years, and involve many teams that must collaborate together. It is for these efforts that SAFe was created. There are many other frameworks that fill this need, such as Scrum at Scale, LeSS, DAD, etc., but we will focus on SAFe here, as this is the framework that most large-scale organizations tend to gravitate towards.
SAFe is a bit controversial in the Agile community, as the infographic here can appear a bit like Waterfall at first glance. This is largely due to the complexity of the fully executed system and the fact that SAFe thinks beyond the short term. At its most basic, SAFe is Scrum extrapolated up one or more levels. Where a Scrum team has a Sprint Planning, Daily Standups, a Sprint Review, and a Sprint Retrospective over the course of a Sprint, SAFe has a PI (Product Increment) Planning, Scrum of Scrums, a System Demo, and a PI Retrospective over the course of a release. The Product Increments are the pieces of value that are delivered within an iteration larger than a Sprint (usually a quarter) by a collection of teams. These teams together are called a “Release Train,” and product releasing is iterative, much like a train schedule. A good way to remember this, is if a team does not have something ready to be released, or they needed to pivot based on the business need, they can simply wait for the next train to come along to deploy. This is in sharp contrast to Waterfall, where everything defined in the initial project plan must be delivered at the end of the project.
One of the mistakes that practitioners often make is to use all of the practices in Full SAFe for all projects that are in flight in an organization. This is where I diverge from my previous statements about ignoring parts of the framework; in this case, SAFe is so extensive that it is best to use it as a toolbox to draw from, based on the type of project that you are working on. In fact, SAFe itself encourages this. The system is modular for different types of projects:
- Essential SAFe: This suite of processes is designed for smaller projects, where a few teams have dependencies on one another and are working to deliver a connected set of value in a product increment.
- Large Solution SAFe: This variant has processes to accommodate very large projects with many teams that are all working on different interrelated aspects of feature delivery.
- Portfolio SAFe: This type of SAFe contains tools for initiatives that require portfolio oversight and need to map to various funding sources to provide traceability for investments.
- Full SAFe: This variant contains all of the processes that SAFe has to offer in one framework. Full SAFe is used for company-spanning initiatives that involve multiple departments and many different teams, and that need to trace back to company goals and core capabilities. This variant is not used very often, as these types of initiatives are relatively rare.
The biggest thing to remember when implementing SAFe, is to critically look at your organization, or Release Train, implement the processes that make the most sense for the type of endeavor you are facilitating, and avoid over-processing. In fact, if your project only involves one team working on one backlog, then it probably does not even make sense to use SAFe at all.
When selecting an Agile methodology, it is easy to get lost in the weeds. We are hardwired to look for the quick solution that will fix our problems, so our brains gravitate towards the processes in the frameworks above. When selecting and implementing a framework though, it is critical to remember the why behind it. When we know how and why the various events, artifacts, and roles in an Agile framework work the way they do to add value, increase efficiency, and maintain sustainable pace, the implementation of the framework has a much better chance at being successful. When the implementation is successful, it gives the team and organization the space to live the values of Agile, Scrum, and Kanban. Practicing both the processes and the values, with a firm understanding of why they exist, will create an organization that is unstoppable.