Bugs Happen!

A friend of a friend (who actually follows this blog, I believe) e-mailed me yesterday, asking if I had any advice on how to handle a situation that his Agile team kept running into. Apparently they'd had several instances in the recent past where high priority production bugs had come to the team in the middle of a (Scrum) Sprint. In each case, it was considered unacceptable that the defect resolution simply wait for the next Sprint, and so they had tried a couple of different approaches to address the urgency of the situation:

1. Include the bug-fixing activity in with another feature in that Sprint that was somewhat related
2. Add the bug fix as a deliverable for the Sprint, with a higher priority than everything else

I was told that neither of those had worked all that well, either in terms of successful completion or from a morale point of view.

As I said in my e-mail response, both of those were reasonable ways with which to try to accommodate a difficult and frustrating scenario. However, I could easily imagine - even without knowing any of the people involved - how each might've gone awry. So instead I offered a different tack to consider next time, and it's the one that most Agile purists would likely always push for. But before I get to that, a few thoughts on the general topic of "bugs from the field."

Since I don't personally believe in "defect-free software" (having never produced, used or purchased any examples of such a mythical creature of legend second only to the unicorn), I go about my day under the strong assumption that there are always going to be problems found in production that weren't caught prior to getting there. Of those, some will be of a truly urgent nature that need immediate attention, and many won't be (but may still be initially prioritized as if they were); most almost certainly could have been detected and corrected before getting out the door had enough time and energy been expended in the search for them, and a few probably couldn't have been. In other words, they come in all shapes and sizes, but regardless: they come when they come! So, for me, the important question to be asked of any bug when it arrives back at our doorstep is, "What can we do better in the future to make production defects less likely." And if you're getting a significant enough quantity of showstopper bugs following release, then clearly you're not asking or (more importantly) answering that question adequately. Some serious and ongoing "inspect and adapt" discussions and tasks need to be happening if "stop the presses!" types of live bugs are more than an occasional occurrence for you and your team. That's one particular problem, and it's discreet from the one that was being posed of me.

What I was being asked was what to do in the short term, potentially high-pressure situation of dealing with the here-and-now of a bug's arrival and its effect on the current Iteration or Sprint. And, of course, the by-the-book answer is that you either cancel the Sprint and plan a new one to include the bug fix, or (somewhat less drastically) get the Product Owner to remove something from the Sprint in order to make room for the bug fix. I prefer the second approach because I'm not a big fan of bringing everything to a halt simply to accommodate something new. It may be that the bug in question is going to suck up so many of the resources for so long that you'll determine, while sizing it, that you're going to have to effectively cancel everything else anyway, but I'd prefer that an outcome like that simply remain an option, rather than the default response. In either case, though, you're taking actions that clearly send the message that fixing this bug is "not nothing." And that's critical because, among other things, it can sometimes result in the bug fix suddenly not being deemed as important as it had been when it had no price tag associated with it. It's like the free coffee and pop at my last workplace, which a few misguided souls there tended to treat rather disrespectfully (open can, take sip, leave remainder there for cleaning staff to deal with). When something's thought to be "free" that isn't really, it often gets some poor assumptions made about it.

Now, one argument against what I've just written that sometimes gets made goes like this: "Since the team didn't find the bug in the first place (but should have), then it's up to them to figure out how to fix it without jeopardizing everything else that they've committed to in the Iteration/Sprint." Honk if you've ever heard that one before! (Honk! Honk! Honk! Honk!)

There are a number of reasons why that's a silly stance to take, and I couldn't possibly think of them all in one sitting. But among the most obvious problems with it are:

• it encourages teams to fix things in the most slap-dash manner possible, since every minute they spend on the resolution is taking time away from what they were actually expecting (and expected) to work on
• it drives home the belief that the team is going to be penalized for every mistake they make, thereby making experimentation less likely (which is appropriate if you're programming a system for the Shuttle or a pacemaker, but in most cases...?)
• it flies fully in the face of the reality that even software organizations with tens of thousands of employees ship code with bugs

So for those reasons and others, it's unreasonable to expect development teams to "suck it up" and absorb critical bug fixes without removing any other work (unless the team decides, of course, that it's a small enough effort and can be added in with no impact).

Getting back to the question of "how often does this happen?", I think that what I've outlined above works fine as long as the scenario we're talking about is the exception, and not the norm. However, if it's happening on a more frequent basis, then in addition to figuring out why (and doing something about it that should reduce the occurrences in the longer term) you may need to set aside a small percentage of the team's velocity every Iteration for critical bug fixes. As I said in my e-mail response, you really want to make sure that any time that's allocated for that use be limited to actually dealing with high priority bugs, or bringing work in (off the product backlog, in priority order) if no urgent defects come along by, say, the midway mark of the Iteration. It definitely should not become a "slush fund" that can be used to soften the blow related to under-estimating, get work in on pet projects or simply to provide a cushion for the team. (You may, of course, want to allow some Slack Time for the team to dream up process improvements or new tools, but that's a different discussion.) If you can do it right, the team will regard that extra time correctly, and no one outside the team will have any reason to resent it or try to eliminate it, because they'll see the value of it, either in terms of showstopper bugs being fixed quickly or additional features being delivered.

Of course, it's easy for me to offer advice when I'm not in the middle of the fray, but that's just the way the ball bounces at the moment. Maybe someday I'll be back in there, swinging for the fences...

It's All Relative

A friend of mine was recently describing his workplace to me, and I couldn't help but evaluate it (in my head) as if it were supposed to be an Agile environment (which it isn't). I realize that that's a bit of a strange reaction to have, but it happened nonetheless.

So here's a thumbnail sketch of what I envisioned as I heard more about the office in question:

1. Leadership style - From what I could tell, it sounded like a very Command & Control setup, although I was interpreting from just one person's comments. The managers keep a very tight grip on all of the decision-making, to the degree that the expression "micro management" kept coming to mind as he related some of the day-to-day occurrences. In his view, this level of hands-on guidance was completely normal and expected from management, but I marveled at how unaccustomed to that style I'd become in recent years.
2. Trust - People in the office are all on fairly short leashes in terms of working hours, as one example of where trust is lacking. Even back in my pre-Agile days as a manager, I think I established a fairly easy-going attitude when it came to things like people needing to shift their hours around or take time off for personal stuff. Therefore it was quite eye-opening to hear about a white collar shop, in 2009, that still operates under very rigid rules in that regard. When I asked about it, I was told that "someone in the past had abused [flex time], and so now they don't allow that sort of thing." Rather than simply penalizing the person in question and extending trust to the rest, I guess the decision was made not to trust anyone with that kind of latitude.
3. Transparency - The funniest example I heard involved some data that was being gathered about productivity within the group. At first I was excited to hear that metrics were being used, but then it turned out that the information wasn't going to be shared with the "rank and file" because of fears that they'd adjust their behaviour (in the wrong direction) if they saw the data! That was just mind-blowing to me, but it probably shouldn't have been. After all, transparency is certainly not the norm, no matter how much we might want it to be.
   
