Bob's Blog
Bob is a prolific blogger who simply enjoys sharing his experiences with colleagues in the Agile Community. Topics revolve around Scrum, XP, Kanban, Project Management, Business Analysis, Testing, Leadership and General Musings.
Check back often as we've always got something to say...
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:
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.
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.
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.
What were the topics you might be asking? Scrum Product Ownership
I hope Josh understands...
Stay Agile my Friends!
Bob.
