I’m sorry but I need to vent. I’ve been encountering these
patterns a bit too often lately and I just need to get these thoughts off my
chest.
The patterns are these:
- Organizations and teams consider it the Product
Owners role/job to write every aspect (word) of every User Story. And,
if the stories aren’t “complete enough” the team kicks it back to the Product
Owner to do a better job.
- User Stories are too robust. I’m being kind
here. The Product Owner / Analyst writing the story writes a complete
requirement (pages, all information) before ever showing it to the team.
From my perspective, these are both agile requirement
anti-patterns, you shouldn’t be doing it this way, and I’ll try to explain why.
In both cases, I think it goes against some of the very core principles of the
agile methods. It’s not changing your Waterfall views and while, you’re saying you’re
agile on the outside, on the inside you’re still handling your requirements the
same old way.
A few weeks ago I saw an article on LinkedIn that Google had decided to drop its 20% time for its teams. If you’ve been living under a rock, this is one of the most referenced (and admired practices) at Google. In essence, every engineer was allowed to spend/invest 20% of their work time on project(s) that interested them. It was a creativity and innovation incubator of sorts. Teams would surround the “best ideas” and work on this with 20% time. As experiments would show merit, they might make it into the core products or leveraged as a new tool, technique, or method. And no, 20% time did not mean that employees worked 120% of the requisite time. It was an 80/20 split and not intended as a project schedule accelerator.
Now they’ve changed policies. Innovation is being focused more on specific teams working in labs, so more centralized. And 20% time is now jokingly referred to as 120% time as Google’s official policy hasn’t been to “remove it”, just to move it to discretionary—in each employees “spare time”. It’s too bad really, because this policy was truly inspirational to many companies.
My My, Hey Hey (Out Of The Blue)
My my, hey hey
Rock and roll is here to stay
It's better to burn out
Than to fade away
My my, hey hey.
--Neil Young
One of the core principles of agility is the notion of “sustainable
pace”. It originated in the Extreme Programming community. Initially, in v1 of
the XP book, it was defined or framed by the principle of a 40 hour work
week.
I vividly recall managers at the time railing (no ruby
intended) against the notion as a clear example that these agile maniacs were
out of touch with business reality, out of control, and looking for an easy
road at work. What could possibly be next—working from home?
In the second edition of XP, Kent Beck softened the message
a bit and dropped the (n) hours recommendation. Nonetheless and thankfully, the
notion of sustainable pace has remained as one of the core agile principles. Although
there does appear to be an increasing de-emphasis of it within today’s agile
teams.
This blog post, which will actually become a “series” as I
keep adding references to it, was inspired by Bhavani Rao. Bhavani is a Product
Manager who lives in my neighborhood. He’s trying to make the transition to
Agile Product Management (Ownership) and is finding it difficult to gain entry
without real world experience. So a catch-22 if you will.
The focus of this blog is to provide a lean (but robust) set
of references for “would be” Scrum Product Owners and “newbie” Product Owners
to help them in their journey. But don’t expect it to be easy or to only read a
few blog posts. The role of Product Owner is deep, broad, challenging and
downright intimidating. That is – if you want to be GREAT.
I hope you do and I hope this helps…
Bhavani – this one’s for you ;-)
One of my favorite movies of all time is A Few Good Men with
Jack Nicholson and Tom Cruise. I can picture that highly charged confrontation
at the end clearly in my mind. You know the one.
Tom Cruise says—I want
the Truth…
And Jack Nicholson
leans forward, with that classic look, and says—
You Can’t Handle the
Truth!
What a climax to the film. I get chills every time I watch
that scene.
I’ve been thinking more and more in my coaching about why
leaders and managers often wait too long to ask for agile coaching help. I
think it’s a general phenomenon in agile (and non-Agile) teams and
organizations, but for the purposes of this article, I want to focus upward—on
“them”.
I’ve been sharing about agile methods for over ten years at conferences and workshops. One of the top three questions I always receive from attendees is:
Does agile work with distributed teams?
And sometimes the question is phrased another way:
That notion of co-located teams is nice in theory Bob, but in the real life, we have team members all over the world. We need to cobble together teams based on our business needs from wherever they are. Does “agile” support that level of highly distributed teams?
I often smile at the repetitiveness of the question. It indicates clearly that enterprise level software development is often distributed. It also indicates that outsourcing is still alive and well. I’ll try to provide some answers to these questions by sharing two stories of distributed teams I have experienced.
If you've been listening to our Meta-casts lately, Josh and I have been talking about the role of the Product Owner quite a bit.
We've been discussing questions like:
- Do you need one?
- If you do, what is the 'profile' of an excellent Product Owner?
- What do they do all day?
- Etc.
We've then been talking about a view I have about the role and the four key areas that you need to cover in order to do the role justice. I talked about them in my Scrum Product Owner book:
- the role is part Product Management
- part Project Management
- part Leadership
- and finally, part Business Analyst
I wish I would have come up with the "quadrants" notion when I was working on the 2'nd edition of the book...but, I didn't. But now I AM talking about the nuances of the role from a quadrants perspective.
