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.

Scrum

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.

Kanban

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.

In my first blog post, I wrote about the benefits and business value that the different levels of the organization can get from an Agile Transformation. In order to reap the full benefits described in my previous article, a commitment by all levels of the organization is needed to support the Agile Transformation. A Transformation is only as beneficial as the effort put in by the company to have it succeed.

As referenced in my post on Agile antipatterns, there is a common misconception that Agile is “just for software developers.” This myth can also manifest within the ecosystem of a company as “Agile is just for the software development department.” When companies take this approach (as many have), they may get an incremental increase in value, and pockets of transparency, but as long as the Agile Transformation remains isolated to one department, the company is never going to recognize the kind of value described in most Agile literature. So how do we get there? In this article, I will discuss the different roles in the company, as I did in my article on business value, but through the lens of what those roles need to do to ensure a successful transformation.

Executive Management and C-staff

This role is often overlooked as an active participant in an Agile Transformation, but it is arguably one of the most critical. When a company commits to go Agile, there needs to be a strong message from leadership as to what this means. As a leader in a company, everybody is watching you all the time. Everything that is asked and unasked gets interpreted in some way by your organization. For individuals in this role, you define the culture of the organization regardless of whether you mean to or not. It is critical to take a hand in shaping the culture to promote the success of the transformation before the culture shapes itself.

What does this culture look like? An Agile culture is, quite plainly, the opposite of a “hero culture.” A hero culture incentivizes performing unsustainable feats on a regular basis to be perceived as a champion that comes in to “save” the organization during emergencies. In a hero culture, emergencies seem to happen all the time, because that is how things get done. Since everybody is trying to be “the hero,” backstabbing is rampant when things go wrong, and sometimes even when things go right. The endgame of a hero culture, is that nobody wants to pivot or take risks to meet market changes due to the threat of being thrown under the proverbial bus; because of this, the business stagnates and sickens from within. Additionally, people will resist collaborating, due to the fear of others stealing their credit, or assigning blame. The good talent that the organization had will leave, and you will be left with a group that thrives on dysfunction.

To avoid this dire fate and promote a culture of Agility, it begins with messaging. Since your words shape the organization whether you mean them to or not, a lot of care must be taken when communicating:

• Be informed. Before charging down the path, I would advise reading up on what Agile actually is, and the benefits it provides to the business at a high level, so that when you begin your initial communications around this topic, your words do not come off as disingenuous “management-speak”. Your people are smart, and they will be able to discern between an informative message and buzzwords.
• Be visionary. As with any long-term endeavor, you need to have a solid vision for what the “perfect world” looks like and champion that vision ad nauseam. When I coach Product Owners, I often state that if you feel like you are repeating your vision too much, then it is still probably not enough. The same is true for a transformation or an organization. Some aspects of an Agile culture to include in your transformation vision might be:
  • Sustainable pace
  • Shared success and accountability
  • Learning instead of assigning blame
  • Frequent, high-value delivery

This vision applies not just to development organizations, but to everyone in the company. Just because a department is doing support, sales, finance, HR, or any other function, does not mean that they cannot become Agile. In some cases, they must become Agile for the shift to occur at a company level.

• Be committed. Take a stand for your vision. When the organization starts to drift, perform a steering correction. When the “heroes” begin to show themselves, guide them back to an approach of shared success and accountability. When you have leaders in your org who cannot be coached, and continue to poison the culture of the organization by assigning blame, promoting overwork, and disrespecting others in the org, do not be afraid to let them go. This sends a powerful message to the good, collaborative people in your company that you are willing to stand up for the culture of the organization, and for them. Actions communicate much better than words, and you will gain their loyalty and trust, as well as putting any would-be kingdom builders on notice.
• Be involved. It is easy to tell your directs to go forth and be Agile, then move on to the next thing. Resist this urge; continue to take “the vitals” of your organization, and adjust your approach to keep steering it towards that vision of Agile Transformation.

Upper and Mid-Level Management

As stated in my blog on the business value of Agile, the role of management does not disappear, it changes. As managers transform from “task accountants” to leaders, the responsibilities in an Agile Transformation shift. In a way, much of the job of mid-level managers is similar to that of the executive: to set the tone and shape the organization, giving the teams the right space to produce amazing products.

Shaping the culture and driving the transformation at this level includes the tenets listed above (driving the vision is not limited to the role of Executive), as well as two unique aspects: defining incentive and promoting sustainable pace.

