Collaborator-8-3-CTA-banner

Agile and The Enterprise: Part 1

Agile Development

This blog entry is primarily based on a wide ranging conversation the author had with Steve Johnson in late September 2013. Steve Johnson is a product management and business process expert with over 20 years of experience, with both bringing products to market and helping others do the same. You can learn more about him and his eBook From Fragile to Agile on his website at Under10Consulting.

Making the move from traditional waterfall software planning, development and testing models to an Agile approach brings a set of process and culture challenges. The most obvious ones are on the development team that has to embrace Scrum, XP, or another variant of Agile development. But less talked about is the positive but possibly challenging impact that the wider organization should feel. A good Agile implementation can and should reveal challenges and shortcomings on other teams in the enterprise. Addressing these issues promises a stronger company and a better product.

In this two-part blog series we’ll discuss some of the most important of these issues: Part 1 discusses the buy-in necessary from the ‘P’ roles of Product Owner, Product Management, and Product Marketing

1. Agile demands a “product owner” who may not actually exist yet

In a conversation about a multinational software company, Steve Johnson paraphrased a conversation he had with their development leadership. “They said, okay we have ‘drunk the Agile Koolaid.’ Now, the marketing team needs to provide us a product owner for each of our development teams.” Basically, the development leadership was saying the company needed to quadruple the product management headcount.

Leadership teams need to evaluate and make decisions about the wider implications an Agile development implementation can reveal about the organization. A development organization that successfully moves to Scrum, the most popular Agile planning method, will need a product owner – a person available to represent the voice of the customer on the team in a dedicated role; this is a need that may not have previously been properly staffed. Traditionally, a Product Manager was responsible for that role and executed it in a number of ways, usually with some documents and perhaps a weekly status meetings and frequent informal conversations. Often, each Product Manager was also responsible for many other products in a company’s portfolio.

But now, with a more effective and streamlined Agile development team hungry to learn about and meet customer needs, they need a product owner with deep customer insight for each product… with daily responsibilities… to be co-located with the development team… to be available on-demand for the team. You get the idea.

An enterprise organization with a deep product portfolio has to make a decision.

  • Do they drastically increase staff to provide product owners for each product?
  • Do they revamp what existing product management, product marketing manager, and other roles mean?
  • Do they allow a software engineer who may or may not have voice of the customer insight act as the product owner?
  • Do they ignore a fundamental role required by the process?

An organization may need subtle or radical change to ensure that an Agile development team doesn’t end up in danger of, to paraphrase Steve, “building the wrong thing faster than ever.”

2. Agile impacts all the “P” roles—Product Owners, Product Managers, and Product Marketing Managers

In organizations with an Agile implementation underway, Steve has heard things like, “we have product managers saying development is moving faster than I am… They are asking me what they should work on next… I’ve been so busy doing the rest of my job I haven’t been able to participate as closely with development as they want me to…”

In smaller organizations, when Product Managers do formally exist by title, their multi-hat role usually encompasses everything and the kitchen sink. They are like Woody Allen’s Zelig—they morph into Sales Engineers when on a sales call, public relations folks when on a press call, and product marketers during product rollout. If the Product Management role doesn’t formally exist in a smaller company, usually an engineer or executive takes that role—if not by title, certainly by action.

Product Manager job definitions may include product owner responsibility on an Agile Scrum team. But if a product manager acts as a product owner with daily responsibilities on the scrum team, how can that person be expected to be in the field learning about customers and the market? To be the strategic portfolio planner that the C level suite demands? And at the same time be a sales enablement resource, working with marketing and PR on rollout planning and execution? And who will fight all the fires—from support to pricing issues to investor presentations?

One reaction to Agile is a more pointed honing and specialization of roles. As Steve points out, because Product Managers have so many demands put upon them by various constituencies, some larger companies are breaking out the roles and responsibilities in a more specialized way.

One possible way to better facilitate Agile across the enterprise is to look at roles in this general way:

  • Look at the Product Manager or Product Leader as a portfolio-level roadmap and strategy owner, focused on the business and a product portfolio. They are essentially the “CEO” of the product line. The Product Manager maintains close multi-way communication with the full matrix of enterprise teams. The Product Managers have a special relationship with the two roles below, but don’t necessarily sit as a required member of the Scrum team.
  • The Product Marketing Manager focuses on rollout planning, awareness creation, and lead generation. The role can be broken down further into Content Marketing Manager roles who specifically build and/or produce content.
  • The Product Owner sits directly on the scrum team and participates on a daily basis. They can directly provide feedback as the voice of the customer collected from the Product Manager and their own customer interactions.

There are other ways to break down the “P” roles that the reality of your organization may dictate. The key point is that a voice of the customer needs to sit on the scrum team to learn about and transfer current real-world customer and market information to the team.

 3. Positive impacts on non-engineering management

Steve said of Agile, “It optimizes software development, an area of the company that needs to be optimized. But it can also reveal how broken other areas of the organization may be.” He tells a story about a development team that hadn’t had a release for 18 months. The engineering teams were crippled by frequent changes in priorities. Members of the executive teams were constantly saying, “Now, this is the most important thing,” usually immediately after visiting a customer or tradeshow. The team was so paralyzed by the ever-changing requirements, that a lot was getting done but nothing was ever getting finished.

Agile development can be a more effective response to indecisive or fluctuating management messages and seemingly never-ending requirements changes. The management organization will also have to make changes to make Agile development a success. But Agile brings good news, not just new rules, to a highly involved management team.

An Agile approach can help break down large projects in practical and flexible ways that make sense not only from an engineering perspective, but also from a “communication with business teams” perspective. Properly implemented, there are many advantages to Agile that can help foster better communication and collaboration with non-engineering management teams. They include:

  • Sharing regular insight on progress of specific features and customer problems.
  • Providing a formal method for those outside of development to communicate with product owners about “the feature we forgot but really need”—and a way to communicate impact and schedule changes based on a re-prioritization.
  • Increasing cross-functional team cohesion and trust because all extended teams have a formal way to see progress on a regular basis. Compared to before, when they may not have ever seen nor understood project progress.
  • A great “behavior training” side effect in that non-engineering managers will begin to better understand work in progress, when they can (and can’t) expect a change in plan, and the true impact of changing priorities.

Summary, and the next installment

Part 1 of this two-part post discussed some ways in which an Agile development methodology impacts roles beyond programmers and testers. A good Agile implementation will have some level of impact the ‘P’ roles of Product Owner, Product Manager, and Product Marketing Manager as well as other non-engineering managers. In Part 2 we’ll look at how an Agile implementation impacts strategic planning and roadmaps.

SmartBear’s portfolio supports your Enterprise Agile teams

Regardless of which Agile approach your team takes, SmartBear is there with development, testing, performance monitoring, and team collaboration tools to support your development workflow. Learn how SmartBear’s suite of tools can help your Agile processes. 

Has your team implemented Agile? How has it changed your workflow? Let us know in the comments section below.

See also:

e5bf4e29-8c40-404c-a2cd-dbc3446a4666

subscribe-3