The other evening I attended a presentation on agile metrics by Larry Maccherone of Rally Software. It was a great presentation. But he said something along the way that has been bothering me since. Let me try to get you in the right place by setting the stage a bit.
He started off by saying the agile metrics in general are “Context Based”. That is, your business space, problem domain, company maturity, technology stack, size and maturity of your team, etc; ALL come into play when determining your metrics. I guess this implies a one-size-fits-all approach doesn’t work and, in fact, that there is a unique size per agile context.
He had me at hello with this one.
It happens to me on a weekly basis. I’m teaching a class on how to write User Stories. Usually it’s part of my Product Owner workshop. We’re happily writing stories for an iPad application simulation. Typically halfway thru the exercise someone raises their hand because they’re struggling with the format of a purely technical story. Quite often they don’t know how to frame the “user” clause and are stuck there in their writing.
My first recommendation is often to tell them to skip it. I tell them that the “As a” and the “So that” clauses are usually quite different for technically related stories. I just ask them to quantify the need (technically), in clear English with perhaps a couple of sentences, and then move on.
Last week I had the privilege of doing some training at a company that had previously been following waterfall and more traditional approaches. Call it a jump-start, the idea was to do a minimal amount of training, help them get a backlog together, and then start “sprinting” as soon as possible.
I do this fairly often, but this group caused me to reflect a bit. Here are some thoughts…
I hear this challenge over and over again from Product Owners. They have little to no problem writing functional User Stories, but then…
Bob, the team is placing tremendous pressure on me to write technology centric User Stories. For example, stories focused on refactoring, or architectural evolution, or even bug fixing. While I’d love to do it, every time I give them to the team and we discuss them, they nit-pick the contents and simply push back saying they can’t even estimate them in their current state.
So I’m stuck in a vicious cycle of rinse & repeat until the team gets frustrated and pulls an ill-defined story into a sprint. And this normally “blows up” the sprint. What can I do?
I think the primary root cause of this problem is that the company views the Product Owner role as the final arbiter of user stories; meaning they need to write them all. I feel that’s an anti-pattern myself, but the question remains, what to do in this situation.
I’ve seen several clients apply approaches that significantly helped in handling, what I refer to here, as technical user stories. Let me share a couple of real-world stories (nor user stories mind you ;-) that should help you envision some alternatives.
I can’t recall when I first came upon the Pareto Principle.
I think it might have been when I was studying for my Six Sigma Green Belt. But
I’m unsure. I know I was operating as a QA Director at the time, because most
of my example uses for it surrounded testing and defects. Nonetheless, it’s
probably been over 15 years.
That being said, I don’t think I hear people “considering”
Pareto enough in their day-to-day activity, so I thought I’d bring it up and
remind everyone of the Pareto Principle or 80:20 Rule and it’s implications for
software engineering in general and agile teams in particular.
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 ;-)
