Last week, I was on the road. Not surprisingly, my flight was delayed and I was spending some quality time with other semi-stranded passengers. Just by chance, I ended up chatting with an engineer. He asked what I do for a living, and I explained how Pragmatic Marketing trains product managers and product marketing professionals. From his comment (“you mean they’re trainable?”), I could tell he was more than a little frustrated with his product management staff. Now, I’ve always been one who can’t resist beating the buzzing hive… so I dove right in and asked about his situation.

As we continued to talk, I couldn’t resist mentally dropping his situation into a bucket that I like to call “Acrimonious Agile.” This particular engineer said, “we’re using agile, but no one seems to know what that really means. Executives think it’s a way to get us to deliver faster and product management thinks it’s their ticket to change requirements as often as they want.” As a result, their current project was in major disarray—promised dates had been missed, and they still weren’t sure what the release would really contain… when (or if) it actually releases.

Acrimonious is an adjective that describes things “marked by strong resentment or cynicism.” Synonyms include bitter and resentful.

Acrimonious is a pretty accurate description of many companies’ experiences with agile methodologies. This approach basically gives in to rapidly changing requirements. In fact, I believe that Agile was created because engineers needed to figure out how to deal with constant and inconsistent changes from executives and product managers. These engineers are dealing with executives who can’t decide which is a top priority and product managers who are too busy thinking about requirements to actually visit the market and learn the real requirements.

Engineers are generally very intelligent individuals who are truly driven to succeed. Have you ever met an engineer who didn’t want their product to be successful? When they’re placed in a situation where requirements change frequently yet they’re still pressured to promise delivery dates, their chances of success plummet. And their frustration soars. One way they react is to acknowledge that the company can’t really give them long-term direction—so rather than trying to make their predictive headlights shine all the way into next year, they tighten their focus to the short term.

For engineering, agile seems to be the answer—their teams can stay focused on a very small set of requirements. They can basically ignore the executives and product managers… and any changes more than a few weeks down the road.

Ignoring changes might make sense, if we disregard the pressure for target delivery dates. However when we mix changing requirements with date pressure, it’s the perfect recipe for failure! As any mature adult knows, in any software project there are three variables: time, content, and resource. We might be able to lock in two but if we try to lock in all three, it is quality that suffers.

For instance, think about the engineer I had talked with. He said that his executives were promising dates (thus locking the “time” variable), and his product managers were continuing to change content (thus continuing to change the lock on content). Time is locked, content is locked. Therefore the quality is sure to suffer (makes you hope you’re not a customer of theirs, right?).

This is not a fun place to be!

I suggest that there is a better way to handle agile programming.

The product manager must research the target market, and provide development with a list of prioritized market problems.

At the beginning of a new release cycle, review the entire list of problems. Sit in a room with Product Management, Engineering, Product Test, Customer Support, Technical Publications, and whoever else is on your core team. Review the list of market problems. Take good notes, and post them somewhere that the team can easily find them.

After you’re on the same page with the list of problems, let Development begin their processes.

If you’re the engineer in this scenario—take the title for each market and put it in your open list (or “backlog”) along with the relative priority. Plan your first iteration. And then, here is the key:

Tell your product manager what you’re promising to deliver in the first iteration! Let them begin planning promotions around a set of features that you are confident in.

After each sprint, repeat this process—sit down with the product manager, and make sure they understand what’s going to be promised with this cycle.

It seems too simple too work… and that’s why it does. I have managed quite a few projects that worked like this. The beauty of it was that I just kept working the same way I had in the waterfall approach—I delivered a requirements doc at the beginning of the cycle, and reviewed it with the team. I answered questions from them during design, estimation, build, and test…..and I only planned promotions for a feature after they had assured me it would be in the release.

Actually I find there is little difference between being a product manager in waterfall and doing the same job with an agile team. Regardless of development method, product managers need to:

• Know your target market well enough to describe the players, their problems, and the urgency & pervasiveness of those problems.
• Assemble a list of market problems that clearly describes what you know, and includes the highest priority problems.
• Communicate with your team.
• Plan your promotions AFTER your development team has committed to features. Adjust the plan as you go, if you need to—but never over commit.
  

The relationship between the engineer and product manager doesn’t need to be different. The engineer must:

• Actively participate in the requirements review. Your responsibility is to ensure that you understand the vision and market problems for this release. You need to ask all your questions (even the tough ones), until you’re in alignment with the goals for this release.
• If you don’t trust the priorities of requirements, discuss it—you and your product manager need to be in alignment.
• Commit to whatever you can—if you start with top priorities, your product manager has a much better chance of launching the product successfully. This makes all of you look good.
• Communicate clearly to your product manager—they need to know what is going to be delivered and when….as soon as you know!
  

And, the number one thing that product managers and developers need to remember, to ensure that agile is not so acrimonious:

You can
Commit and deliver,
Or you can
Under-commit and over-deliver…
But if you
Over-commit and under-deliver, we all lose.

Stacey Weber is a consultant at Pragmatic Marketing. She has more than 7 years of experience in software product management. During that time, she developed a focused interest in the improvement of requirements gathering, analysis, and review. She has led efforts to increase market focus, improve roadmap planning, and increase the effectiveness of requirement reviews with development teams. Contact Stacey.