I presented at a local professional group the other evening. I was discussing Acceptance Test-Driven Development (ATDD), but started the session with an overview of User Stories. From my perspective, the notion of User Stories was introduced with Extreme Programming as early as 2001. So they’ve been in use for 10+ years. Mike Cohn wrote his wonderful book, User Stories Applied in 2004. So again, we’re approaching 10 years of solid information on the User Story as an agile requirement artifact.
My assumption is that most folks nowadays understand User Stories, particularly in agile contexts. But what I found in my meeting is that folks are still struggling with the essence of a User Story. In fact, some of the questions and level of understandings shocked me. But then when I thought about it, most if not all of the misunderstanding surrounds using user stories, but treating them like traditional requirements. So that experienced inspired me to write this article.
In my last post I talked about a tendency some organizations (and individuals) have in jumping on the latest fad in building software teams and the methods for producing value. Beyond jumping on tactical or practice bandwagon’s, there appears to be a war going on related to traditional hierarchical organizational structures and traditional line or functional managers
Now to be clear, my context is 90% from an agile adoption and transformation perspective. And this isn’t some new phenomenon, as it’s been tied almost to the inception of the agile approaches.
I remember years ago, Microsoft was considered the benchmark of all things leading edge when it came to software development. They seemed to be the “poster child” for how to build software organizations and software products.
For example, they had a multi-tiered strategy for a code freeze model and everyone seemed to be copying it. And today their Software Developer in Test (SDET) model is also incredibly popular. There were many books written about their strategies and approaches, and everyone seemed to want to “be like Microsoft”.
What’s interesting to me is my perspective. If you’ve been in technology long enough, you see recursive themes unfolding. What today is a benchmark company with everyone jumping on the bandwagon to copy them, in ten years becomes a passing thought. Microsoft is clearly an example of this curve—first being the “darling” of what to do – to falling into a category of status quo or even an anti-pattern. Sure, Microsoft is still a viable company and sometime role model, but it’s no longer seen as the one to emulate.
My partner Josh Anderson and I just finished a Meta-Cast on the topic of self-directed teams. One of our listeners asked us to share our thoughts on handling agile team members who simply wanted to be “told what to do”.
On the surface, this doesn’t seem like such a bad thing. In fact, I’ll bet these folks are bright, capable and work very hard. They’re also probably “good people”. So if there is an issue with this in agile teams, what is it? And why would it be a problem?
I was working with a colleague the other day and we were talking about speakers for a possible local agile conference.
I brought up a few people that I respected in the national agile community and, almost to a person, they discounted them as being “the same old…same old” presenters. From their perspective, they were looking for more:
- Fresh meat or new blood
- Novel or breakthrough ideas
- Something “different”
- Out of the Box thinkers
- More modern and energetic
And I think I understood the point. We can certainly get repetitious in our industry. Following the same old pundits with the same old messages. But at the same time, something bothered me and for quite awhile…and I couldn’t put my finger on it.
Mike Cottmeyer is one of my favorite agile coaches and leaders within our community. When he worked for VersionOne years ago, I used to read his blogs fairly often. Now that he’s been out on his own with LeadingAgile, I don’t get the chance as often to experience his thoughts.
So I was pleased when I ran into a recent post by Mike that had the same title as this post. I read it with anticipation, and as with all of his writing, Mike made me stop and think a bit. Here’s a context snippet from Mike’s post:
I just registered for the Scaled Agile Framework, SAFe Program Consultant (SPC) class.
I’ll be taking the course April 22-25 in Boulder. One of the reasons I picked this class is that Dean Leffingwell, the creator and prime instigator of SAFe, is teaching it. Much as I did in 2004 when I took my CSM certification with Ken Schwaber, I want to get it “from the horses mouth” so to speak.
I’ve been sitting around far too long observing it from the sidelines or peripherally and feeling quite apprehensive about the implications that SAFe has across a variety of agile principles.
Another driver is that many of my coaching colleagues have taken this course and are recommending & leading SAFe initiatives. I respect them and their balanced judgment, so I want to approach the class with as few preconceptions as I can. I’ve long respected Dean for his work in RUP and software requirements, so I want to give it (and him) a fair shot.
I was talking to an experienced Scrum Master and Agile Coach the other day about agile in general and the topic of stand-ups came up. It seems he’d had an “experience” at one of our local agile group meetings where Daily Standup dynamics were being discussed.
Here’s a link to the session. It’s a meeting from our local Raleigh, NC AgileRTP group. The topic was entitled: Do You Stand Up? I missed the meeting, but he recounted the general discussion and flow for me.
The group consensus was that: 'Chickens' (interested bystanders, stakeholders, leadership folks, etc.) should not talk during the Daily Scrum. The rational mostly surrounded that at it would interrupt the teams conversations and flow.
The Scrum Master disagreed with this view and he (jokingly) said that—when he brought up his perspective, the crowd summarily dismissed him as being wrong.
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.
