Now that I think about it, a “rule” sounds a whole lot more formal than I intend it. Perhaps I should call it a guideline or a heuristic or a thinking tool?
Ah, I don’t know. Let’s get into it and make that determination afterwards.
The Rule
It’s simple really. It revolves around telling your teams what to do. That is providing your directives, strong opinions, and guidance when you’re interacting with your fledgling agile teams.
The premise is that for every 100 opportunities that you are confronted with in your organization to provide prescriptive advice to your teams, you get no more than 5 times to actually tell your teams what to do.
I teach quite a few teams about User Stories. Most struggle with the concept, at least initially. One of the key challenges for many is the notion that stories are iterative. That you visit and refine them often, instead of the “once and done” view that we have for traditional software requirements.
Part of that revisiting is reinforcing the collaborative nature of the stories. The nature that says they are “intentionally incomplete” in order to encourage conversations around the story. Remember the 3’C’s from Ron Jeffries: Card-Confirmation-Conversation, with conversation being the most important ‘C’?
I thought it might be helpful to go through a life-cycle example of how stories morph and change as they approach an execution-ready state. So here goes a somewhat contrived example—
Potential clients often approach me with an immediate request for coaching. Usually they’ve attended one of my classes or heard about me from a colleague. Literally 90% of my business comes from these two sources.
Now usually they’re in a hurry to get me in. Often they want me to “drop everything” and come in for emergency agile training / coaching within a few weeks. I have to explain to them that my pipeline is usually fully engaged 3-4 months in advance, particularly for longer engagements.
Quite often I’ll try to recommend a solid colleague, but they often have the same constraints as I do. So the client usually will schedule something and wait. Often that waiting interval will allow “things” to calm down and for us to better plan our engagement.
One of the core ideas or principles of agile teams is this notion of a self-directed, self-managed, and self-organized team.
In my experience, it’s one of the hardest things to “get right” in your coaching and team evolution efforts.
Often I see two extremes…either:
the teams use the self-organization, self-directed mantra as a means of having no accountability. It’s essentially the “inmates running the asylum” and they can choose to do whatever they wish, whenever they wish under the banner of – “don’t bother us…we’re being agile”.
Or the other extreme is that:
the management team says that they’re empowering their self-directed teams, but when you look at their behavior, they’re doing what they’ve always done…tell folks what to do.
Book References
Project Retrospectives - A Handbook for Team Reviews by Norm Kerth
Sort of the “Godfather” of the modern day, agile retrospective is Norm Kerth. I always try and mention norm and his work as a means of giving folks a sense of the pre-Agile legacy of retrospectives. Point being, it pre-dates agile approaches.
The other nice thing about Norm’s work is his notion of “safety” in retrospectives and his Prime Directive. I almost always reference the prime directive at one point or another with each of my clients and in my teaching. It epitomizes the “mindset” of a healthy retrospective.
I have a confession to make. I've been podcasting with my friend and colleague Josh Anderson on the Meta-Cast for over 5 years. And I've been loyal to it.
But recently I was invited to chat with two follow podcasters. So I cheated, just a bit, and had a great time chatting with these folks.
I thought I'd share links to those 'casts here, just in case you're interested in the conversations. I also recommend you pay attention to the two podcasts as they are well done and incredibly relevant.
- Deliver It podcast with Cory Bryan, we chatted about Product Ownership, imagine that?
- Mastering Business Analysis podcast with Dave Saboe, we again chat about Product Ownership. But this time with a twist towards Business Analysts.
What were the topics you might be asking? Scrum Product Ownership
I hope Josh understands...
Stay Agile my Friends!
Bob.
In a recent article on AgileConnection, Allan Kelly wrote the following about the timing of writing acceptance criteria (acceptance tests) for user stories:
The Right Time to Define
I am frequently asked, “When should we write the acceptance criteria?” Sometimes programmers resist giving an effort estimate for a story unless they can see the ACs—sometimes detailed ACs, at that. However, there is little point in POs (and testers) spending time on ACs until stories are about to be scheduled. After all, if ACs take hours to write and the story is not scheduled, their time is wasted.
Also, if ACs are added but then the story doesn’t get scheduled for a year, by that time the story and the ACs may have changed. Because old criteria are in place, it can be easy to overlook these potentially important changes.
I was talking to the CTO of a company heavily invested in “going Agile” the other day. He was incredibly frustrated.
It seemed they were pouring money into the execution / technology teams – moving from an investment of 9% of revenue to nearly 35% of revenue in R&D. From his perspective, they were hoping that agility would be a creative and productivity “force multiplier” in their space and they were doing everything they could to support it.
However, what he was seeing from his perspective was…nothing.
There’s a trend in the agile community of influencing folks away from saying no, instead saying: “Yes, And…” as a means of connecting various conflicting points together. I wanted to use the same mechanism for the title of this article, because I think we need to start looking at the basic Scrum certifications in a different way, perhaps the same way we view Peanut Butter AND Jelly. Let me try and explain.
I’ve seen an incredibly alarming trend over the last 1-2-3+ years in my coaching. It involves whoever is teaching Certified ScrumMaster classes; whether they be from the Scrum Alliance, Scrum.org, or elsewhere.
I encounter quite a few organizations and many teams in my travels. Almost universally they are adopting Scrum and have a few to many CSM’s around to guide the transition.
But I’m finding that the “Scrum” that is being fostered and guided in these organizations leaves a lot to be desired. Often:
I have a good friend and colleague who works in a rather large enterprise. Among others, she’s tasked with bringing “agile” into the organization and “transforming” their work. She’s largely leading the effort, so has a tremendous amount of responsibility for its success.
They’ve chosen Scrum for this effort.
They’ve engaged a rather large agile coaching firm to help them “go Agile”.
So far their strategy has been along the following lines:
- Hire full-time agile coaches
- Do a little training for “Leaders and Managers”, less than a ½ day, usually 60-90 minutes
- Spin-up Scrum teams (a little training), with Technical Leads as ScrumMasters and limited Product Owners (time and skill)
- Start sprinting
- Hire more agile coaches
- Spin up more Scrum teams…start sprinting
- Rinse & repeat…
To-date, there are more than 50+ newly minted Scrum teams who are dutifully sprinting away creating lots and lots of value.