If an incentive structure that is conducive to an Agile Transformation does not exist, the Transformation will be lukewarm at best. Like it or not, as humans we are hard-wired in our brains to respond to a reward system and to change our behaviors to accommodate that system. We see this in organizations all the time. If the incentive structure rewards actions such as working late or on weekends, performing heroic tasks in response to perceived emergencies, or positioning oneself above others in a force-ranked system, it will be almost impossible to convince people to attempt predictable delivery and sustainable pace. This applies both to comprehensive statements of expectations, as well as subtle, one-off course corrections. When somebody works overtime to get something done, the interaction should change from “that’s great, you really went the extra mile” to “thank you, but how do we keep this from happening in the future?” And remember that your directs are also watching what you do… If you are working unrealistic hours and weekends, they will feel pressured to do the same. Disconnect, and set the example. Live your life.

In these scenarios, I do not simply imply that engineering managers need to make this change; I am referring to all managers. HR policies must promote a learning culture, and learning from mistakes versus assigning blame. Departmental funding and financials should be incremental and iterative, versus only allocating budgets once per year. Operations and support teams should value inspection and adaptation around process efficiency and issue response, versus just moving to the next emergency. Only when everybody is committed to an Agile culture can effective transformation truly happen.

Product Owners

In an Agile Transformation, you are not a project manager. Let me repeat this: you are not a project manager. All too often, organizations will decide to go Agile and tell a bunch of project managers: “You are all Product Owners now,” without following up about what this role actually entails. A traditional project manager is responsible for ensuring that a project is completed on budget, on scope, and on schedule. An Agile Product Owner is responsible for ensuring that the product they are responsible for is delivering the most value for the investment. A traditional project is considered “successful” when it is completed within the parameters listed above. The problem with these criteria is that they completely disregard whether the outcomes of the project actually add value.

To be an effective Agile Product Owner, you must constantly ask why the team is building what they are building. Product value is ephemeral, and the value statement for a particular feature or process may not hold true from one month to the next. So, if product value is a moving target, what is a good baseline for determining whether a product is adding value or not? This is where the Product Vision comes in. Much like the CEO’s vision for the company, a Product Vision is aspirational and can never be stated enough. This vision should be a single statement encapsulating the world that should exist if the product, outcome, result, or mission that the team was created to perform is completed perfectly. This will guide the team during those uncertain times when there are conflicting priorities, or external requests coming in. When there is confusion over a priority, or a question of whether the team should pivot, the question that should be first and foremost in your mind should be: does making this choice drive us towards or away from this vision? In a way, a Product Owner is like the navigator of a ship. It is not the navigator’s job to make sure everyone is performing their functions perfectly on the ship; rather, it is to make sure the ship is heading in the right direction and ensure that everyone is aligned.

The Builders

It is tempting to address these folks as “engineers,” but this again fosters the myth that Agile is just for development. For an Agile Transformation to succeed, the entire company must be willing to participate. Whether you are an engineer, HR generalist, accountant, customer service representative, sales associate, or marketing manager, an Agile culture will help you add value to the company and your career, and you will usually gain fulfillment by doing so.

As individual contributors, how do we add to that Agile culture and protect the health of the organization? A good benchmark for this lies in the Scrum values:

• Courage. The Scrum value of Courage is the antidote for dysfunction. It takes a lot of courage to stand up and call out a behavior that is not acceptable to the team’s working agreements or team norms. If an organization is going to work in an environment of authenticity and respect, we must have courage.
• Commitment. The Scrum value of Commitment implies integrity. We do what we say we are going to do, and this builds trust. For true commitment to occur, we must also have the courage to say when a request is too much, or not feasible. When we commit to things that are not feasible, we almost certainly do not deliver, and this breaks trust.
• Openness. One of the greatest dysfunctions in an organization is hoarding knowledge, and obfuscating reality. If we are not open about the reality of what is happening on a project, or in a given situation, it is impossible for the organization to help us, and divisions occur between different elements and tiers in an organization. If everyone demonstrates Openness in an organization, there is much more confidence in the commitments of the individuals, and everyone knows that we all respect each other enough to tell the truth. In addition, the best designs tend to emerge when others can contribute knowledge; this will increase value and accelerate delivery.
• Focus. In order to meet the commitments we make, we must have the focus to do so. This is where we start to see the value of the Agile frameworks come into play: Scrum limits the work by creating the Sprint boundary, letting the team focus on the work without interruption. Kanban allows the team to focus through work-in-progress limiters. When an organization has that laser-focus to follow the visions of the company and product, truly amazing things can be built.
• Respect. None of these other values can be successfully realized without the Scrum Value of Respect. It is very difficult to have the courage to be open if we are worried about others tearing us down or sabotaging us when we speak up. Likewise, we cannot focus on commitments if we are always watching our back. Respect is the glue that holds an organization together, and it is everybody’s responsibility to uphold. If we don’t respect each other, it is very hard to get anything done at all, much less execute an Agile Transformation.

