The Agile Executive

Making Agile Work

Archive for August 2009

The Agile Infrastructure cultural change problem – Agile Executive #06

leave a comment »


To listen to this podcast, download the podcast directly, subscribe to the blog/podcast feed in iTunes (or whatever), or click play below to hear it:

As part two in our (planned to be) three part or so series, Israel Gat, Andrew Shafer, and I get back together to discuss the idea of Agile Infrastructure. See part one for an overview of what “Agile Infrustructure” aims to be in the first place.This time, we talk about the difficulty of cultural change to make a more Agile IT process possible. We spend much time on “motherhood and apple-pie” topics as always happens when it comes to discussions of organizational change management, but drawing on our experiences in both small and very large companies, we start to pull apart the tactics for not only implementing a change to Agile IT, but coping with the friction that occurs during any change, esp. something as dramatic as changing to a more Agile way of delivering software and business services.

Here’s a feel for what’s in the episode:

  • I start out by asking how organizations start the process of changing to more Agile IT operations.
  • Andrew says that change starting at a grass roots level, bottom-up, and is far from wide-spread.
  • Israel speaks to one anecdote with 20% from the top and 80% from the bottom.
  • What’s the process for change? What’s the context for trying to get people to change?
  • Andrew says that people have to care – they must be interested in doing more than passing the time and getting paid for it, as I put it. Ideally, champions can start to “manage upwards” too, as needed. Also, having an expert on Agile available for internal assistance and answering questions is key.
  • Israel adds in his “Agile Executive” view. He speaks to using people’s desire to do better, but figuring out a window (or time and environment) in which it’ll succeed.
  • Using small successes to build the room to do large successes.
  • This discussion leads Andrew to remember a talk by Lisa Crispin where the testers and others began to understand the “business,” or the larger context they were operating in.
  • I ask Andrew and Israel why it’s important for IT employees to rise above being someone who “just works here.”
  • We then discuss how changing to the more role-fluid nature of Agile conflicts with the static nature of jobs in organizations, where people are assigned a specific role and aren’t expected to go outside that role.
  • When it comes to knowing how well you’re doing, Andrew introduces the Dunning-Kruger effect, wherein people are bad at evaluating themselves, esp. when their context is limited to their own group or organization.
  • Reflect and adapt… making sure you do this in Agile. Israel connects this back to building confidence and moral in the organization as a way to enable change and Agile. This relates to one of those group psychology studies that’s always fascinating, namely, people preferring confidence over expertise.

Written by Coté

August 6, 2009 at 10:02 am

A Note on “The Tool is the Method”

with one comment

The post The Tool is the Method generated a lively discussion. Whether you agree or disagree with the post, you are likely to find the experience reported by Rod McLaren in Jira, Greenhopper, Lighthouse: tools vs practice in Scrum of interest. Here is an excerpt from Rod’s post:

Our biggest problem with Jira/Greenhopper was that it isn’t as well-aligned to our developing practice of scrum as we needed it to be. The tool got in the way of our learning the practice, and started behaviourally skewing our view of scrum (‘The chosen tool becomes a factor of the first order in determining not “only” how Agile (or any other software method) will be practiced, but what mindset will evolve in the course of the rollout’). We were trying to fit scrum to the tool we had, and were talking more about how to use the tool well than we were about whether the sprint was going well.

I don’t know that the debate tool v. method could or should be resolved here. Absent resolution, the perspective on the subject Annie Shum expressed in Tools, Behavior, Culture is quite a good one to keep in mind:

In thinking about tools in the context of impacting large scale cultural changes, one can’t help but immediately think about the computer/digital computing.  By all definitions, a computer is a tool – in fact, I would venture to characterize a computer as a “universal tool” that can, in theory, perform almost any task.  Moreover, I can’t think of any other tool that can surpass the computer and digital computing as the most disruptive transformation agents of our society and cultural shifts in the 21st Century.

Written by israelgat

August 5, 2009 at 6:55 pm