Maximizing the Value of Your Agile Transformation – Transforming All Levels of the Organization

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.