Editorial note: My blog’s ScrumMaster let me know that this post was a super-epic with poorly-defined target user personas, so I will decompose this into more actionable User Stories. I’m leaving this draft in place because I want my Product Owner followers to know that it’s okay to admit you didn’t size or prioritize things right the first time…be genuine.
So now you’re all agile…
At scale, the “Hero-Scrum” paradigm falls apart. A product becomes too large for one team, then the number of teams becomes to large for the Product Owner & CEO model to work. A company working toward agile transformation could slowly restructure toward mini-CEOs; but the truth is, the organizational switching costs are too high to make this a realistic option. Be honest – those that own the customer relationships and those that own the technical communication are, respectively, too specialized – and great at their jobs – to start mashing them together as peers.
That said, I see a clear skew in agile transformation consulting and especially entry-level Scrum training toward protecting the team against the more powerful Product Owner. While this may be a tactical prejudice when the role is played by your boss, my first-hand experience has been the opposite. In scaled transformations, the more likely scenario is that Business Analysts, Project Managers, Jr. Product Managers, Quality Assurance Analysts, or Support Engineers of the organization are asked to rise to the occasion and somehow, instantly and powerfully, lead a team to greater autonomy, mastery, and purpose.
{inspirational anthem plays in here}
Let’s be real.
The two fundamental hero images intrinsic in most Scrum courses – the ever-vigilant, time-protective ScrumMaster and available-part-time, drunk-with-power Product Owner – is meaningless in the more complex patterns of large organizations.
So here are the top three winning tactics that can help mid-senior managers and individual contributors succeed.
#1 – Startup Principles are Worth Your Time:
As I’ve mentioned before, the ability to ensure work is meaningful to the user-in-pain and the customer paying to resolve that pain (occasionally but not always the same person) is super important to the health and motivation of the engineers. The shorter the time between empathy and resolution, the more meaningful the work, the more likely the direct correlation with revenue, and the safer the jobs and projects of the engineers become.
The big “evil” business “side” in a large company doesn’t need any of that in order to maintain risk aversion and product agility. Cancelling a three year project before a customer saw it because a better project was two years in WAS their agility.
Congratulations on your agile transformation, but when you said “agile” you really meant lean concepts like “small batching” and “level-loading”. As a Product Owner what you really must have is lean startup principles. The moment your team became an agile team, you became a new venture. You now have to proactively validate all learning about three things:
- Product risk – The right thing was built to solve the pain of large (enough) but narrowly (enough) focused group.
- Market risk – The ability to build and continuously improve the viability of your product’s business model.
- Customer risk – The ability to get the solution into the hands of the customer.
Project risk – as you once knew it – is gone. You don’t have a deadline to track against, you have angel investments from your Product Manager(s). You don’t have technical risk that your estimates were wrong, you risk the loss of “investor” (c-suite, VPs) confidence that you know what you’re doing. Can good forecasting and transparency help? Sometimes. Unfortunately, some of us get promoted from T-Ball to the Majors with no notice that it even happened.
Product Owners – strengthen your relationship with your Product Manager like they are the venture capitalist and this is your first company. The expected return is 10X due to the risk. Many of them are having to let go against their will and trust that you know what you’re doing.
Key skills to learn: The Lean Canvas, Innovation Accounting, Validated Learning
#2 – Everything is Marketing:
There is a java team, and a product management team, and an inbound sales team. Marketing is not a department. In a large company, yes, there is a corporate group in charge of advertising, branding, messaging, and copy. As a Product Owner, embrace the idea that the marketing team is only 1% of the marketing the company does. Everything is marketing – and you just became a sales(wo)man. Every time you let a critical defect through and an engineer complains to their spouse and their spouse bad-mouths the company to their friends at a cocktail party – that’s marketing. The world is a small town. What you do matters and nothing is in the shadows.
Treat memos like Tweets with a million followers. Fake your own notoriety if you need to. As it turns out, you are uniquely positioned to make an enormous difference in how effectively your team meets the needs of customers. Luckily, you don’t have to just make that stuff up from scratch! Other people at other companies in roles you never thought to cross-pollinate against have ESSENTIAL skills that are PROVEN to work. Decades old. Seriously. And most of them give that training away just to get you to spread the word!
Key skills to learn:
- For Roadmap / Release Planning – Talk to a Custom App Dev guy. I can make intros if you like. Most of them are so desperate for attention, you could make up a fake product and string them along for months. Anyway. The good ones do Story Mapping and MVP scope for FREE as PRE-SALES. Lucky you – you already have a product manager to building software for! You still need to be consultative to ensure collaboration and rational planning occurs. Same advice as your personal life. Date your spouse. Start the courtship over again occasionally. Things have changed, don’t act like you’ve memorized everything and communication can stop!
- For Stakeholder Alignment – Study the super hot topic of starting your own company. You’ll be glad you did. On ramps. Assumption mapping. Balanced scorecards.
- For Sprint Planning – Its a solution pitch. PLEASE have an agenda. PLEASE gain all necessary information and buy-in for prioritization prior to involving your developers. Want an example? Google “SAP Digital Transformation” and you’ll see that they have an example solution pitch for every industry. This isn’t new territory you’re exploring, just a new town with a new bar but your old friends came with you.e
- Sprint Reviews – There is an art to the tell-show-tell demonstration. Engineers and engineer leaders can be especially bad at this (and I’ve learned from plenty of terrible webinars as well). The attitude “you paid me to build it, look its right here, no questions? great….” is going to erode whatever influence you aspire to have. Tell your stakeholders what you accomplished. You know, business goals. Product Pirate Metrics. Tell them why it matters. You know, to revenue and the sustainability of the business as a whole. Give them numbers if you know them. Then anchor your demo against a pre-defined roadmap. Lead feedback as you go with open ended questions. Follow the poll / show of hands, individual follow-up routine. Most importantly, this means taking it seriously enough to prepare in advance. Everything is marketing!
- Sprint Retros – Until you start making falsifiable hypotheses, you have no experiments. Without controlled changes to variables, you are not engaging in empirical process control. You’d be amazed what a 4th grade poster about the Scientific Method could do for your team. Test at least two assumptions “changing X in the product will influence Y positively” and “changing practice A as developers will impact outcome B as a team”. There is no learning without defining what a successful outcome is prior to conducting the experiment.
#3 – Show Your Work (Too):
No really, make a scene. Draw a picture. Use a kanban board on your wall. Write haikus. Whatever you do, show it off in progress. Disappearing to document things makes you irrelevant. Show people what you do, how you do it, and why you do it – aspire to be like the great chefs. You might even realize that people actually care how the sausage is made.
The best way to do this is to teach others. The only way to build cross-functional teams in an ultra-specialized environment is to show people how much it benefits them to become cross-functional team-mates.
If you don’t have time (you think) for reading anything intense, just pick up some Austin Kleon. Savor it slowly. Sip it. Like egg nog. Then tell people the compelling secret to the best homemade sausage anyone every made Tuscan soup with (metaphorically, of course).
Keener Strategy 