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 don’t know what it is lately, but I’m encountering way too many agile teams with challenging work environments. Ones where the dynamics the team are trying to deliver software in are, in a word, crazy. For example:
- Teams are knowingly committing to more work in each sprint than they have capacity for;
- Teams are knowingly committing to specific date targets without having clear velocity data and/or without doing a modicum of agile release planning;
- Teams are ignoring the reality of their environment in (interruptions, multi-tasking, fire-fighting, knowledge & skill level gaps, etc.) and are pretending it won’t happen;
- Teams have shared team members or team members with limited capacity, but they’re ignoring this in their commitments.
This would be like your home builder knowing that it’s going to take them 5 months to build your house because of their teams’ capacity constraints, the complexity of the home, and the seasonal weather constraints, BUT they commit to 2 months anyway.
My reaction to all of these is the same: Are you crazy? And more importantly, how is this approach working out for you?
My wife and I saw two movies over the holidays. One was The Hobbit: The Desolation of Smaug and the second was The Hunger Games: Catching Fire. Both were the second episodes in a three part series. I suspect both were shot at the same time as their concluding episodes as well.
No, this is not a movie review, although both of them were “reasonable” follow-ups to their opening episodes. But both also had a similarity—one that bugged both my wife and I very much.
Both of them left you (the audience, the customer) hanging at the end. And I’m not talking about a subtle ending that hinted at a future plot direction. I’m talking about an abrupt, no warning at all, CUT off of the movie in lieu of the next (and hopefully final) installment.
I want to share a story from a Galaxy Far, Far Away.
It’s been on my mind quite a bit of late, as I tell it in some of my agile classes. However, I’m unsure whether the students believe me or they glean the significance of the story. I usually share it to illustrate a key point around software requirements. I usually get LOTS of pushback in my classes surrounding the “goodness and need” for fully documented requirements in software projects.
And as I unfold the agile approach to requirements (user story based, conversational, acceptance-driven, intentionally incomplete, and did I say collaborative?) the class starts turning ashen-faced in disbelief. Particularly attendees who are Business Analysts, Project Managers, and Testers struggle with the essence of agile requirements.
So that being said, I thought I’d try telling it here by writing it down.
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.
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.
