The Agile Transformation: It ain’t easy…

What is agile?

“Agile” is a software development approach that prioritizes flexibility, collaboration, and continuous delivery and testing. Unfortunately, over the past several years, Agile has become the panacea for typical project delivery challenges and has sought to replace the more traditional Waterfall method that is found in nearly every other sphere of Project Management.

Though it has its roots in software development, we now see Agile deployed in many product-oriented environments, even those that are physical. But why should an organization contemplate an Agile transformation?

Over the years, as a technology leader, I have either led or been part of a half-dozen agile implementations or transformations. I would call NONE of them a resounding success – but I learned a great deal from each one. I can also proudly report, that there is only one mistake that I continue to repeat (more on that later).

So, why go Agile?

Compared to Agile, its distant cousin, Waterfall, follows a linear, sequential process. It emphasizes thorough planning and documentation up front and focuses on delivering a full-featured product at the end of the development process. It features a more rigid and defined process, with little room for changes to requirements or priorities. Therefore, attempting to deliver a product leveraging Waterfall methodology may be challenging when:

• all of the requirements aren’t fully understood up front.
• there isn’t a high degree of confidence that the “customer” will find value in the product.
• there is a strong potential that requirements could change.

Further, because the “build” doesn’t begin until design is completed, challenges encountered during the build process could send then entire project back to the design or requirements phase.

While it can lead to faster delivery of the product, the primary focus of agile is not on speed but on delivering value to customers and being responsive to changing business needs. Leveraging the concept of a Minimum Viable Product (MVP), Agile teams aim to deliver working (not completed) products as quickly as possible, but they also prioritize maintaining a sustainable pace of work and avoiding burnout. This means that they may not always deliver a product or feature at the fastest possible speed, but rather at a pace that allows them to maintain high levels of quality and customer value.

Organizations looking to increase increase flexibility are prime candidates for this methodology. Agile allows organizations to respond quickly to changes in the market or business environment, as it emphasizes the ability to adapt and pivot as needed. Further, leveraging a “product-oriented” approach, Agile can help with better alignment with business goals. It helps to align development work with business goals and customer needs, as the product owner works closely with the development team to prioritize and define requirements.

Where there is a degree of uncertainty, the “ceremonies” associated with the methodology promote frequent, ongoing communication and collaboration among team members, which can lead to more efficient and effective problem-solving. Rapid iteration and continuous testing and feedback, agile can help organizations deliver higher quality products.

Finally, as organizations look to revamp their employee value propositions, Agile places a strong emphasis on teamwork and collaboration, which can lead to improved team morale and a more positive work culture.

A word on the “Triple Constraint”

In either Agile or Waterfall, Project or Product Managers are faced with the same “Triple Constraint”: Time, Cost (or Resource), and Scope.

In the Waterfall approach, because the design work done upfront, the scope is pretty well defined and understood. Similarly, a project schedule has been defined, typically with a delivery date in mind. The critical path is determine, and resourcing or cost is determined based on the now fixed Scope and Cost. Cost is typically your dependent variable in Waterfall (assuming there can be no slippage in time or scope).

With the Agile approach, there is a defined team that has finite capacity. That team will work in “sprints” (typically 2-3 weeks in duration). That said, by definition, your Cost (in this case, the cost of the Sprint team) and Time are implicitly fixed by the methodology, leaving the Scope (what all the team will deliver) somewhat of the dependent variable. Overtime, as the team becomes more experienced with each other, the product and the customer, one would expect to see an efficiency lift, and as a result, more efficient delivery of the feature that comprise the overall scope.

So what is the right place for Waterfall?

Agile is not a fit for all products or products. So, be sure not to force it. Waterfall may be the better option when faced with any of these constraints:

1. When the project requires strict compliance with regulatory or legal requirements: Agile’s focus on flexibility and rapid iteration may not align well with projects that have strict compliance requirements.
2. When the project requires a high level of predictability: Agile is based on the idea that requirements and priorities can change frequently. If a project requires a high level of predictability and a fixed scope, agile may not be the best fit.
3. When the project has fixed deadlines: Agile emphasizes delivering value to customers and being responsive to changing business needs, which means that it may not be a good fit for projects with fixed deadlines.

Why is implementing Agile so difficult?

In short, Agile requires a complete rewiring of how we think about delivering capabilities. It is very difficult to implement Agile in a scalable, sustainable, and productive way without thinking about the broader organizational impact. There are new roles required that don’t currently exist in the organization. Sure, you can train some of your “hi-pots” who demonstrate a desire to grow and learn. But if you’re not thinking about the cultural implications/requirements, scaling your transformation will be difficult at best.

The following is a summarized collection of lessons-learned that I’ve gathered over the past 10 years. There’s nothing novel or ground-breaking here. Yet, these are the same traps I commiserate over with my colleagues time and again:

