Product owners and product owners/managers, ask questions when you consider joining an organization that is agile, that is transitioning to agile, or that wants to be agile.

In my experience, organizations don’t mean the same thing when they use those words. Even different people within a single organization often use the words to mean different things.

Let’s explore.

Applying Agile to The Enterprise

The Genesis of Agile

At its core, Agile is a project and engineering management approach for individual development teams.  There are a number of methodologies (Lean, Scrum, Kanban, etc) all intended to drive product development through small iterations, while providing transparency and visibility to allow for ongoing improvement.

Agile approaches are intended to account for the insights of customers during the product development process. Agile methodologies encourage frequent evaluation of work in progress by the customer; thus, the point of agile is responsiveness. Its primary benefit is more successful products that better meet the customer’s needs.

It’s also worth noting that the point of agile is not pure development speed. However, by implementing agile development as part of the effort to optimize the value stream, the speed of value delivery can be increased.

Agile was originally considered in the context of custom software development, built for a single customer, with the customer serving as product owner to ensure what was built solved the customer’s need. (Makes sense, no?)

In startup and enterprise product companies, both assumptions are questionable.

Agile in Commercial Product Companies

Steve Blank and Eric Ries have helped popularize the concept that in a startup, customer development must be paired with agile development to root a successful company. In a startup, the customers don’t really exist yet because a market has not been found.

Eric Ries wrote this interesting passage about how they fit together (emphasis added):

I now believe it’s better to think of ourselves as focusing our energies on unknown problems and unknown solutions. Approaching each of them iteratively is the right thing to do. But the biggest payoff of all can be found when we combine them into one large company-wide feedback loop.

For commercial product companies, the closest parallel to the custom software world–where the team has direct customer access–is generally a startup. In a startup, Agile enables the business to inspect and adapt in the search for a business model.

Whereas a startup is in search of a market as part of establishing a viable business model, an enterprise product company with one or more products in market already has a place in an existing market–with customers, prospects and suspects.

In the old days, products were specified in full prior to being developed, and once complete, they frequently didn’t meet the needs of the customer. Now in both startups and enterprises, we recognize learning continues over time — and we build products incrementally using agile development to optimize our chances of success.

Bending Agile

The bigger the organization and the project team in particular, the more coordination is required to deliver, and the more documentation is required to keep a growing organization marching in step.

A number of elaborate frameworks and processes have been constructed to apply Agile methodologies to groups of teams in the enterprise. One example is the Scaled Agile Framework–or SAFe; another is Disciplined Agile Delivery.

To their detractors, these methods are an application of Agile to “traditional command-and-control mental models.”

How can it not? A growing product company exists to execute on the vision of the leaders, not to go build whatever it wants.

In many organizations, executives, strategists and client-facing teams decide what to build, and then hand it to product developers to create. Others assert they get better results when customers are made part of the process throughout. Still others distribute decision making all the way down to the development teams themselves.

Which type of organization are you in?

How far does Agile permeate the organization?

The real question is whether Agile is buried in the engine room, or whether the captain who’s guiding the ship is involved.

In my mental model of commercial software product companies, I think of a few layers of implementation:

  • Agile might refer to internal projects. Many organizations deploy teams to build products used by other internal teams using agile project management methodologies. This could be implemented even if products built for customers are still built in a waterfall process.
  • Agile might refer to engineering as a whole. A B2B product company may look to agile product development to increase transparency and predictability of the product development process, while still going-to-market in a traditional waterfall mindset. Organizations whose clients demand rigid predictability often find it hard to be agile outside of engineering; and their motivation for moving to agile is not innovation, but rather the ability to better predict delivery to customers.
  • Agile might refer to an entire business including the marketing and sales functions, within a centralized decision making structure. A lean startup uses agile product discovery and development techniques to deliver working software iteratively in response to what is learned speaking to customers. The company might deliver a minimum viable product to expedite discovery, and ships more functionality on an ongoing basis based on what is learned. I generally think of this as a single-purpose business composed of a single business unit, selling one or more products.
  • Agile might refer the entire business, with distributed decision making. FirstRound cites a couple of great examples in a recent post–Spotify and Yammer–illustrating the way revolutionary concepts such as fully autonomous teams helps those companies deliver better product faster. This is fringe organizational structure now, but will it still be in 10 years?
RELATED:  Product success requires agile product management

So wait…what does agile mean, anyway?

Organizational Agile Personality

What agile personality does your organization have?

I’ve come to realize that the organization’s approach to the world, and the degree to which it can be Agile, is driven by the context in which it operates.

In the last six months, I’ve kept coming back to a model developed by Mike Cottmeyer and the team at LeadingAgile.

