How to Involve the Entire Organization in Your Agile Transformation "Product people - Product managers, product designers, UX designers, UX researchers, Business analysts, developers, makers & entrepreneurs October 10 2019 True Agile Development, Agile Transformation, Product Management Skills, Stakeholder Management, Mind the Product Mind the Product Ltd 952 Product Management 3.808

How to Involve the Entire Organization in Your Agile Transformation

BY ON

When product and engineering teams adopt an agile way of working, it’s all-to easy for them to leave other departments in the organization behind. But, there are techniques you can use which help to make your agile transformation more acceptable for everyone else in the business.

Agile transformation, undoubtedly two words that strike fear into the heart of any product organization.  It should be an exciting time, with tough conversations, compromises, and hopefully good progress. But even if you successfully form a single team, there’s another problem… the rest of the organization has no idea how to deal with you.

Did you know your agile transformation would require a transformation of the entire organization?

Sales, account management, and marketing will often look for that big idea to wow customers:  “I’ve got something new, and it’s going to knock your socks off!”  Your finance team wants tight clarity on what they’re paying for (typically a feature) and a clear understanding of its return on investment.  And your HR team wants clear goals that an employee can independently control to help measure their performance.  Working incrementally toward outcomes that the TEAM is responsible for just won’t work in these traditional models.

As a product leader, you may not always have control over affecting change across the entire organization.  However, there are steps you can take to help other teams more clearly understand what’s happening and how it’s good for the company.  Below are four techniques you can start to use immediately that help to make your transformation more palatable for everyone else.

1. Involve the Organization

Hopefully most of us realize that we’re not all-knowing.  Yet, when we talk about creating tests in our products, we too often reserve brainstorming new ideas for the product and design team. The more you can engage different perspectives from the rest of the organization, the better the chance you’ll find the right one. However, you need aggressively to solicit suggestions. I recommend an open design thinking session where you bring in a couple representatives from each team (sales, account management, marketing) and walk through the data together.  For maximum effectiveness, ask the leaders of those teams to assign people.

BONUS: With these sessions, you’re teaching the participants the processes of design thinking.  This will allow them to take it back to their own teams.

2. Get Everyone Comfortable With Themes

Themes can be marketed, sold to customers, and generate excitement.  Strategic themes of investment are more powerful than a list of features.  Granted, customers often want to see their specific ask on your roadmap, but that becomes even more powerful if you can transform their requests to fit your themes –  it demonstrates that you’re aligned!  Develop long-term roadmaps in themes and report to executives with your investment levels relative to those same themes.

BONUS: Themes can be very useful for product managers when a request can’t be worked into a strategic theme.  It’s much easier to explain your “No” if something doesn’t align with your strategy.

3. Keep Everyone in the Know

It’s hard to the rest of the organization to keep up when you make small incremental changes and constantly evolve based on data. They may start to feel like you’re doing your own thing.  I use product update meetings “creatively” to address this. The meeting content is created for everyone outside the product and engineering teams. The goal is to share:

  1. What we’ve done and did it work.
  2. What we’re working on now and what you should expect to see shortly.
  3. Where we’re going and why.

Putting together this much content can be a drain on the product team, so I recommend these are held no more often than every six weeks.  I also recommend holding them in person or broadcasting to the rest of the organization.  This gives you a chance to elaborate on intimately familiar topics that may otherwise take a long time to explain in writing.

BONUS: This meeting gives your team a chance to practise their presentation skills – and everyone can benefit from that.

4. Maintain a Scoreboard

I often ask teams what a basketball game would look like if nobody kept score: very little urgency, individual self-identified goals might take precedence, and generally it would be a pretty terrible game.  Yet, at work we do this all the time.  We show the scoreboard at the end of the game, or only monthly do we report progress.  To be really effective at keeping teams focused on the goals, you need to create some “scoreboarding”.  Maybe it’s a report that gets sent every day, or a TV with that dashboard.  What about something like Smiirl’s physical dashboard?  Whatever form it takes, it must be present and discussed.  With a clear scoreboard, the rest of the organization understands exactly when you’re succeeding and when you’re not.  It can make you feel a little vulnerable to put your success metrics on the wall, but that vulnerability goes a long way towards creating trust.

BONUS: When the scoreboard metrics are not moving, the rest of the organization gets particularly creative about how to turn that around.  Now, you’re really getting everyone involved!

If you’ve read anything on agile transformation, you already know the mantra: This is Hard. Don’t forget it.  Focusing on how the product and engineering team’s changes affect the rest of the organization can seem a bit overwhelming.  However, if you bring everyone along with these techniques you have a greater potential to turn from a good team to a great team.  And, isn’t that why we have these jobs?