We have all been there. The message comes from the top of the organization stating that the company is “going Agile.” A flood of consultants is brought in to teach the employees what the Scrum events are and to play a quick game to illustrate what a sprint looks like. Vague promises are made that this will transform the business into a thriving, self-actualized beacon of productivity. As an engineer, developer, executive stakeholder, or product manager, you may have found yourself asking “so what?” And you should.

It may surprise you to learn that, as an Agile Coach, I encourage people to ask this question loudly, and often. Over the last couple of decades, Agile has exploded into the technology sector as the de facto way to do business. Companies publicly embrace the term “Agile” as a way to recruit talent and sell product, and teams are formed within these companies to follow Scrum processes. Only it seems that very few people actually wonder why. When we do not understand the benefit and intent of Agile, we run the risk of adopting one of these two personas:

• The Evangelist. The Evangelist will go to the ends of the earth to ensure that everything in the organization corresponds exactly to what the Scrum Guide states and views the value of Agile as having correctly executed the Scrum Events themselves. Anything occurring outside the auspices of the Scrum Guide is considered “Not Agile.”
• The Cynic. The Cynic believes that this whole Agile thing is a waste of time that creates meetings which are non-productive and kills time that could be better spent writing code, manufacturing widgets, etc.

In most large companies, both of these personas exist, and as one could imagine, are frequently at odds with each other. The sad thing is that this doesn’t really need to happen. People that fall into these personas are usually coming from the same place: a desire to increase productivity, company success, and employee satisfaction. The key to getting to that common ground is understanding the why. To understand the why, we need to first realize that Agile is not just for software development teams to “do Scrum”; it is for entire companies in every industry to be able to continually provide the highest possible value to their customers at a sustainable pace. Let’s take a look at what this looks like through the lens of different roles in a typical company.

Executive Management and C-staff

At a strategic level, Agile enables businesses to pivot and reinvent themselves. If you are in an executive role, you are responsible for the performance and profitability of the company. If this is the case, you cannot afford to remain static. Take Play-Doh for instance. This well-known children’s toy started out as “Kutol,” a wall cleaner for the black residue that accumulated in houses with coal furnaces. As coal-burning furnaces were replaced with oil and gas, the executives in the company did not create a five-year project plan to come up with a better wall cleaner with milestones and a schedule that could not be moved; they pivoted. Reinventing their product as a multi-colored modeling compound for children (and adult children like myself) not only saved their business, it made it wildly successful.

This type of outcome is why all literature that references Agile and Lean espouses that strong connection to the customer. The success of Play-Doh as a product is a direct result of Joseph and Noah McVicker realizing that the customers’ needs had changed; so much so, that they needed an entirely new customer base. When they met with a schoolteacher (a member of this new customer base) and found that she was using the product as a modeling compound in her classroom, they adapted the business to deliver on their new customers’ needs, thereby reaping the benefits of “Individuals and Interactions over Processes and Tools,” the first value statement in the Agile Manifesto.

With these actions, the McVickers were living the three pillars of Scrum (transparency, inspection, and adaptation) decades before Scrum was ever a term used in business. They realized the why of Agile at an executive level before Agile was even an industry term. In this case study, the business value of an Agile mindset is fundamental: it saved the business itself.

Upper and Mid-Level Management

If you lead an organization or team within your company, you are responsible for building a durable, effective, and scalable organization, as well as defining the culture of your organization through action. You are also responsible for providing growth opportunities for your direct reports and working with them to help them reach their goals. Essentially, you are building a legacy. The best part about Agile for this role is that you will actually get to do these things!

A common misconception among managers new to Agile is that it represents a threat to their job security. This is understandable, as a traditional manager manages tasks that their team is doing and drives them to completion by following up with individuals on a regular basis. The Agile mindset teaches exactly the opposite approach, placing ownership of the delivered product into the hands of the team. By taking away the things that the traditional manager does on a daily basis, it could appear as if their job is being phased out. This couldn’t be further from the truth.