1. Lack of understanding or buy-in: Agile transformations require a significant shift in mindset and culture, and it’s important that all stakeholders understand and support the change. Without sufficient buy-in and leadership at ALL levels of the organization, the transformation is likely to fail. By the way, I haven’t found top-down to be particularly successful. Most senior leaders have a limited understanding of Agile, and rarely understand all of the implications of what the transformation will require. That said, it must have executive support and sponsorship.
2. Failing to establish a solid foundation: Agile relies on a set of principles and values that should be embraced by the entire organization. If these principles are not properly established, the transformation is unlikely to be successful. It is important to take inventory of your organizational values and culture and ensure they at least somewhat align with the Agile Manifesto. If they don’t, it may require a redefinition of the organizational values, along with a well defined Change Management plan to ensure adoption of those new values.
3. Lack of proper training and support: Agile transformations require all team members to learn new skills and ways of working and thinking. Providing adequate training and support is crucial to the success of the transformation. As such, it is important to “seed” your team with “Agilist” who can help your team round the change curve. At a bare minimum, consider an Agile Coach.
4. Not being flexible enough: Agile is all about adaptability and flexibility. If an organization is too rigid and unwilling to change, the agile transformation is likely to fail. Further, it is important to not be subsumed by the dogma of Agile itself. Every organization, every product, has nuances that require that Agile be tailored to most appropriately meet that team’s needs.
5. Attempting to operate in a hybrid model: Organizations often split their resources across Agile and Waterfall teams – or worse, on business-as-usual task (BAU). This lack of dedicated team resourcing dramatically slows the Agile process and often leaves team members waiting unproductively for key members to free up.

Driving Agile Transformation from IT – That’s even harder! Don’t Do IT!

This is a mistake that belongs at the top of the above list which I referenced as the one pitfall that I continue to encounter – and I can easily see the opportunity to repeat it in the future – perhaps, a matter of circumstance. Insurance, where I’ve spent the overwhelming majority of my career, tends to be a somewhat change-resistent industry. Therefore, seeing the opportunity to bring the goodness of product-oriented delivery via Agile to each organization I’ve worked with seemed nothing more than a given. However, seldom are there business folks who understand the potential and I’ve not yet developed the
“sales” skills to convey that value in such a way that would generate a groundswell from the business to drive the necessary reorganization, re-tooling and training, and the realignment of values.

An agile transformation should be driven by the business. Agile prioritizes delivering value to customers and being responsive to changing business needs, and as such, it is important that the business drives the transformation process. Consider the following four dynamics:

1. Business understanding: The business is best positioned to understand the needs and priorities of the customers, as well as the market trends and competitive landscape. As such, they are best equipped to drive the transformation process and ensure that it aligns with business goals.
2. Ownership: If the business is not driving the transformation, they may not feel a sense of ownership over the process and may not fully embrace the changes. This can lead to resistance and a lack of buy-in, which can derail the transformation.
3. Value alignment: Agile is all about delivering value to customers, and the business is best positioned to understand what value means to their customers. By driving the transformation, the business can ensure that the team is focused on the most valuable features and requirements.
4. Business agility: The ultimate goal of an agile transformation is to improve the organization’s ability to respond to changing business needs and deliver value to customers. By driving the transformation, the business can ensure that the changes are aligned with their needs and goals.

So, who’s the Product Owner?

As part of my often ill-fated approach to driving Agile transformation from IT, I’ve often opted to install an IT resource as the Product Owner (PO). As you come to understand the role of the PO and marry that understanding to the four aforementioned reasons for business sponsorship, you’ll then realize the reasons why it usually doesn’t work.

Product ownership refers to the role responsible for defining and prioritizing the features and requirements of a product. In an agile organization, the product owner typically sits within the development team and works closely with the development team to ensure that the team is working on the most valuable features and requirements.

However, the specific placement of the product owner within an organization will depend on the specific needs and structure of the organization. In some cases, the product owner may report to a higher-level manager or executive, while in other cases they may report directly to the development team.

It’s important to keep in mind that the product owner plays a crucial role in ensuring that the development team is building the right product for the intended customers, and as such, they should have a strong understanding of the customer needs and market trends. They should also have the authority to make decisions about the product roadmap and prioritize work for the development team.

This is a very specific role that requires very specific skills and temperament. Again, simply picking your “best-available athlete” to lead the charge may not work without the right training. Further, the PO must be dedicated to the product team. Attempting to split your PO across multiple responsibilities outside of that specific product’s lifecycle will usually result in a frustrated development team and missed expectations.

The MVP Challenge

A minimum viable product (MVP) is a product development strategy in which a new product is developed with just enough features to allow users to experience the core functionality of the product. The MVP approach is designed to allow a company to test the market for a product and gather feedback from early adopters, which can then be used to iterate and improve the product.

You can see how the MVP approach can de-risk product development and launch when used correctly. The problem I’ve encountered lay within a misappropriation of the term. Somehow, in every transformation I’ve been part of, the MVP becomes a misnomer for Phase I…because with traditional Waterfall delivery, the business has been trained that “Phase II will never come…so get it now while you can”.

This mindset flies in the face of Agile and leaves significant value on the table. “Large” MVPs can not be delivered in a few sprints and therefore the team never gets the feedback that so often improves the product along the way. Without that iterative feedback, changes to the product become harder to accomodate.

When establishing the scope of the MVP, at each feature, ask the simple question: “If we didn’t deploy this feature, would it render the product useless to the customer?”