<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=443149619225659&ev=PageView&noscript=1"> Asking the Big Questions about Agile Transformation

We would like to email you valuable insights on software development and DevOps! (We promise not to stalk you or share your info)

 

Asking the Big Questions about Agile Transformation

Asking the Big Questions about Agile Transformation

If you’ve ever spent any time around little kids, then you know they are fascinated with life’s big questions. Why is the sky blue? Why do we have to have broccoli every night? Why are monkey heads so furry? Why, why, why?

Intrinsically, children seem hardwired to ask. To know. Before they can appreciate the blue sky or pet the monkey head, they need to know why. Sounds silly, but their natural inclination makes them masters at something we software developers too easily forget.

We spend so much time planning how we’ll build things, when we’ll build things, where, with whom and even what we’ll build—that teams can lose sight of the biggest question of all: why. What’s our purpose? Better still, what’s the value of what we’re doing? Because when you know the value of what you’re doing, you know everything.

And that’s not just a question for Product Owners, either. To maximize the benefits of Agile, everyone involved in the process, from deep in the development team all the way through sales and marketing on the business side, should have a fairly strong preoccupation with wondering why.

Why, you ask?

(See what I did there?) Asking why is at the core of successful Agile operations, for one thing. Just ask Forrester Research. Their 2017 Q4 State of Agile Report documented the growth, impact, results and impediments to incorporating Agile Practices and Transformations for both scaled and distributed teams. On the upside, organizations are seeing software delivered faster and with higher quality, and DevOps is steadily making its way into the mainstream.  

On the downside, while teams continue to improve their ability to deliver quality software quickly (who, what, when, where, how), they have not improved  their ability to increase the value of that software to the product or business (why). We can see that evidence in the multiple barriers to successful adoption outlined in the report. Worse still, the top barriers are avoidable, predictable, and solvable, largely because they all concern the question of value. Let’s look at the three of the top issues.

Barrier 1: Lack of Skilled and Committed Product Owners from the Business

Clearly, development teams understand the need for skilled and committed product owners on their side. But what about the business team? In development terms, the Product Owner is the single point of accountability not simply for what the team builds, but perhaps more importantly, for making sure the team understands why they are building it. The Product Owner is constantly determining what is the most valuable work the team could deliver in the near term, and ensuring that the definition of the work (usually a user story) is ready for the team to work on it. Without a clear Product Owner who is empowered to make decisions on what is valuable, it is hard to see how the team could deliver the highest value to the business.  

Recommendation:  Create Your Own

Agile transformations take time. And not all businesses are able or willing to pull people from their day jobs to be Product Owners. Fortunately, they don’t have to be.

If we truly approach this issue from an Agile mindset, we can address any lack of skill, commitment or even personnel in the role of Product Owner on the business side by adapting on the development side. Simply put, if the business fails to provide product owners, the development organization can create their own, with the focus on embedding themselves in the business to understand the needs and also get the business to directly engage with the team(s).

The Product Owner is key to defining product value and continually guiding the team to make decisions that will derive that value. Poorly skilled and noncommitted product owners cannot do enough to drive value. In this model, treat the business group as critical stakeholders, who the team and Product Owner constantly pull into the Agile process.

Barrier 2: Lack of Agile skills in Project Management, Backlog Grooming, and Planning

While this is troubling, it is not surprising. Missing skills can only have two causes: improper training, and/or mismatched personnel.

Many companies handle their Agile transformation by bringing in great trainers to provide great training on the basics of scrum (or another framework). Everyone gets excited, plans are laid, and the process begins. Then the trainers leave.

And the day-to-day tasks of successful Agile adoption were never even addressed. Who answers ongoing Agile questions during scrums? What about planning and backlog building techniques? Even in organizations that continue to provide coaches, most are experts in general scrum and Agile, and not in the art of building great backlogs.

Compound these process migration hiccups with the reality that most business-side Product Owners rarely have the unique mix of skills a Product Owner needs. It’s almost the inverse of the above barrier: business teams inherently understand the question of why; but they rarely have the technical or procedural background to deliver on the who, what, when, and where. So, one might ask, why put them in the Product Owner role at all?

Recommendation: Find Coaches/Partners with the Right Skills