This model has helped me in conversations I’ve had with individuals in a few different organizations.

Compass

The LeadingAgile Compass

Taking editorial license, here’s what the compass communicates to me:

  • On the horizontal axis are the attributes Predictive and Adaptive, which speak to the market’s preference for predictability versus its need for the ability to respond quickly to change. Organizations in markets where predictability is valued strive to be more predictable. In my experience, the more established a product category is, the more predictability is favored.
  • On the vertical axis are the attributes Emergent and Convergent.  In an emergent market, a company is trying to solve new problems and employs rapid iteration to find a viable solution. In a convergent one, the need is to better execute against a set of known needs in the market.

These attributes are very telling when it comes to the nature of “Agile” that is feasible and optimal within an organization.

Is your product organization being driven to innovate or to execute? Unrestricted innovation is most commonly found in a lean startup. If discovery of a better way to solve a problem causes consternation because it invalidates previously communicated timelines, your organization has a stronger incentive towards planning than towards innovation.

James Turner termed this “Agile In Name Only”:

Agile acknowledges the uncertainty in development estimates, and requires the team to stay “ready to ship,” so that when the decision is made to pull the trigger on a release, all the work done to date can be easily consolidated and shipped. But focusing on keeping shippable units in shippable shape only makes sense if you also embrace the idea of frequent releases, and putting only in the release what fits in the bucket.

In contrast, a company that’s agile in name only will cling to a distant release date and a laundry list of features, but still insist on short sprints and closing stories. At this point, the benefit of short sprints isn’t for the developers or the team, it’s for management, because it lets them focus on their burn-down charts, and chart the progress toward that eventual release that may be a year away.

How important is meeting timelines in your environment?

If you’re in a mature market, you may be conducting business through the Request For Proposal (RFP) and the Statement of Work (SOW). The RFP is a request for your company to illustrate how it will meet the buyer’s needs, not to illustrate the problems you’re prepared to solve.

If there are buyer needs that aren’t solved yet, there may be pressure to commit to meeting them within a certain time period of the beginning of the contract.

The seller in this scenario is operating within a predictive, convergent market.

If you’re creating an offering in an established market that already has a shape, don’t be too married to the idea of being agile to think about what your solution will look like when it’s fleshed out.

In fact, you may have a pretty good idea. Mike Cottmeyer wrote in 2013 about this type of company (emphasis added):

They have a business model and customers that demand fixed dates, fixed cost, and at least some idea of what they are going to get for their time and money when it comes time to deliver the product. These companies aren’t trying to use agile to inspect and adapt and change direction.

These companies are trying to use agile to get visibility into what’s happening, drive up communication, and get things done faster. They are looking for predictability over adaptation… they need to ensure quality… and they need to get product into market faster. Predictability is really though first and foremost the problem most on their mind. Figuring out where to go and what to build… not so much.

This isn’t inherently bad or good, but it does strongly influence the agility welcome within the organization.

RELATED:  The Scrum Product Owner as Backlog Manager

Just make sure to leave room for the solution discovery.  To that end, there’s a different form of innovation.

The Shapes of Innovation

As it turns out, there are two main flavors of innovation that are pretty easily separable:

  1. New Product Development – A startup is usually built around a single product idea; as mentioned previously, agile applies across the business. An organization marketing solutions into defined markets will eventually have a portfolio of cash cows if innovation stops. Some percentage of the product team’s resources should be devoted to exploring unsolved market problems and evaluating new product concepts.
  2. Existing Product Evolution – In a competitive marketplace, especially if some competing offerings have been on the market for some time, there is plenty of opportunity to innovate better solutions. You may address similar market problems and requirements with similar features, but by investing in user experience design and looking at the big picture, you may be able to offer a better solution and gain market share for your offering. It’s possible the product development organization is agile, but the surrounding business may not be.

Previously, I’ve written about the distinction between the problem space and the solution space. This is another angle on that same distinction.

Startups iterate in the emergent problem space via customer development, and adapting within the solution space via agile development, at the same time……. to find a problem they can successfully sell a solution to.

At the opposite extreme is the enterprise product company selling to a predictive market of customers, with a convergent solution to a known problem.

In most cases, these enterprise product companies want to innovate–they want to bring an offering to market that’s different from the competition. Competitive analysis helps drive a differentiated offering.

What’s important to recognize here is that even though the organization may be entering a new market via new product development, they are creating a new offering in a convergent market where lots of expectations already exist. So their market opportunities are somewhat fenced in by those expectations.

These companies are innovating within the solution space–but usually not within the problem space, since the problem is already clearly defined in the prospect’s mind.