As you can probably tell, all of these values intersect with each other and are all dependent upon one another in some way. It is hard to demonstrate one in isolation. There is a simple elegance to these values that belie the trial and error that went in to creating this framework and the realization that these are the building blocks of a functional, successful organization. Scrum itself is a product of iterative development.

In my previous blog post, I wrote about the business value of Agile, and how it benefits different areas within a typical organization. With that context in mind, let’s look at some myths and antipatterns about Agile, and ways to recover from these. These antipatterns reduce the type of value I described in my previous entry, so they are worth calling out. Sometimes, when artifacts of Agile are misunderstood, they can cause more harm than good, and execution of these antipatterns are usually the underlying reasons why some people believe that Agile “doesn’t work.”

Overloading Terms

Where I see antipatterns do the most damage to the ability of the team to focus on value and continuous improvement, are when Agile terms get misconstrued, overloaded, or even abused. The two terms that I have seen most often coopted are “servant leader” and “self-organization.” These terms are particularly dangerous, because they can be weaponized for personal gain or to avoid having to do certain elements of a job that one might find undesirable. This can have a devastating effect on the quality of the team’s work, as well as the direction of the product. Let me explain.

Self-organization. This is a term that is used frequently in the Agile community, and is meant to imply that the team should determine for themselves how they will go about building their product, and what sort of working agreements they will abide by as they do so. This does not mean that the team needs to also be responsible for product strategy, user adoption, and generating functional requirements. An example of this term being misconstrued comes from a project I was working on, where the Product Owner, in response to the development team asking for detailed use cases of a feature, replied with “Just…self-organize around it! I’m sure what you come up with will be good.” In this case, the Product Owner abdicated the responsibility of defining the direction of the product by overloading the term “self-organization.” Whether this individual was motivated by a lack of understanding or a lack of desire is irrelevant; the outcome is the same. The team was left to guess at what the business wanted, and hope that the product they built would be sufficient, or even correct. I have also seen leaders misuse this term when they do not have a broad understanding of the strategy in an organization, or when there is a desire to avoid accountability for the execution of that strategy.

In order to fix the underlying problem, if it is in response to strategic questions, it may be beneficial to assemble stakeholders, sponsor, and team to align on the Product Vision, and perhaps conduct some high-level backlog refinement with Epics or Features. It may also be wise to have a session to define what the different roles in the project are accountable for, so that there is an understanding of what, exactly, the people in the project need to “self-organize” around.

Servant Leader. This term is also often overloaded in the Agile community, and has been used to the point of becoming a buzzword. The danger of this term is that some people will take advantage of the term to imply that the “servant leader” is the notetaker for every meeting, fills out all access request tickets for the team, or even gets coffee. While the servant leader may do these activities from time to time, the role of a servant leader is not to be the dumping ground for all the work that the team does not want to do. A servant leader is someone who acts on behalf of the greater good of a team, and ensures that everyone whom the leader affects is growing and evolving in their role. Sometimes a servant leader will need to have tough conversations with members on the team to get them to see their blind spots and grow. Other times, a servant leader will need to rise to the defense of the team by having direct conversations with people outside the team, and even escalate within an organization’s management structure to protect the team from being randomized or subverted. This term does not imply meekness at all; rather, it implies a shift in priority from issuing commands, to developing individuals, and acting for the greater good of the team.

Misunderstanding What Agile Is Designed to Do

Over the course of my career, I have encountered several individuals who believe that Agile has failed to deliver on its promises. More often than not, this is because there is a misunderstanding of what, exactly, those promises are. These are not antipatterns per se, but more a misalignment of expectations. Let’s look at some common myths about what Agile is designed for, based on quotes I have heard working with teams and stakeholders

Agile doesn’t work; I’m following all the practices, and we’re still not predictable, the team still gets interrupted, and (redacted name) is still causing problems!

This quote is based on an assumption that Agile will fix all the issues in a team just by following the guidance in the Scrum Guide (or Kanban books) and the Agile Manifesto. This is also, unfortunately, a misconception that some Agile consulting agencies will try to sell clients on as well, so when the client understandably becomes disillusioned, the Agile mindset and associated frameworks get blamed. The truth is, that Agile will not, in fact, solve all the problems the team or organization is dealing with; Agile is designed to make these problems visible, and enforce accountability. If a team is unpredictable, Agile frameworks provide tools for determining the cause of the unpredictability, and where in the process those causes occur; the Agile mindset then guides the team to be courageous in calling it out, and tackling the problem versus assigning blame. Agile will not actually fix the problem though… the team, organization, and/or management structure must do the hard work to remediate the issues that are causing the inconsistencies, have those tough conversations, and practice discipline in the process.

Agile is only for software development. It won’t work for (redacted).

