I used to think that there were basically three forms of agile transformation. They were and are:
- Bottom Up
- Top Down
- Middle Out
and I used to say the most effective strategy for a true transformation is…all three!
I still basically coach that as an effective strategy. But as time has passed, and I’ve gained more and more experience, I realize that there is a fourth option that intersects all of these.
It’s:
And it doesn’t apply to the organization at all. It applies to the individuals within the organization. Let me explain.
I once worked as a coach at a large financial firm that had been “going Agile” for quite awhile. They were one of the worlds largest firms, so the teams and the projects were often distributed.
They had invested in a relationship with a Ukrainian firm to outsource a significant part of their software. This had been going on for a while, so there was integration between internal and outsourced agile team members.
I was pulled in to help the outsourced teams with their understanding of agile practices. You see, even though they “said” they were agile, their behaviors were really suspect and more indicated cowboy and self-centered development.
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.
