"What do you mean he said it's crap?!?" Jake's voice thundered. I'm pretty sure there was steam coming out of his ears . I could feel my own kettle on a rapid boil myself so Jack must have been at nuclear meltdown stage. I turned and cast a sympathetic eye down the table. Poor, Bob, our hapless product manager looked like he'd just been served up as the main course at a great white shark feeding frenzy.
I'll give him credit though, Bob didn't cower in the face of our rampaging development manager. I mean after all, it wasn't his fault, he was just the messenger. Bob nodded his head gravely, "he did. He went on to say it was lifeless, had no vision, was poorly put together and had no business being on the store shelf." Ouch… Fiat Armburger was the man. If he gave your product a pass, you could name your price with the channel. But if he panned you, might as well start selling the office furniture now.
Jake shook his head, a look of complete disbelief washing over him. I don't think I'd ever seen him look so defeated. "We executed perfectly. We even shipped three months early. Hell! We delivered everything you asked for in." His eyes turned back to Bob at the last words.
"I know, I know," said Bob. "What can I say, we missed the mark. We'll just have to try harder the next time."
I jumped to my feet. "Well now," I interjected, because if I didn't Jake was going to levitate across the room and kill Bob with his eyeballs alone. "We have a stack of bug reports here. Bad review or not, we've got to fix these issues before GA. After all, we still have to ship, the schedule is committed."
It worked, everyone calmed down and we got back to making the product ready to ship. I don't know about anyone else, but all I could really do is wonder whether anyone would even buy it.
Great, just what I needed. A failing product and now a gorilla who thinks he's a movie buff. Why me?
"Well cause it's your fault." Hogarth offered up.
I spun my chair to face my personal gorilla. He was lounging on the wall contemplating his naval (yes gorillas have belly buttons, Hogarth's was large enough to misplace loose change in). "How on earth is it my fault?"
Hogarth looked up, producing a quarter from his naval. "Well technically it's Bob's fault, but come on doesn't it get boring always blaming the product manager?"
"Hogarth, explain to me how this is my Bob's fault much less mine?" Though the idea of it being Bob's fault was certainly more appealing to me.
Hogarth smiled, "G.I.G.O."
"I… what… " I stammered. Then my mind realized what he meant. "Oh… my george…"
Garbage In, Garbage Out:
GIGO is a term that reaches back to the dawn of the commercial computer age. It's a fundamentally simple fact that states "computers will unquestioningly process the most nonsensical of input data ("garbage in") and produce nonsensical output ("garbage out")." The overall concept goes back even father to early "computer" inventor Charles Babbage (now seeing a resurgence in fame thanks to the Steam Punk phenomenon) .
It's hard to argue with the concept, in fact the software programmers I know wouldn't even try. To them it's like trying to say "Brick+Music=42". It just doesn't work. You have to use good inputs if you ever want to have good outputs.
So then, why the heck do we think the magic solution is in the development soup?
For the sake of this discussion, we're going to take a scrum team. This problem applies to any kind of development process, from BDUF to XP. I'm using scrum because let's face it, some of us have held it up as the golden ticket to solve all ills. So let's see what happens when the golden ticket uses lead to develop.
The official Scrum Guide is seventeen pages long. Of those seventeen pages, about one page is devoted to the concept of a Product Backlog. This page covers that the product backlog is the Product Owner's responsibility, that it is important, that higher stories have more details, that it should be rank ordered and that it should be regularly groomed.
You can groom a Canadian Hairless cat all you want, he's still not going to win any beauty contests. A scrum team needs a good product backlog (requirements) to work from. If they don't have a good backlog, then they can ship the project on time, on budget and it will still fail because it was a bad idea to start with. New Coke failed because there wasn't a need for it, everyone was happy with the old coke.
GIGO- If you don't take the time to figure out what you want, then you won't get it.
But, but that's not agile! You're saying I have to do big planning up front! See I knew agile was a crock.
Yeah, no…
You don't have to document the Library of Congress, before you start a project, but you need to make sure you at least understand what the customer wants and have an end vision in mind. You then have to make sure that when the developers are getting ready to start coding, they understand EXACTLY what is wanted for that functionality. You can absolutely be agile in your product planning process. In fact, you can just be agile in planning and I think you'll get a better project, even if development still builds in "waterfall."
The Gorilla Planning Outline:
I found much of my inspiration in Jim Highsmith's Agile Project Management: Creating Innovative Products. I heartily recommend the book for anyone involved in project planning or project management. Another good bit of inspiration came from Agile Learning Labs, a really great agile coaching and training shop in the San Francisco Bay Area. If I have stood farther, it is because I have stood on the shoulders of giants (Isaac Newton).
Note: This is an outline only. Within each stage I promote agile based exercises to get to the end goal.
The Cast:
Product Manager/Owner
Product Sponsor
Customer Voice/Representative
Architect*- Optional
Agile Coach/ Facilitator
*- An architect level technical person can provide valuable insight to this stage of the project. It is vital though to ensure this person(s) can separate business from technical constraints. An architect who is constantly focused on the how and how long will not add value to the process during this stage. The exception is in Stage 6, Estimate the Cost.
Stage 1: Defining the Product
Purpose: Create the “product box.”
Time Needed: Half Day
Description: Ensuring everyone thinks that blue is really blue is a fundamental starting point. If the product owner things you are building a Ford Pickup and the Sponsor is envisioning a Land Rover, you have a disconnect. This stage of product planning focuses on the overall corporate goals and customer “box” experience. The “box” experience is the level of experience you get when you pick a product up off the shelf and look it over. What compels the customer to buy? The core of these concepts comes from Jim Highsmiths’ chapter on Envisioning from Agile Project Management.
Stage 2: Layout the Product Story Outline
Goal: Create a timeline of the product's use and identify missing gaps.
Time Needed: Half day to full day.
Description: “How did we forget that feature?” has been a long asked question, typically so far into the development process as to require derailing the project to get the feature in. Story Mapping is a process that discovers the users, the end to end experience and then allows you to drive into the highest level of user stories but doing vertical break downs.
Stage 3: Create the Chapters (User Stories)
Goal: To create clear and concise descriptions of user experience with the product.
Time Needed: One week offline work, after Stage 2 and then half day.
Description: A poorly written user story can lead to the implementation of something that is technically perfect and a complete failure as it doesn’t meet the needs of the user, as envisioned by the product owner. A critical component of this stage is that even the highest level stories need a basic acceptance test to validate against.
Stage 4: Decompose the User Stories
Goal: Break large user stories down into iteration obtainable goals.
Time Needed: Half day (can be done with Stage 3 to save some time overall)
Description: One of the largest challenges in the creation of a backlog is to go just far enough with the details of a user’s experience and not to far that you’re creating a functional feature spec. Product Managers often struggle to not provide so much data that they are directing the engineers to a specific implementation – which can both stifle a creative new idea and can upset the engineers who feel they are being dictated to. Engineers who get too vague a story are faced with many challenges, not the least being “what exactly are we building,” “If I’d know that originally, I would have estimated this as a much bigger story,” and “This will take at least six weeks, I can’t do it in a four week sprint.”
By breaking user stories down to iteration manageable levels the team is able to better estimate value and cost (time to complete), removes confusions that can result in a feature that doesn’t match the vision of the product owner, allows for shorter iterations – which itself improves the overall development process by allowing more chances to apply the “inspect and adapt” philosophy of agile.
Stage 5: Value the User Stories
Goal: To create a relative ranking of all user stories on a project.
Time Needed: One to two hours
Description: P0, P1, P2 ultimately breaks down. Fifteen years ago I never even heard of P0 and you might actually see a P3 in a product. Today you see projects where everything is a P0 and engineering says it will take two years.
Doing force ranking, feature weighting and other traditional techniques rarely leads to the level of consensus required to create a final ranked list. The realistic question to ask teams, at this stage, is how often estimating against real world artifacts has worked. When was the last time a product forecast was accurate? Using agile values opens up the process to creating a system that creates agreement not conflict.
NOTE: This is one of the secret sauces of this process. In my next blog I document an excellent exercise for how to define business value for an entire release in just a couple of hours.
Stage 6: Estimate the Effort (Cost)
Goal: Rank the user stories in relative order of effort (cost to produce).
Time Needed: One to two hours
Description: Classic estimating of user stories. It needs to be done on even the grossest level stories for the product owner to be able to properly rank order the backlog. Otherwise a backlog can be skewed towards value, costs or even worse, gut judgment. Poker Planning and Delphi models have an inherent flaw of focusing on the story itself which leads to exact effort and not rank ordering estimates.
The Cast: This stage does not involve the product owner/stakeholder cast. Effort estimating is done by the engineers doing the actual work. It is important to not just have management at this stage but engineers doing the functional work.
Note: The developers should not have knowledge of the business value rating at this stage. They are just assessing the complexity of the future. If they know a particular feature is the absolute silver bullet, they may over or under estimate it.
Stage 7: Order the Requirements List
Goal: One backlog to rule them all.
Description: At this point the Product Owner has both a business value and a cost. These are both placed on the user stories. From here the product owner then uses their judgment and skill to create the product backlog. They weigh the value and cost of a story (feature) to create the backlog.
Note: In agile development, best practice is to groom the backlog once iteration with the product team. This is where cost can be reevaluated, better definitions of stories can be done and the product backlog reordered as a result.
Posts
