Roadmap » David Alfaro: Scrum Costa Rica

25th March 2009

No agile practices or processes are substitutes for a Roadmap or Vision

More and more I see Products/Start-ups failing to sell once they go out to the market. Here’s my take on their main reason of failure.

Problem: The Product Manager has an Idea for a Product and starts throwing User Stories to the Team. The Team consumes them using the discipline they have devised by themselves thought the Sprints. Because we are doing Agile and Usability Studies, everything just have to end up fine, right? So at the end of the engineering effort the website will progressively go from glugging some sales to enabling more servers to control the fire hose throwing sale requests. Reality? if your are managing your product as I just described your are playing at the jackpot. You will have chances to have a fire hose throwing sales, but those chances are the same as hitting the jackpot.

Listen! Synthesize!

A Product Manager has to have conviction of his/her vision and the understanding that detractors will try to take the Product down, I mean, we live in the human jungle, don’t we? However, such a conviction has to be tempered with Company’s Business Strategy, market trends, with Subject Matter Experts opinions, and, most important, with fact your Product is changing the world for better, that you are solving a real pain. So listening has to be the key factor when envisioning a Product. After you have listened to all the aforementioned stakeholders the following two hardest steps are ahead: 1) Synthesize all that input into something really remarkable, feasible to implement and affordable for customers. 2) Communicate that synthesis to stakeholders and team in order to go for it.

The Mirage of Bad Assumptions in Review Meetings and Usability Studies

A Review meeting becomes obsolete if you don’t have a Subject Matter Expert to evaluate the Sprint results. If you are doing software for kids, guess what, the final acceptance word is for the kids to give, not for you. When I say Acceptance Word, I mean: From a Product stand point, we got a increment, which is apart from the achievement the team has accomplished. If the team delivers what you asked for but displeased your final user, congratulate genuinely the team achievement and blame your inability of transmitting what the user needed to be solved. Although is vital to have team members skilled in the Product domain, I strongly recommend not to have a SME inside the team. Paying consulting hours to a external SME disconnect him/her from the fear of trying to please the Product Owner. The SME doesn’t have to fear telling the Product Manager “Your baby is ugly” or “Your baby is cute but the bodysuit that is wearing today is horrible”.

On the other hand, Usability Tests are tricky. First of all, Usability Studies are not a substitution of Marketing Studies. The latter are inputs for the former. Why? Because as Usability Test Facilitator will always be able to find users that fit a wrong characterization of your persona. The persona can easily represent a market segment that is not big enough to make your product profitable.

Let’s dot the i’s and cross the t’s

Scrum and popular Agile practices are good to deliver complex products on time assuring Product Owner satisfaction and fulfilling his/her vision. But Scrum and popular Agile practices don’t cover all the responsibilities of a Product Manager, even more, the Product Owner role is a subset of responsibilities of a Product Manager. The ScrumMaster needs to receive a vision from the Product Owner to transmit it to the team. The Product Manager articulates a continuously validated vision and Product Strategy and then articulate a continuously validated Product Backlog. Don’t forget build an Agile Release Plan with clear milestones.

People who looked at this item also looked at…

Related items

posted in Roadmap, Usability |

11th November 2007

Agile is about Reality not Fairy Tales

The Product Owner role is highly important within the Scrum Process. He is in charge in getting sure the team is delivering business value.

Building a Product Roadmap
Building a Product Roadmap is an art. I had had the chance to talk with Luke Hohmann, founder and CEO of enthiosys, about all forces you need to take into account when you set out on defining your product roadmap. Surely, you can find an excellent and comprehensive explanation of Luke’s insights in his amazing book “Beyond Software Architecture: Creating and Sustaining Winning Solutions“. Luke’s advice and guidance have been instrumental for me to successfully push towards a realistic planning state in my projects at Artinsoft.

Up to now, I just tell you how important is to establish a clear distinction between the system’s architecture and the business perspective of that. Combining the business value features, market forces, technological forces, and events (among other things that I will blog later) you are able to build a roadmap.

The roadmap will provide you deadlines and features in order to build an Agile Release Planning. The ScrumMaster training given by Stacia Broderick is a wonderful source of tools for an effective release planning.

Along with the team, the Product Owner is ready to organize the priorized features by Sprints . That is, in earlier sprints the team will deliver the highest business value!!

Product Owner’s Fairy Tale
Ideally, before starting development, the Product Owner has a clear idea of what is needed for the product to be profitable. He has clear idea of all the market behavior and since he is supported by an experienced marketing team, building a Roadmap is just one more step forward.

In this ideal world, he just sit down and write all the User Stories needed to accomplish that wonderful profitable product. With a brightly bunch of User Stories, he now can sort them by business value: from the highest to the lowest. Let’s make an Agile Release Planning and voila! just let the Scrum team bring potentially shippable increments.

Wake up!
The most powerful weapon of Scrum for software delivering is Adaptation in an uncertain environment. In most cases of the real world, the Product Owner just has some idea of what is needed to have a profitable product. Even more difficult: maybe the team doesn’t have a velocity yet because they have never worked together and don’t have a deep understanding of the possible platform. Does it mean we don’t need a Roadmap and Release Planning? Well, this when we need them the most!

I’s alive!
Roadmap and Release Planning are Adaptive! I don’t want to touch metaphysical areas, but in order for something to be adaptive, that something needs to be animated, for me: alive! The Product Owner needs something to start with. At least he would have a fuzzy idea of the product. At the beginning the product features, technology and marking architectures are vague. THAT’S FINE! Let’s do our best in defining the Roadmap and the Release Planning.

Product Owner, remember: be responsive!
For the product perspective, each Sprint will give you high quality software to play with and that will give a magnifying glass to discern what do you want. You will sharp your vision with every Sprint. Every Sprint will give the chance to be more concrete in the Roadmap and Release Planning. Don’t miss an opportunity to update them. Every time you update, do all the meritorious market research, try to be more concrete and definitive in deadlines. Deadlines are important as we don’t have infinite resources to be vague all the time.
For the team perspective, each Sprint will give you a solid idea of what is your velocity based on what was done in earlier Sprints. Team velocity is vital parameter to wisely update in the Release Planning.

That’s all folks so far. Keep on tuned!