I just watched a video by Mishkin Berteig where he clarified that the concept of a Sprint #0 is NOT part of Scrum.
A few weeks ago, a colleague of mine tweeted about the concept of Hardening Sprints. If you’re aware, the Scaled Agile Framework has “dabbled” with hardening sprints and other “extensions” to Scrum. Ron Jeffrey’s strongly, clearly, and repeatedly responded that hardening sprints are NOT part of Scrum. It became physically painful as Ron pounded his point over and over again in tweets.
I’m an insider (a CEC) to the Scrum Alliance CST & CEC discussion group. Some of the most heated discussions I’ve ever seen there revolved around the definition of Core Scrum in the Agile Atlas. This was before the Scrum Alliance centered on the Scrum Guide as the clear definition of Scrum.
I was watching an NHL game the other evening. The team was playing a hockey game without a goalie.
Apparently the team had decided that their goalie was too expensive. So they traded him away to another team.
Then the backup goalie was sick. And his equipment didn’t fit anyone on the team, so they decided to “go without”.
In a pre-game interview with the General Manager, he said that it was strictly a financial decision. They felt that the team could fill in the goalie role by sharing it amongst themselves.
If it worked out as he expected, then they might consider this change as a permanent part of their hockey team structure.
At the very end of the interview, he wondered –
What does a Goalie do anyway? For 90% of the game they’re idle. What a waste of money. Why not get the team to “pitch in” and fill that role? It just makes good sense…
A month or so ago I was invited to do a podcast with my good friend Cory Bryan. The podcast is Deliver It and I highly recommend listening into what Cory has to say. Cory said something during the podcast that has been running around my brain ever since. He said:
I sort of like it when leadership can’t make decisions. I’ll tell them if you can’t decide, then I’ll decide for you.
The implication was that he would drive all decision-making as the Product Owner – even decisions that senior leadership should be making. He was quite firm in his tone, seeming confident of his ability to step in and drive.
I was reading the latest newsletter by Gojko Adzic this morning. The title of the newsletter was – How to Reduce the Cost of Testing and the themes were mostly focused towards test automation.
It also bordered on that age-old argument that as you automate, you need less and less “testers”, so costs naturally are reduced.
We’ll, I woke up a bit grumpy this morning and I have a revelation to share. If you really want to reduce the cost of testing, then…
I’m often asked why I do what I do. It’s simple really.
In the late 1990’s I was an early adopter of Extreme Programming while working at Lucent. I was in a leadership role, leading software development and test teams, and it seemed to me to be an interesting way of effectively building software.
I had struggled with Waterfall approaches for years. I’d even worked hard at refining my estimation processes. But my projects were inevitably challenged and many failed to meet critical criteria. That is – projects that met all aspects of our stakeholder expectations.
When I stumbled on XP, it just…resonated with my experience. It also resonated with my leadership style and beliefs that PEOPLE were the central success proposition in software efforts.
Not: risk plans, test plans, project plans, management spreadsheets, cost accounting, estimates, system requirement specifications, metrics, status reports, etc.
Richard Khor is a young ScrumMaster who works with my buddy Josh Anderson over at Dude Solutions.
Josh has been there for a couple of years and is building some kick-butt agile teams leveraging the Spotify models. I’ve been doing a podcast called the Meta-cast with Josh for over 5 years and we’ve talked about everything we can think of around agile software development.
But enough about Josh and I.
In recent Meta-casts we’ve talked about Richard and the example he’s setting as a ScrumMaster. You see Richard is “becoming” a great ScrumMaster, not only by training, but also by his mindset, instincts, and actions. He’s also show initiative in the local agile community by leading a ScrumMaster Focus Group meeting for our local ALN chapter.
More than a year ago I wrote an article about how important “capacity management” was in agile teams. To be clearer the point was really…realistic capacity management.
At the time, I’d just come off a coaching roll where I’d encountered quite a few organizations that were pushing their teams too hard. Not slightly over their capacity, but two, three, four or more times their healthy capacity. And this created some distinct side effects:
- Employee satisfaction and morale was down and attrition was up. And they didn’t just loose their average people, they were losing their best people;
- Product quality was usually in a crisis mode and customer trust was continuously eroding;
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.