4. Empowerment - Because it's always been a favourite topic of mine, I tried to ask the sort of questions that would give me some sense of how empowered employees were at this company. The impression I got was that some of the leaders play what I like to refer to as "the false empowerment game", which goes as follows: I tell you to do something but I don't tell you how or give you many details. When you proceed to do what you think I wanted done, then I look at the results and say, "That's not right. I want it to be more like this." After a few more iterations like that, we finally end up with the correct product. (So, in one sense at least, they're doing iterative development!) The problem with that approach is that it wastes a lot of time and teaches the staff not to make decisions.

Now, as I say: this isn't an Agile office that I was hearing about, so there's no reason why they should be expected to live up to Agile principles. And yet I couldn't help but wonder just how much better they might be doing if it were, and they were.

The Latest Lecture

Today I did my third iteration of the "Introduction to Agile" university lecture for second year Computer Science students. The class size was around 30 this morning (out of a possible 38), which was bigger than it's been in the past. I'd love to chalk that growth up to the AgileMan reputation spreading across campus and bringing them in from far and wide, but I think it's actually just a larger enrollment this time around.

Since my material tends to be the same each semester, what distinguishes the different sessions are the questions posed by each group. Today, one student asked whether Agile only worked for smaller companies, as it seemed to him that it wouldn't scale well. I explained that it had been fairly common for people to assume Agile wouldn't work in larger companies, but that books had then started to appear that provided insight and guidance on how to scale the practices without losing the principles. Because time was limited, I didn't go into any of the examples, such as the Scrum of Scrums (or even Scrum of Scrum of Scrums) concept to facilitate communication between teams, or Communities of Practice to share learning and discoveries. But I thought it was a good question and showed that the young man asking it had been thinking about what he'd been hearing.

Another question was, "With Agile, do you see more instances of burn out?" As soon as this was raised, I realized that nowhere in my slides do I mention the concept of "sustainable pace." I'll have to correct that for future lectures, but in the meantime I explained what's meant by that term. Then I described how you have to reinforce that principle, in both words and actions, and that failure to do so can quickly lead you down the path to an endless series of death marches.

I was also asked what tools are available to use if you decide to go Agile (I rattled off a few, and mentioned that since Nature abhors a vacuum, there were new ones showing up on the market all the time) and what sort of projects would be better suited for Waterfall (a question I've gotten before, and to which I always offer up "heavily-contractual, government and/or highly-specified work where the customer doesn't typically change their mind midstream").

As happened with the third year, 3-hour lecture last November, this one ran out of time before we'd exhausted all of the questions. That's always a much better feeling than what's occurred with previous incarnations of this second year course: few or no questions and a palpable sense of relief from the attendees that it's over! I'm not sure what to attribute the difference to this time around, but it just seemed to flow better all around.

What Can We Learn From Video Games?

When looking for insights into how we can all work together more effectively, there are worse places you could go than into the online environment of video games.

The sorts of games that I play, at least, have many of the same attributes that we value in the best workplaces:

• a focus on teamwork makes a difference - many squad-based setups only reward the individual players with experience points and movement up the ranks if they work together toward team-oriented goals; lone wolf tactics in team games are generally unsuccessful, and sometimes even penalized
• adaptability is a must - while a select few may be naturally gifted at the art of gaming - or software creation! - most of us discover quite quickly that we can only achieve respectable results if we adapt to each new environment; adopting an attitude of "that's just the way I am!" rarely works very well in online competition, just as it's severely limiting in Life
• clear goals can work wonders - there are few things quite as frustrating as not understanding what you're trying to achieve, and video games are becoming increasingly aware of that fact; you may be informed of your objective(s) in any number of ways (icons on a map, voice-over instructions, or even a small on-screen display of the current score) but the point is to keep everyone's eyes on the prize... which is equally sage advice for the workplace, as well!
• metrics and other forms of feedback are powerful - just as important as having goals is the understanding that reporting results will affect how people behave; one of the ways video game companies capitalize on this is by providing lots of statistics to their players; if you know that you're doing especially well with one type of weapon, for example, that may inspire you to use it even more and try to rise to the very top of the leader boards in that category; conversely, you might decide to direct your energy toward an area where you've discovered that you're below average, now that you have that data in front of you; in all cases, having more information empowers people in ways that ignorance never will
• leadership always reveals itself - if you've ever played online and watched a really good player take over a game, making the entire team better through a combination of outstanding strategy and technique, only to later discover that you were following the masterful guidance of a 12 year old kid, then you know that leaders come in all shapes and sizes; those who can, lead; those who can't, need to learn how to follow... and video games often make that distinction readily apparent in ways that questionable promotions and titles at the office seek to obscure

While admittedly somewhat tongue-in-cheek, I still hope that this post will nevertheless make all of us consider just what might be gleaned from even the most unlikely of sources... including video games!