Creating great Product Owners in your organization requires more than a title change for someone with a deep understanding of the business. Just like building backlogs, there is an art to finding, training and grooming the perfect Product Owner.

And it’s worth it. Product Owners are critical to the success of your Agile implementation. Fortunately, help is available, so bring on a specialized Transformation Coach, Product Owner Consultant or dedicated development partner who specializes in this role. The goal here is to establish a relationship with your partner for the long haul. Expect partners to carefully evaluate individuals for the role, and not just pick people because they are available (after all, you could have done that yourself). Once a carefully selected Product Owner is in position, be sure that organizational management provides thorough support for the new role. Understand that your Product Owner now faces a day-to-day challenge of determining what is best for the teams to build—otherwise known as the key to your profitability.

Spend a little time and the required resources to make this role a success within your organization. And lean on your long-term consulting partner. If you’ve hired the right one, you’ll have an excellent go-to resource for collaborating with both the organization and the Product Owner on your ongoing Agile adoption.

Barrier 3: Lack of Agile Executive Leadership

With such an emphasis on key leadership throughout the process, it’s almost hard to believe this still exists as a barrier to business-side Agile transformation. Perhaps that’s because identifying a problem is only half the problem.

Again, it comes down to a question of why. Why transform to Agile at all?

While the development organization may gain quicker delivery capabilities through Agile, executives need to use this new capability effectively to gain the highest value for their business. The flow of market dynamics, competitors, and other business factors do not consider your roadmap schedule as they change, and so executives must be ready to adjust the roadmap in real time. Executive Leadership should adopt Agile values to evolve strategy from an annual or semi-annual event to a continuous process. Test-and-learn techniques, enabled by Agile development, will help facilitate faster, more effective strategic business decisions and enable faster course-correction from mistakes, thus lowering business risks in a fast-paced market. Traditional product portfolio management methods need to supplement their long term planning with short term continuous planning cycles.

Recommendation: Ensure Product Portfolio Management is part of the transformation

Adjust the product portfolio management process to adapt more iterative planning and test-and-learn cycles to help with faster decision making. There are many techniques for doing this, with examples from companies like Amazon, Apple, and Microsoft. Bosch created a steering committee for their Agile teams that interacted with the company’s leaders to communicate and evolve strategic initiatives continuously. This type of executive level support for Product Owners helps align strategic imperatives by creating a continuous alignment between Agile teams that are executing and business direction that is adjusting to market direction. Executive coaching and Agile product coaches can assist by applying the right techniques with your organizational culture.

Conclusion

Agile Transformation can turn your entire product development organization into one that can help you adjust to the market, make quick decisions, and pivot your priorities toward the highest valued work and away from less valued work.  In order to be successful, your transformational approach must include the right mix of people, all carefully selected to fulfill their strategic roles: well trained and highly skilled Product Owners, thoroughly invested Executive Leadership, and integrated Product Portfolio Management and Product Managers. By aligning your core personnel with your newfound Agile philosophy, organizations can allow for the highest potential increases in value and speed to value by ensuring the entire team is constantly working on the right things for the business.

 

The Challenges of Agile Software Development eBook

Recent posts

Coming Full Circle - Delivering Value through Value-Driven Transformation
How Continuous Integration Benefits Your Software Development Team
Driving Value in Digital Transformation
Exploring NoSQL Databases
What to Do Between Sprints

 

Share this article

 

About the author

Michael is the Director of Agile Strategies with Small Footprint, where he leads Agile software development projects and Agile transformations. The goal of his projects is for businesses to deliver high value to customers and stakeholders through adopting Agile across the entire organization, not just the development teams. He has 15+ years of new product development experience, ranging from software engineering to product line management. Michael is a certified Product Manager, Product Owner, and Scrum Master.
Ready to partner with an expert in custom software development? Learn about our fast, cost-effective approach to creating world-class software solutions.
301 N Main St, Winston Tower, Suite 2206
Winston-Salem
NC
27101
USA
Republicii 24
400015 Cluj
Romania

The Small Footprint Blog

Keeping up with the latest in custom software development? Visit Small Footprint's blog for expertise, insights and innovative software strategies.