Which Way Does Your Agile Lean Anyway?

As a product professional, the important takeaway is to think about the kind of organization you’re in, or the kind you might join.

Is it lean? Without getting deep into the rich methodologies derived from Toyota’s lean manufacturing legacy, one simple question to ask is how much “waste” exists in your current process?

Are you building features before you know whether they’ll be needed, or before you know whether those features solve the business problem they’re intended to solve? If so, you potentially have a large opportunity for waste reduction.

(Side note — there’s a great talk by Dan Olsen I recommend on Lean Product Management.)

Companies go after markets in different ways, and it’s important to understand if you’re comfortable with the business strategy before you sign on to the product team.

Understanding the business strategy and how agile or lean an organization is impacts product team processes. Among others, voice of customer efforts, investment in discovery and staffing. You want to bring in people who are comfortable and prepared to operate within the organization’s constraints. And you want to agree to work for an organization that is operating in your comfort zone.

I’ve run into several organizations where the Product and Development organizations believed their organization is “Agile,” and maybe engineering is using agile methodologies, but the business through its actions demands predictability and meeting commitments. People in that kind of organization may say they’re Agile, and even share how Agile they are in engineering with their prospects. But what they care about is meeting commitments.

It’s in this kind of environment that a passage like this rings true:

Agile was an important step forward in acknowledging the importance of testing and iterating based on customer feedback, but the vast majority of its implementations are targeted at increasing efficiency and control vs empowerment or self organizing teams.

One of the elements of agile we haven’t touched on in this post is self-organization. When the outside environment values commitment over innovation, it’s difficult to release enough control for a team to truly self-organize.

RELATED:  Resources for Starting a New Product Management Job

In this scenario, you might be in an agile product organization, which may think of the business as agile, but the business around the development organization is really more like waterfall.

It’s hard to transform an organization from the inside-out, because customers pay the bills.

But a few are successful doing it. Zappos is moving to “holacracy“:

[Holacracy] replaces today’s top-down predict-and-control paradigm with a new way of achieving control by distributing power. It is a new “operating system” that instills rapid evolution in the core processes of an organization.

According to a recent piece in QZ, “Zappos, which has 1,500 employees, will be the largest company to date to implement Holacracy.”

You have to show business outcomes–higher revenue or lower cost–from releasing control from the center of the organization, or you won’t win the support of the business.

But some companies are starting to see it as a way to scale companies in the knowledge economy.

What if your current environment is having an identity crisis?

What if people in your organization use the word “agile” differently? What if some argue that you’re agile when you really aren’t–at least, to the same degree as behaviors and expectations might suggest?

Get it out on the table.

Or, maybe sales is pushing for commitments, but executives are on the same wavelength as Product and development.

Again, get it out on the table.

I don’t recommend calling an all-hands meeting to debate which way the company should go.

That’s above your pay grade. And it’s far murkier than any black-and-white distinction.

If you have products in market, one place you can start is calling out explicitly when the conflict is manifesting. For example, when you’re being pushed to commit to functionality on a timeline, making sure everyone is aware of what strategic initiatives that commitment will jeopardize.

The Impact on Hiring

If you have influence on organizational development, this is an important area to pay attention to.

The kind of organization you’re trying to be should play a big part in the kind of candidates you seek.

Are the sales and marketing teams staffed with technology-savvy professionals? They may be familiar with agile, but as you can imagine, you’ll want to go deeper. Did they work in an organization where engineering conducted sprints, but where everything else was fixed?

If that organization was completely uncomfortable with uncertainty, and you’re trying to be an adaptive organization in a convergent market, that hire may not get you where you want to be.

What about engineering? If you explain your company’s outlook and definition of Agile inaccurately, how does that impact hiring? Are you a predictive organization hiring developers who are adaptive and emergent at heart, who will not be comfortable with commitment at all?

What if you’re evaluating a potential employer?

Now the decision is on you.

What kind of product role do you want?

You may feel more fulfilled in an idea-to-product, pre-launch world where there aren’t as many clients and commitments. You’re getting to define a product, if not define an entire market. Lots of flexibility but no direct feedback from paying clients who like (or don’t) your work.

Or, you may be more comfortable running a ship that has already sailed, managing the incoming customer requests and big whales writing features into their contracts. Here you have paying customers sending feedback almost constantly. You’re regularly getting insightful feedback about every little change you ship.

The last thing you want is to be in an organization where you don’t fit. Or to be helping build an organization with one personality, by hiring team members with a different one.

Wrapping Up

What other challenges have you experienced with mapping your organization’s practices to the expectations of your market?

Share in the comments.

 

Image source: Flickr