Note: For new Gorilla Blogs, head over to The Gorilla Coach
"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," 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?"
"Huh?"
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
|
Technical Architect*
|
Marketing
|
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?
Joel Bancroft-Connors
The Gorilla Talker
Posts
