Getting political with Agile Sadism

I was on my way home from a medical appointment the other day and for some unknown reason decided that I needed to have a little talk radio background noise. After tuning into the local NPR station I was all set to disengage my thinking brain from my ears when I heard the interviewee say "Without common pain there is no chance to achieve real change in an organization."

Cue cinematic double-take record scratching sound.

Did I really just hear that? On an NPR talking heads program?

After a little research I discovered that the talking head in question making this point was no less than Mike Leavitt - former Governor of Utah (amongs many other positions I didn't bother to go look up) and the point he was making was in his new book entitled "Finding Allies, Building Alliances".

For those of you worried about being bored to death by a book report, fear not. I have yet to pick up the book. You'll just have to get by with being bored to death by my thoughts on what I learned from that interview.

If you haven't looked at the title of the blog recently, this would be a good time to do so. Go ahead - I'll give you a minute.

Done? Great. As you'd imagine, the fact that pain is an effective tool in the political arena isn't a huge surprise. What was a surprise was the fact that he acknowledged it as such. What was even a bigger surprise is that he went on to describe a situation where his approach failed.

See why I was surprised? Hearing a politician (or at least a former one) acknowledge not only the fact that he's applied "Machiavellian" techniques to get things done but actually admit that he experienced failure was the true eye-opener for me.

Sounds a lot like a reflection session, doesn't it?

What he "learned" from his failure was that not all of the stakeholders in a particular situation felt a common pain. As a result that same stakeholder ended up derailing the effort because they were better off maintaining the status quo.

Of course we'd never see such a thing in the software development industry, would we?

It is always instructional to see how similar problems are solved in different contexts. As this was the first time I've heard of a formalized approach to solving difficult problems in the political world I wanted to see what could be applied to my industry. Fortunately I was able to find the "Too Long; Didn't Read" book summary to get the big picture:

1. A Common Pain—a shared problem that motivates different people/groups to work together in ways that could otherwise seem counterintuitive. 

Absolutely. Of course no virtuous person would ever consider actually manufacturing these common pains to get things done, right?

2. A Convener of Stature—a respected and influential presence who can bring people to the table and, when necessary, keep them there.

If I were translating these points into the software domain (which of course I am) I'd say that this is the equivalent to the concept of an Executive Sponsor

3. Representatives of Substance—collaborative participants must bring the right mix of experience and expertise for legitimacy and have the authority to make decisions.

This was a good reminder to me that the twin characteristics of recognized experience and decision making authority are key for all participants.

4. Committed Leaders—individuals who possess the skill, creativity, dedication and tenacity to move an alliance forward even when it hits the inevitable rough patches.

Since problems within the software domain tend to be smaller in scope to the challenges government groups face, I'd say that we'd see this be the same group as with point

5. A Clearly Defined Purpose—a driving idea that keeps people on task rather than being sidetracked by complexity, ambiguity and other distraction.

Definitely an important point for our industry considering how common it is for our teams to have split responsibilities.

6. A Formal Charter—established rules that help resolve differences and avoid stalemates. 

I've decided I don't know how I feel about this one yet. My initial reaction is that establishing rules is counter-productive to solving a problem quickly, but as I thought about it more I realized that the teams that I'd point to as not needing rules were actually operating under a self-generated set of rules learned from prior experiences.

7. The Northbound Train—an intuitive confidence that an alliance will get to its destination, achieve something of unique value, and that those who aren’t on board will be disadvantaged.

This was probably my most valuable takeaway from this list. When you think about it, it is nothing more than a "pain" generated by the problem solving process. But it is also a particularly wide-reaching pain that if properly applied can increase the "rejection rate" of the solution across the wider organization.

8. A Common Information Base—keeps everyone in the loop and avoids divisive secrets and opaqueness.

This is not exactly news for our software world (Information Radiators, Sunshine, etc), but it is a good reminder for me as I have a tendency to not put as much effort into these tools/process as they deserve.

So I'm sure at some point I'll pick up the book and read it. It's probably worth your time to do the same, especially if you are (as I am) a student of seeing similar problems solved in different environments.

Care and feeding of feedback loops

So, I have to brag just a bit. Frequent readers will recall that from time to time I post about the teams I am currently working with. For those of you suffering from "too long, didn't read" syndrome, I'll sum up the back story.

The mobile applications group I work with consists of 5 different development teams - one back end services team and four client platform teams (iOS x 2, Android, Mobile Web). Although each of these teams have some really top notch people on the team, they were challenged from the process perspective when I joined the group. 

Our Android team was the first to launch with a structured methodology based on Alistair Cockburn's "methodology tuning" technique. The team is in the final stages of their first release using their shiny new methodology and speaking personally, I really am quite proud of what the team has accomplished. 

One accomplishment in particular was interesting enough that it warranted a write-up here. As mentioned above, the team is in their final stages of delivering their first release of a shopping application for the UK based grocery store chain. As this was the first time a native mobile application was being released for the UK market by our group, the leadership team decided that formal usability testing was warranted. 

Interesting thing about performing usability testing for an application to be deployed in the UK, the usability testing took place in - you guessed it, the UK. With the exception of the Product Owner, the whole development team is based in the US. Ideally we would have sent the whole team over to observe the usability testing, but given the distance the team decided to send their UX Designer over to represent the group.

The choice was a good one. The UX Designer took copious notes of the usability testing, noting equally the things that users were pleased with and things that didn't work so well. These notes were then transferred to the team at the close of the first day of testing, who in turn immediately started poring through the notes.

Here's the good part. Once the team was through the UX Designer's notes, they decided that they were going to fix a number of issues immediately and have the updated application ready for users at the start of the second day of usability testing. And they delivered.

Note that I didn't say that the Product Owner requested the fixes, nor did the team responsible for usability testing. The decision to make the changes in time for the next day of testing was made entirely within the team. For those looking for some measure of team ownership of an application, you could do a lot worse than using this as a benchmark.

Day 2 of usability testing dawns, and a new tested version of the application has been delivered to the usability lab. Prior to the team working in formalized iterations it is questionable whether they would have felt confident to turn around a new release of the application within a single night. Thanks to several iterations of practice at delivering a working application to stakeholders (the team's definition of "done - done" at the end of an iteration) gave them the experience and confidence to crank out a new release in short order.

I know what you're thinking. "Wonderful, they can iterate and release quickly. Look how 'agile' they are. Whoopie.", right?

Well, yes. They are 'agile'. Right on the front page of the Agile Manifesto it says "Respond to change over following a plan". All of the iteration / release conventions the agile community holds dear is rooted in this principle.

But there's more to the story than that. Right below that "respond to change" line is "Customer collaboration over contract negotiation". What seems to be lost on most of our industry is the fact that the word "collaboration" means interact, not guess. Teams that interact directly with customers on a frequent basis are getting the single most important feedback there is - actual feedback from real customers using the application.

Because the team had improved their ability to deliver frequently, they put themselves in a position to take the best possible advantage of that critical feedback loop. Prior to this it was difficult (not impossible, but still difficult) for the US based development team to interact directly with intended customers in the UK. In interviewing the team after the fact it was clear to them the value of having that customer interaction thanks to one of the team being on the spot.

Without the team directly involving themselves in the usability testing they would have received the resulting reports in due course, but they would have missed out on the opportunity to close the that critical feedback loop with their customers. A feedback loop that was particularly difficult for the team to close prior to this usability testing event. 

I think that the best news of all is that I can't take any credit for the team taking advantage of user testing in the way they did. I didn't even know what their plan was until I heard about it after the fact from the team project manager, Michael Buckland. Michael is much more than the project manager for the team - he's also taken over agile coaching responsibilities for the team, and has done a great job in that role. So much so that I may even forgive him at some point for being such a Scrum fanatic. 

Picturing cultural change

In a significant departure from my typically over-verbose style, I'm doing a quick vignette today on an interaction I saw occur with one of the teams that I am currently working with on their transition to Agile. 

The backstory on this is that one of the persistent pains for this team is a disconnect with QA, so the team agreed to shift their working pattern (culture) to incorporate QA as a direct part of the team, with a much more prevalent role related to work in the current iteration. 

What the team knew was that this should give them much shorter feedback loops on if something needed to be fixed or not, and it should also greatly shorten the amount of time that the project would go dark in QA at the end of an iteration/release.

What teams experienced with multiple roles working together know about this closer collaboration is the fact that when you have close association with the work that a specific role is doing on a day to day basis, you learn about that role to the point where you naturally take on some of their work.

Rather than trying to communicate to the team every single advantage to having all of the roles working together closely, I kept the focus on the direct pain the team was trying to address. I knew that sooner or later the secondary effect of role "spreading" would happen, but not when.

The following picture is a screen shot of a conversation that took place between one of the UX designers on the project (Val G) and one of the developers on the project (Thomas H). I was impressed enough at how fast the team shifted their culture to realize this secondary benefit of close collaboration that I thought it warranted a blogging. 

Here's the conversation: