“Bob,” Jake’s tone was almost plaintive. “You’re killing me here. I thought we had this all sorted out. Didn’t we just spend three days doing ideation work?”
Bob looked pained, he wasn’t happy and it showed. “We did and I thought we were sorted as well.” He gave a shrug, “Sales got wind of the requirements and threw a royal fit that we weren’t addressing performance on the OutDate hardware.”
“They do realize it’s a fifteen year old platform?”
Bob nodded, “And they insist it’s a must have to support ‘key’ customers.”
Jake grumbled, “fine, that explains that. What about this other stuff?”
Bob winced, “My boss isn’t happy with the strategy, he wants to alter course.”
I glanced over the new proposal. I made a note to talk to Bob about the concept of the word ‘alter.’ This plan was nearly a 180 from the previous one.
Jake threw his hands up in the air, “I give up. Every time I think we’re settled and I can start planning, the entire model changes again. Who the hell is in charge of the business plan?”
I could see Bob stiffen at that one. He didn’t respond, even though I could see he was rankled by the comment. I think he didn’t respond because he knew he really wasn’t in charge, even if his job description said that he was in charge. He had tried to put together a business plan and now, every time he turned around, someone was sticking a hand in and changing it.
“Sounds like you need to start the project before you start the project?”
“What is it this time, Hogarth,” I asked with no small amount of dread. Turning to face him I continued, “I’ve got Bob fully engaged with development, they’ve been meeting regularly. I’ve got an honest to goodness PO led product backlog for the first time ever.” I waved at the business plan on the screen, “and it’s all been tossed out the window. What’s the point? We are halfway through development and this is a huge shift in direction.”
Hogarth nodded, “Which is why you need a project before the project.”
I blinked, “Wait, what? That’s Big Design Up Front! We’re agile here!”
Hogarth gave me a huge, ivory filled yawn. “We covered this already, remember? Garbage in, Garbage out?”
I pointed a finger at Hogarth, “look here, I did that. Bob went through the whole process. We even brought in Jake and his team to look at some of the requirements. Our backlog was built on real requirements this time!”
Hogarth nodded, “And who else helped?”
Hogarth gave a long stretched before fixing me with his dark gaze again. “You wouldn’t design the features without the agile development team, why design the business plan without an agile business team.”
Blink, blink. Well dang…
A Product Owner is Not an Island
Experienced agilists will of course be saying “duh” right about now. Product owners are supposed to work with the team and collaborate towards a final product. This is good and effective, and the PO can still be an island if they do this. He just has seven other cast-aways, from his three hour cruise, on the island with him.
Beyond even the question of “how do you prioritize the business value of the backlog,” are questions like “what’s the business model,” “what’s the product concept,” and “where does the product owner get his requirements from in the first place?”
The product owner is not an island. He doesn’t sit in some ivory tower and imagine great ideas, which he then transports to the development team in a puff of smoke smelling faintly of brimstone. Our product owner, still called a product manager by many companies, instead is sometimes reduced to nearly the level of a scribe collecting all the inputs from other parties and trying to justify how to have the product be “fast”, “ultra-secure” and “cheep.” The product owner must work and take inputs from a wide variety of sources in an often dizzying array of inputs and conflicting priorities. When every organization is clamoring for their little slice of the feature pie, you can end up with a product that looks more like Frankenstein’s monster than Brad Pitt.
That’s just the way it is, you can’t expect that to change.
It can if you make a village.
In Garbage In, Gorilla Out I propose a new model for the early stage of a product. In what most lifecylces would call the Concept and Planning Phases I propose an iterative, agile driven, style that takes you from product ideation (vision) all the way to a well ordered backlog that the agile development teams can plan their iterations from. While I don’t speak to this in the GiGo blog, in essence, what I am espousing is an agile project where the finished product is a product or release backlog. So if GiGo is an agile project, where is the team?
In GiGo I briefly touch on the idea of the GiGo project team. It is not just the product owner that moves through the GiGo project. With her on the journey are representatives from her key stakeholders. This is not a fixed team and will vary from company to company. Ideally it won’t be more than seven, plus or minus two people which may require some team members to then go off and work with an SME team of their own. For example a representative from Technical Support might have their own Support GiGo team where they review and bring back final “product” to the primary GiGo team.
Who should be on the team? Other than the product owner, again it depends. Below is a list of common team members based on the most common roles to contribute to traditional requirements documents.
|Product Sponsor||Customer (or voice of the customer)|
|Related product managers||Technical Support|
|Agile coach or Facilitator||Sales|
While the product owner is the final decision maker, she is not the only person to have input into the creation process. When the PO works with a village, they prevent the customer, sponsor and team from getting PO’d at them.
Do you have your village?