The Clever PM

Tips, tricks, and hacks that help you to be a better, more clever, Product Manager.

Breaking Down the Agile Manifesto — Processes & Documentation

by

One of the issues that Product Managers commonly face when engaging with teams who claim to be, or who want to be, “Agile” is that most people have never really take the time to actually research the origins of the Agile movement, the principles upon which it is based, or even the histories of the specific practices that have grown from these principles.  All too often, teams and companies begin their way down a transition to Agile practices as blindly as a bat fluttering out of its cave into the sunlight.

The fact is, there is a long and storied history to be found, and one of the best places to start is by reviewing the Agile Manifesto, which in many ways was the first coordinated effort to coalesce a variety of different approaches under a single set of guiding principles.  After a few online conversations, I thought it might be useful to present a few common misinterpretations of the Agile principles and explain why they’re incorrect.  To start with today, I’m going to dig on on the first two statements in the Agile Manifesto:

  • Individuals and Interactions over Processes and Tools
  • Working Software over Comprehensive Documentation

[Read more…]

“Agile” Does Not Mean “Without a Plan”

by

A very common, and very dangerous misconception about Agile development — whether you’re using Kanban, Scrum, XP, DevOps, or any other flavor of the week — is that it “requires” or “expects” that you can operate quickly, efficiently, and effectively without necessarily having an overall strategic plan.

Bullshit.

There certainly are teams and companies who waste their valuable time and energy moving forward through iteration after iteration without following a long-term plan.  And some of these teams can be successful in delivering in-the-moment, valuable solutions to customer problems.  And these teams can sometimes continue to be successful at this for a short time, until they realize that an entire organization has grown up around the product, and there are impacts to this lack of planning that span multiple groups.

Agile does not mean you don’t have a plan.  It means that you have a plan that’s flexible enough to accommodate valuable and important shifts in the plan’s underlying assumptions. [Read more…]

The Role of a Product Manager in Scrum

by

One of the sometimes-confusing aspects of the Scrum approach to Agile development is how a Product Manager fits into the system.  It’s important to understand that Scrum was designed originally as set of development practices, and as such from the textbook perspective views everything through that lens.  The crux of the confusion comes primarily because Scrum has a role called a “Product Owner” which is intended to be the teams “contact point” with the outside world.  All too often it is just assumed that this is a role that melds entirely with that of a Product Manager, without critically assessing what that role really is, how it needs to be managed, and what other duties a Product Manager needs to engage in that aren’t comprehended by Scrum as a development practice.

[Read more…]

Why Your User Stories Suck

by

I find it ironic that one of the most fundamentally important aspects of Agile planning is so very often terribly implemented.  User Stories are the single most important thing that a Product Manager/Owner delivers to their development teams — they’re the foundation on which everything the team does is gauged; and all too often, quite frankly, they suck.

The impact of the vast suckitude of these user stories is far-ranging, and does not go unnoticed.  Bad user stories are one of the biggest causes of complaints on the part of development teams, the cause of endless friction and misunderstanding on the part of stakeholders, and ultimately result in missed deadlines, failed sprints, and Armageddon itself.  Okay, maybe not quite that last part, but it sometimes feels like it.

[Read more…]

Be careful what you put on your backlog…

by

We’ve all had the conversation…you’re working at your desk, just finished a call with a customer or prospect, and that random person comes around and taps you on the shoulder…

“Where’s my feature?”

“Huh?  What feature?”

“You know — the feature you talked about last week.”

“Oh, that one!  It’s on the backlog.”

“I know, so when is it coming out?”

“Well, it’s…on the backlog.”

“Yes, I know.  So I told our biggest customer they’d have it next month, that’s cool, right? It’s on the backlog, after all!”

“YOU DID WHAT!?!?”

…and so it goes, and you wind up randomizing the teams to deliver what’s been promised, tossing out a good chunk of strategic work that you’d planned on doing.

[Read more…]

What “Agile” Means to the Business

by

Agile development and its related methodologies and practices have long been viewed as something that “developers do” with no consideration given to the broader impacts of those processes on the organization as a whole.  This, incidentally, is also the primary cause of failures on the part of organizations who attempt to implement Agile practices — the belief that all that’s changing is how the developers create, test, and deploy their code, and everyone else in the company proceeds on with business as usual.

Unfortunately, such a belief is far from the truth — in reality, companies who change from a rigorous, planned product process to an Agile process have to face the fact that they have to change the way they do business from the ground up, if they expect to gain the benefits of those changes across the board.

[Read more…]

Dropbox: The Most MVP of All MVPs

by

It’s constantly surprising to me that people seem to have such widely different ideas of what the term “MVP” or “Minimally Viable Product” really means.  Perhaps it’s a result of the term becoming an industry buzzword, or perhaps it’s because it’s used in some very different contexts, but it always baffles me that people focus on the “minimal” part of the term and completely forget the “viable” and “product” side of things.  To me, you don’t have an MVP unless you meet all three criteria:

  • You have identified the minimum set of features necessary to engage your users and to solve their valuable problem;
  • You have identified a way to ensure that your solution is scalable enough, stable enough, and valuable enough that you can confirm your product hypothesis; and
  • You actually have something that you can sell, market, or test.

Whenever I think of what MVP means to me, I think of Dropbox, the cloud-based file-sharing system that pretty much encapsulates everything that an MVP should be.

[Read more…]