In the last episode, we saw how Paul Butler was able to grow the people of St. Lucia into parrot stewards. In the video above, I address the question: “If you’re trying to bring agility to a software team, how might you grow your team into people who identify with an agile mindset, extreme programming mindset, or DevOps mindset?”
I think it is good to start with how the team members see themselves today. What do they take pride in? What do they value? How much do these values align with what is most valued in the agile manifesto, in extreme programming, or in DevOps?
Deliver Fast or Deliver the Right Thing?
If your team values delivering features fast, concepts like spending more time writing tests, limiting work in progress, and introducing slack might be difficult to introduce because these may appear at first to slow things down when in fact they speed things up.
If instead your team values delivering the right thing more than delivering as much as possible as fast as possible, they may be well on their way to an agile mindset.
Should You Reward Individuals or Groups?
If your team members value individual achievement over group achievement, it may be a challenge to introduce things like shared code ownership, pair programming, or mob programming. This can be particularly difficult when developers and testers are evaluated in ways that discourage collaboration such as by counting bugs closed and bugs opened, respectively. In such cases, it would be valuable to take a look at the company’s incentive structure and have some conversations with upper management.
Should You Reward Heroics?
If your team members treat long hours and other forms of heroics as badges of honor, it may be difficult to introduce things like sustainable pace and limited WIP. The company’s incentives are likely to blame for this. Don’t expect that reducing rewards for heroics will solve the problem overnight. There may still be a cultural component in which peers continue to be impressed by each other’s heroics.
Command and Control or Self-Organization?
If your team sees management as making all the decisions and sees themselves as simply acting on management’s decisions, it may be more difficult to introduce things like self-organization and self-management.
If your team sees themselves as consisting entirely of one type of specialist, say programmers, then it may be more difficult to introduce things like the concept of a cross-functional team.
Self-Examination
If your team does not see themselves as the kind of people that regularly perform self-examination and regularly track performance against improvement goals, it may be more difficult to introduce things like increased transparency and retrospectives.
Now that we have some examples of the identities your team members may be starting from, in future articles, we will examine some techniques for forging new identities: identities that embrace agile/XP/DevOps values and principles.
I would love to hear what you thought of the video and article, so feel free to comment below, on The K Guy Twitter, or on The K Guy Facebook fan page.