What actually happens, assuming an organization is fully committed to transformation, is that the job of the manager changes. Remember all those responsibilities in the first paragraph of this section? Chances are, the traditional manager has never actually had time to do any of those things, because they have been occupied with task management. By placing the responsibility of managing the day-to-day work onto the teams and freeing up time to define the culture of their organization, the manager gets a golden opportunity: to transform into a true leader. With these types of outcomes, the bottom and top lines of the business itself will directly benefit; by increasing the effectiveness of management and reducing employee attrition, the business will see a reduction in cost associated with backfilling headcount, as well as higher-value products when workers are allowed the freedom to innovate.

Product Management and Project Stakeholders

Product Managers reap much the same benefits as the previous two roles do. A typical Product Manager in a traditionally aligned organization will spend most of their time gathering requirements from stakeholders, writing up voluminous business proposals, and preparing status reports. While some of this will exist in any environment, the landscape of the role changes dramatically when a Product Manager takes on the role of Agile Product Owner.

As the name implies, the responsibilities of this role include a much stronger hand in directing the product that the team is building. The reason for this is that the ability of the company executives to pivot needs to extend all the way down through the company for it to be effective. When someone is allowed to be a Product Owner, master the craft of user stories, and drive the vision of the product, they are allowed to be the visionary who shapes a product that people are excited about.

Note: I mention that Product Managers most often take on the role of Product Owner, but this is not always the case. Sometimes others can assume that role, such as an information security officer for security remediation teams, or an Operations director for teams that work on automated dashboards for outages. In any case, the value remains the same; the person owning the product gets the opportunity to drive the vision of the product in order to maximize its value and effectiveness. The important thing is that someone is performing this role, so that there is a voice of the customer and a single point of accountability when it comes to the value of the product.

The Builders

I refer to this group as “Builders” rather than developers, because Agile is not constrained to a particular industry. We might see it most often in technology organizations, but any industry type can benefit, whether you are writing code, manufacturing car parts, installing data center hardware, creating good health outcomes for patients, building marketing campaigns… if you are doing things that someone can benefit from, you can do Agile. The execution framework you select may vary based on the type of work your team does, but the principles remain the same. So what do the builders get out of all this? From a business perspective, the builders of the product get to see how their work matters. One of the most gratifying things on a job is seeing how your efforts directly impact the success of the company. In an Agile culture, whether they are using Scrum or Kanban, the teams own their day-to-day processes and the way they work. This is the first step in a virtuous cycle:

• The team takes ownership of their craft and how they build the product.
• By executing with that sense of pride and accountability, the team delivers higher quality and higher value product than previous iterations.
• Through stakeholder demos and adoption metrics, the team sees how their efforts affect the overall success of the business.
• That feedback and knowledge creates a greater sense of ownership by the team.
• Repeat.

This cycle complements the notion of a sustainable pace. There are two benefits to a sustainable pace in Agile methodologies: predictability and work-life balance. If the team is working at an indefinitely sustainable pace, their rate of delivery is predictable, which means that Product Owners and stakeholders can say with a high degree of confidence when a capability or product might be available for use. This not only benefits the business, as it builds customer confidence, it also reduces the distracting, panicked emails, texts, and phone calls inquiring about the status of a project or feature. When stakeholders are calm, the team has more time to work without distraction, which ultimately adds value.

A note about work-life balance: it is actually imperative for sustaining the success of a business. A lot of organizations see “work-life balance” as a catchphrase that they have to use in their job descriptions, or something that detracts from business success. This is actually quite the opposite. It has been shown in multiple studies that productivity decreases, and on-the-job errors increase when forcing employees to work long hours (sources: https://cs.stanford.edu/people/eroberts/cs181/projects/crunchmode/econ-hours-productivity.html; https://hbr.org/2015/08/the-research-is-clear-long-hours-backfire-for-people-and-for-companies). Furthermore, especially with thought-work, burning out employees is a huge risk to the business; it is a heavy cost to recruit candidates, onboard and train employees, and then get them up to speed on the project or workflow. Pressuring employees to work extended hours is not in the company’s best interest from any perspective.