This misconception is widespread, largely due to the fact that many of these terms were given names by software developers, such as the signatories of the Agile Manifesto. In fact, there is one line in the Agile Manifesto that I do not agree with: “Working software over comprehensive documentation.” If anything, it should be “Working product or successful outcomes over comprehensive documentation.” Here are some examples of non-software Agile development:

• Digital Marketing. I worked with a team in a previous organization that pushed marketing campaigns for the business. These individuals would release items to a website, but most of their work did not have to do with software development. This team successfully used Scrum to manage the tools used to push the campaigns, while using Kanban to handle incoming requests from marketers. Though this team had to write some scripts and administer tools, they were not a traditional software development team.
• Training departments. Before I got into the business of Agile Coaching, I was a trainer for a customer service organization. There was absolutely zero coding done, but we used Scrum to manage the creation of training materials, and Kanban to queue up training requests.
• Manufacturing. Long before the term “Agile” was ever used in this context, the Toyota company created the Kanban system for their manufacturing plants; this system is now a prominent Agile/Lean framework, and helps manufacturing companies maximize value, throughput, and cost-effectiveness to this day.
• Nursing. There is a concept in nursing called “shared governance” that is gaining traction. This concept involves self-managed work teams that coordinate around daily huddles to track the work, and more closely align that work with the values of the profession, while keeping the focus on the best outcomes for the patient. Source: OJIN. Sound familiar? They don’t call this “Agile,” but it most definitely is.
• My own yardwork. Yes, I am a procrastinator. Yes, I look at my massively overgrown laurel hedge and think, “There is absolutely no way. I am going to play video games instead.” To help myself get out of my own way, I break down tasks into manageable chunks of work to avoid getting overwhelmed, and have everything listed on a personal Kanban board as prioritized by my Product Owner, aka my wife.

The bottom line is this: if you produce something, create a successful outcome, or otherwise add value to an organization or to yourself, you can do, and be, Agile.

The Danger of Obsessing on Metrics

To invoke an old cliché, metrics can be a double-edged sword. They are useful and necessary tools for continuous improvement, but they can also be quite dangerous if misused. Most Agile antipatterns I have seen among teams and organizations spawn from the misuse of metrics.
There is a quote that I particularly like from A. Donald Stratton, the author of An approach to quality improvement that works: “Some say you only get what you measure. I say that’s all you get.” This quote perfectly encapsulates the tendency for teams, individuals, and organizations to change behaviors to make the metric look better, versus the outcome that the metric is measuring. This can take many forms, but I see this most often occur with story points. This antipattern will usually start with a comment or an expectation such as “Why can’t you do more points in your sprint?” Or even worse: “This other team is able to do 450 story points per sprint…why can’t you?” On the surface, there are three antipatterns that manifest from this mindset:

1. An assumption that Agile teams should get faster every sprint; at some point there is a speed limit that a team will get to before they break their sustainable pace. The goal is predictability, not speed.
2. A tacit competition between teams with a zero-sum game, using a metric that is subjective to each team. Good luck getting those two teams to collaborate on anything in the future.
3. A desperation to make excuses or blame others if the metric in question is not looking completely healthy, as the reasons are likely beyond any one person’s control.

In response to this implied direction, teams and individuals will perform mental gymnastics to show that the metrics look good; they will inflate story points, attempt to equate story points with hours, deliver RAG statuses that are always green regardless of reality, insist that defects are actually “features,” and so on. What often gets overlooked, is a mindset that begins to take shape as these antipatterns are executed: valuing the metric over the outcome. The metrics themselves are not important; the questions the metrics are designed to answer are. Questions such as:

• What exactly happened to lead us to this point?
• Can we perform this feat again sustainably?
• Are we in trouble?
• Can we identify small problems early before they become big problems?
• How can we plan for the delivery of thought work, where the outcomes are uncertain?

When we prioritize making the metrics look good, we forget to keep these questions in focus, and we lose sight of the true value of measurement. After all, if I go to buy a car, I’m going to look for a car that has good gas mileage, has 4-wheel drive, and is a comfortable ride; I’m not looking for 450 story points worth of car.

Remediating Antipatterns

So once we find these antipatterns, and can identify them reliably, how do we proceed? This is where the art of Agile Coaching comes into play. It is sometimes tempting to feed our egos and approach the situation from a position of superiority by claiming that the person, team, or organization is “doing it wrong,” and that the “right way” is some process that you are an expert on, have a certification in, or have read about. All this behavior will likely do is to cause people to dig in their heels and resist. Remember, change is hard. Even if that change will cause individuals to feel less pain, be more successful, and become more fulfilled, it is still change, and that requires people to alter the way they think. Also, remember that antipatterns that are entrenched in an organization likely took a while to take root, so undoing those old patterns is going to take just as much effort to extract.