In a rush to adopt an Agile transformation for your big company? Slow down! I detail why this is a bad idea in my book The Dolphin and the Tortoise: How Self-Awareness impacts Agile Transformations, but I know a lot of you want the answers now. If an Agile transformation turns your company into one that embraces collaboration, flexibility, and self-organization, don’t you want to get there as quickly as possible? Not necessarily—especially if you’re a big company.
Change affects every company. Especially big change. And particularly when it happens in big companies. It can slow down or even halt the overall product organization and it’s really easy to underestimate the scope of such an undertaking.
It’s no wonder a lot of companies struggle to implement Agile best practices in a meaningful way. They have a tough time reorganizing workflows and roles that are sustainable when they hurry to get Agile in place.
Every company is different and has unique challenges. However, there are some commonalities to be found after a transition to Agile. Let’s take a look at the before and after from a Product Owner’s (POs) perspective.
From Part-time Supervisor to Full-time Product Owners
When an Agile framework is adopted, watch out! The role of the PO completely changes. POs used to have a part-time role in the more traditional waterfall model, partially engaging, during up-front requirements definition and final testing. However, after an Agile adoption the PO enters into a daily commitment. The PO’s role changes and they become a full-time, constant-contact member of the scrum team, alongside software engineers.
Don’t want your PO to be overwhelmed with work? Don’t worry—their actual workload doesn’t change that much. Agile POs define requirements on fewer projects than before, but they are now required to be more present. This means that meeting engagement goes up, but the amount of time spent on documentation goes down. Once the PO gets into the new Agile groove, they find that their workload is the same weight just distributed differently.
The PO Identity Crisis: Redefining the Value of a PO
In many cases, when a company moves to agile, it converts its Business or System Analysts into POs. Good analysts in the traditional waterfall model were considered detail-oriented, thorough, and subject matter experts. They were known as the experts with all the answers, but oftentimes their role made it possible to miss the perspective of the customer when defining product goals and needs.
Undergoing a change to Agile makes it so that the PO now serves the customer by representing the customer. It’s no longer their job to have all the answers—and that’s a good thing! Nobody actually knows it all. Instead, their new job is to be the authority when it comes to asking the right questions and getting honest answers from real customers.
Being thorough and detail-oriented are great qualities, but they’re no longer priorities. A PO on an Agile team knows how to dismantle complex concepts into small, digestible, bite-sized pieces. They’re effective at sharing their knowledge with stakeholders during in-person meetings, through epics and/or features. POs have become top tier at asking questions in the new, fast-moving system.
It’s not about knowing the answers. It’s about getting them.
Trading Detail-orientation for Ambiguity
Adopting Agile affects the product team more than any other group in the organization—including IT and software engineering. Why? Because it alters how Product behaves, plans, and operates both inside and outside the company.
Agile isn’t just about learning to do a job differently or figuring out a new project management tool. After the change to Agile happens, POs are asked to leave behind the complicated Business and Functional Requirement Documents (BRDs and FRDs) they were used to delivering. Instead, less detail is created in features and stories and the Minimum Viable Product (MVP) is implemented because it quickly identifies the fastest, easiest, and most affordable way to validate a product hypothesis.
This new agility thrives with more room for client feedback and innovation—and plenty of questions.
Building a Bond with Software Engineering While Displaying a New Level of Leadership and Engagement
Companies who adopt an Agile environment increase their odds of being successful, but the change also requires some help from the Product organization. These companies must also say goodbye to the “us vs. them” mentality often seen between software engineering and product personnel. Product and software engineering become inseparable in an Agile setting, which is why collaboration is key in this newly matrixed environment.
Product and software engineering teams need to interact on a daily basis and work together to solve problems. As you can imagine, this can be challenging to enact instantaneously—and often impossible. Changing how we think and act requires proper facilitation so that everyone has time to adjust.
Can Everyone Make the Switch to Agile?
Unfortunately, moving to Agile isn’t for everyone. Success isn’t guaranteed, and it’s nearly guaranteed to fail if it’s rushed. Success becomes more difficult the larger a company is, particularly for Fortune 500 and B2B companies. If your company falls into this last category, you’ll need a lot more preparation compared to smaller companies and startups.
There’s no singular approach to implementing Agile. It is known that Agile requires everyone’s participation and buy-in to be successful, but that’s just the first step. There are strategies that work best, and properly training and coaching the key players during the transition has proven to be critical. Careful preparation within the organization during the change to Agile is key, which means the process cannot be rushed. Rushing in the midst of a product change can lead to double work and confusion in the future. Just don’t forget that with the right attitude, coupled with realistic expectations, you can succeed.