In my agile coaching and training journey, I spend a lot of time discussing a wide variety of topics. But there are themes that form a “Top 10” of topics that everyone seems to be interested in.
One of those items is how to handle bugs. Questions like:
- Do you estimate bugs (planning poker - points)?
- Are bugs equivalent to stories?
- When do you “file a bug” while sprinting?
- Do you count bugs as part of your velocity?
- Can you deliver a story in a sprint with bugs still open?
come to the surface in my classes and at conferences with amazing frequency. I often smile inside in amazement at the level of interest focused towards “bugs”. But that being said, it is an important subject for agile teams and I thought I’d discuss my views towards handling bugs in the above contexts.
In my previous post I shared about experience I’ve had in “connecting” UX activity into Scrum development teams. I tried to explain a pattern of collaborative partnering over either embedded UX in the teams or independent UX outside of the teams.
I thought I’d share another story that illustrates an aspect of these ideas.
A Story
Not that long ago I was working with a client helping them understand and practice release-level planning across their Scrum teams. Some of the challenges they were having revolved around incorporating UX design work and cross-team dependencies in their projects.
Matt Kortering of Universal Mind, wrote a blog post about How UX Fits Within a SAFe Environment. Lately I’ve been thinking about and writing about the scaling models, so a part of this fits well with current themes.
But I don’t want you to get stuck on the SAFe bits here. I truly want this to be a generic blog post about handling UX concerns and x-team integration within any agile method or approach.
Here’s what Matt had to say towards the end of his post:
In order to successfully engage UX within SAFe, there are a few other things to remember…
There is an old, old movie called the Marathon Man with Dustin Hoffman. In it, there is a compelling scene where the evil doer continues to ask Hoffman – “Is it safe?” while giving him a free dental checkup.
You can watch the scene here, if you’re up to it: https://www.youtube.com/watch?v=kzw1_2b-I7A
There seems to be several things that are incredibly difficult for many folks to do.
You see it in general, but it’s particularly interesting in agile contexts. Agile Teams seem to rarely want to:
- Ask for help
- Or say, I don’t know
I’m wondering why?
In my classes I often liken an aspect of the ScrumMaster role to that of a sheepdog. That an important part of their role is protecting the team. Often the direction of this protection is assumed to be outward, for example, insulating the team from external interruptions.
In a recent newsletter (sent on September 22), Mike Cohn discussed this part of the role in more detail. He spoke to two areas of protection:
- From Management Dysfunction (external), and
- From Team Complacency (internal)
The thing that struck me in Mike’s post is the internal protection perspective, ie., protecting the team from “themselves”. It made me think about areas where a ScrumMaster can really help their teams in this area.
Let’s explore some specifics…
A few years ago I quantified the 4 Quadrants of the Product Owner role as a means of communicating the depth and breadth of the role.
My intention at the time was to provide guidance to agile teams about the level of difficulty in performing within the role. I also had the intent to provide enough nuance so that Product Owners would realize that they typically would need help. That even though Scrum emphasizes a singular Product Owner per team (backlog), that more than one person might be needed to help fill all of the requisite skills and daily chores.
As part of the 4 Quadrants, I bundled the activities of a Business Analyst under the Product Owner role. It doesn’t mean that the Product Owner needs to be a Business Analyst. It just means that they have to either (1) have these skills themselves, or (2) have access to these skills within their team in order to effectively perform their job.
If there were one topic that seems to dominate all others in agile software development, I’d say its estimation.
Every team seems to struggle with it and I’m always being asked for “silver bullet” solutions that might make it easier. And of course, there are none.
I do think there is some guidance I can provide that might help you to improve your estimation understanding, confidence, and results. Or at least that’s my intent. So let’s try…
2-Phased Estimation
The first thing I’d like to make clear is the nature of most agile estimation & planning approaches. I like to think of them as a 2-phased approach versus the 1-phase, plan everything down to the single molecule in advance approaches typically used in waterfall projects.
To be fair, I’ve been fairly critical of some aspects of the Scaled Agile Framework. And even though I’m a SPC, I still don’t blindly install SAFe in many of my clients. That being said, there are a majority of my clients who are using (or planning on using) SAFe, so I get exposed to it quite often.
While I personally struggle with the agileness of much of SAFe, in the spirit of fairness, I do think there are concepts in the framework that are healthy and useful. So let me share a few of those...
I was inspired for this article by the same titled blog post from Simon Nadav Cohen that you can find here: https://labs.spotify.com/2016/05/13/to-coach-or-not-to-coach/
In the article, Simon speaks to his experience of overusing the “coaching stance” in his agile coaching interactions and showing that more nuance is often required. I wanted to explore it even more from an additional context – that of leadership coaching. But let me start out here…
The 5 Why’s
Are you aware of the 5 Why’s tool? It’s a lean technique for getting to the root cause of a problem or challenge. You keep asking why, five times in fact, in order to “peel the onion” of a problem and get to the root.
I was reading an online HBR article the other day about leadership communication. Here’s the HBR article –
https://hbr.org/2016/03/two-thirds-of-managers-are-uncomfortable-communicating-with-employees
I thought this might be a nice way to RE-explore leadership communication challenges. And a new twist might be some ideas on HOW to improve it.
