Is a Pit-Crew Driving your Agile Racecar?

There’a backlash out there against Agile.

But the problem is NOT with Agile - most of what passes for Agile these days is a misappropriation of and misattribution to Agile whatever suits the need/greed – and abilities – of consultants who range from incompetent to dishonest.

The problem also lies with those who hire a Pit-Crew to Build or Drive your Racecar.

An overwhelming majority of Agile practitioners out there are consultants whose primary (or even only) skill/background is Project Management. Many of them are the same people from the waterfall world who have simply rebranded - not reinvented! - themselves and co-opted the term Agile to mean whatever they can get away with.

Everywhere I look I see companies hiring

  • Project Managers as Agile Consultants / Coaches – aka the Pit-Crew
  • with scant experience in Engineering or Product Management or Business Leadership
  • to tell their Engineers
  • how to build a state-of-art Engineering Pipeline – aka your Racecar; and
  • to tell their Product / Business Leaders – aka the Drivers
  • how to Create/Innovate valuable Products.

It's time to redirect the backlash where it belongs - towards those who have co-opted Agile and turned it into a certification and perpetual training & coaching machine that's harming software/product development teams, product innovation and organizational success.

Even the Agile Alliance's official position statement warns against it, albeit couched in subtleties. Agile Manifesto author and software industry luminary Martin Fowler denounced it in his post on Flaccid Scrum.

No one who ever puts his or her money on the line - aka bootstrapping entrepreneur - can ever fail to reap the rewards of Agile methods or have a fundamental problem with agility. I say this as a bootstrapping entrepreneur for a good part of the last 14 years, as an Agile Product Strategist for the last 10 years, and as the founder of an organization that enables bootstrapping entrepreneurs help each other through collaboration (including hiring each other through HaE.Ninja).

The problem has been people on the inside resisting threats to their entrenched positions and consultants on the outside cozying up to them to milk the corporate cow.

The Agile Manifesto - and the Twelve Principles of Agile Software - have served as the foundation of my product development efforts at my own startup as well as successful communication and collaboration with other companies ranging in size from solo entrepreneurs and SMBs to large organizations.

Dave Thomas – one of the authors of the Agile Manifesto - would like to kill the term Agile. I would go farther and say this:

There is no such thing as Agile (or Lean or Scrum or Kanban) – just the right way of building software programs and products.

And it all starts with understanding the nature of software and setting free its magical power.

It's time to get the pit-crew out of the drivers seat and the racecar - and back into the pit. In other words, stop letting Agile project management aka Scrum consultants get away with murdering the morale of your engineering and product management teams.

It’s time to stop treating Product Management as “out of band” in Agile and put it back in charge of the Go-to-Market Strategy.

It’s time to empower Product Management & Engineering to define & drive the Agile Roadmap.

Kill the Backlog of User Stories

Most companies think that a key part of being Agile involves creating a Backlog of User Stories from their product vision & product strategy. Soon they end up with 100 user stories to manage! And then drown in the details and the tedium of writing even more granular acceptance criteria for the user stories. Then there’s the estimation, grooming, prioritization, ad nauseam.

So Product Managers end up choosing one of the two evils:

  1. minimize Strategy work and spend most of their time updating the dozens of User Stories in the "Backlog" with detailed acceptance criteria;
  2. disengage from the delivery process and declare that Product Management is "out-of-band" in the Agile development process.

The solution is mind-numbingly simple - at least for a good Product Manager, Entrepreneur or Product Executive:

Start with a Go-to-Market Strategy

Here's how:

Identify key business Milestones (plan on getting to them in about 3 to 6 months), figure out your strategic Plans (about a month each) to validate or invalidate your assumptions about user & customer acquisition/ engagement/ monetization, and focus on minimizing core development Activities by choosing one key Activity that targets a key User Role/Persona in each Strategic Plan that should result in a Release (no longer than a month).

Put another way:

Don't *create* a big product backlog of User Stories from Features in your product strategy - that's just feature creep in bite-sized chunks. Instead, separate your product strategy from go-to-market strategy, and derive a mere handful of user stories from each Activity in the current strategic plan.

You shouldn't have more Plans beyond the Milestone you're targeting; and no User Stories beyond those derived from the Key Activity (and maybe, 1 or 2 supporting Activities) you have in the current Plan.

A typical company I coach and even my own startups typically have about 3 Milestones considered, about 3 to 6 Plans per Milestone, and 1 Key Activity (broken into about 4 to 10 User Stories for the current Plan) for the Persona/User-Role under focus.

My entire "Backlog" consists of no more than 10 User Stories at any given time.

I submit that the primary source of the problem most Agile projects face today lies with the word: Backlog.

"Backlog" is a *project* manager's term - nothing wrong with that, that's their job. But project managers shouldn't even be influencing - let alone deciding - what needs to be done, they should be responsible for getting done that which has been decided by Product Management and their Go-to-Market Strategy.

Product Managers don't think about the "Backlog" - they think about all the strategies to engage their users/customers in Activities to realize their product & business goals.

Empower the Product Management in the Agile process by focusing on Strategic Activities instead of the abominable Backlog of User Stories, and you empower the whole team and the entire organization as a result. You will end up lowering the time & cost to achieve business goals, while simultaneously increasing the quality of the products by reducing the amount of "development" work that needs to be done.