In 2006, Ivor Jacobson famously summarized, "Most important, agile is about social engineering." And indeed one of the things that makes so many agilists so darned loveable is that we are, as a friend of mine put it yesterday, "the kind of people who want to create a work place where you can go and still be a human being." Not a "resource," not an "FTE," but a human! It's an inspiring dream!
But you know what? It's not a goal you can attack directly, even if you are, for some reason, under the impression that you're in charge. In fact, in my view, a lot of us are completely wrong about what the "lead" and "lag" measures are for a successful "agile" transformation of an organization.
"Lead" measures, you will recall, are the little things you can observe which reliably indicate that something bigger and better is about to follow. So for example, "open team communication" is a lead measure for agile, if you can measure it, whereas "85% of the company's teams are executing with scrum" is a lag measure. A good agile coach will seek a company offering good open team communication, happy to think that they will be able to easily build a large number of scrummers to start scrumming everywhere you look, and lots of colorful post-its.
But wait, really? What is the means, and what is the end? Are we insisting on a certain kind of culture so we can impose a specific set of processes? Does that even make sense? Is that what the Agile Founding Fathers meant when they said they valued "individuals and interactions" over "processes and tools"?
We pride ourselves on thinking that culture change is needed before we can cultivate agile. How many times have you heard, "I'm not going to get anywhere with these people. They're all command and control mainframe people" or "they have a team of 5 people in 4 time zones" or "they only want to change their requirements process, and not touch engineering," or...or...or. We sit in judgement and say "you know what, you people, you don't have a culture of trust and communication, so you're pretty much doomed. I don't see agile working here." Some of us turn down the work from these "losers" point blank, while others of us sneer silently to ourselves while we bite the bullet and we cash the paychecks.
We would be better off thinking that successful software delivery is the best breeding ground for culture change. Let's get down to brass tacks. In an economy where technical people can move fairly fluidly from one company to another, a software development team is not "Camelot." It is more like a giant polygamous marriage of convenience.
Go with a few classic delivery success metrics, and let culture take care of itself. Ironically, if you want to make a difference to people's lives, you should help them:
 |
| http://www.pbpp.state.pa.us/portal/server.pt/community/human_resources/5364/how_to_apply/494613 |
"Lead" measures, you will recall, are the little things you can observe which reliably indicate that something bigger and better is about to follow. So for example, "open team communication" is a lead measure for agile, if you can measure it, whereas "85% of the company's teams are executing with scrum" is a lag measure. A good agile coach will seek a company offering good open team communication, happy to think that they will be able to easily build a large number of scrummers to start scrumming everywhere you look, and lots of colorful post-its.
But wait, really? What is the means, and what is the end? Are we insisting on a certain kind of culture so we can impose a specific set of processes? Does that even make sense? Is that what the Agile Founding Fathers meant when they said they valued "individuals and interactions" over "processes and tools"?
We pride ourselves on thinking that culture change is needed before we can cultivate agile. How many times have you heard, "I'm not going to get anywhere with these people. They're all command and control mainframe people" or "they have a team of 5 people in 4 time zones" or "they only want to change their requirements process, and not touch engineering," or...or...or. We sit in judgement and say "you know what, you people, you don't have a culture of trust and communication, so you're pretty much doomed. I don't see agile working here." Some of us turn down the work from these "losers" point blank, while others of us sneer silently to ourselves while we bite the bullet and we cash the paychecks.
We would be better off thinking that successful software delivery is the best breeding ground for culture change. Let's get down to brass tacks. In an economy where technical people can move fairly fluidly from one company to another, a software development team is not "Camelot." It is more like a giant polygamous marriage of convenience.
- The company needs something done
- The team members want to contribute towards the companies goals and get stuff in return like money, experience, and recognition.
Go with a few classic delivery success metrics, and let culture take care of itself. Ironically, if you want to make a difference to people's lives, you should help them:
- Get some actual metrics on their current corporate and team performance using agreed upon objective measures. A shockingly small number of companies measure this stuff. What is your actual speed to market today? How are you measuring code quality? What is your total cost of ownership? Total cost of quality? What are your company's goals? What is your scorecard? Or even "how much do you measure, and how much do you reveal about the results?"
- Analyze what the pain points are and pull from your agile bag of tricks to suggest lowest effort/highest payoff techniques to try.
- Prove success by comparing "before" and "after" business metrics.
- Repeat. Plan build check act. Etc.
You need to be a very good reader of a culture to figure out what the appropriate fix is going to be for the problems you see. But it is seldom a good idea to share those observations with your subjects. Luckily, in general, a business case can be made for almost any "social engineering" you want to do, so there is no need to get all pious with your coach-ees.
Do you feel people should pick up the phone and just talk to each other, instead of sending passive aggressive little emails? Ask teams to do a pilot where they try discussing things in person on a non-intrusive schedule, and suggest they impose a 3-email limit on all exchanges, after which the participants call a meeting to discuss it in real time. Ask them to stop and consider the results as a group.
People don't even have to like each other to get better results from practices that agile has made customary. And, on the other hand, proximity, whether physical or virtual, creates a sense of team unity that cannot be gained any other way, particularly if the team is succeeding. (Or better yet, failing spectacularly and then succeeding due to your helpful process tips.)
In real life, most adults don't want to be lectured about how to get along with each other. Most adults prefer to know an actual corporate goal and be given the right tools to contribute towards the goal, along with appropriate reimbursement. People may even settle for inappropriate reimbursement so long as they choose the trade-off, and their immediate coworkers recognize their contribution.
As a coach, you have a very serious choice to make. Are you going to lecture people constantly about how they will behave when they are agile? Or are you going to help them achieve actual goals which contribute to the actual company mission, vision and values? And let them figure out how they want to get along. The choice is yours.
Do you feel people should pick up the phone and just talk to each other, instead of sending passive aggressive little emails? Ask teams to do a pilot where they try discussing things in person on a non-intrusive schedule, and suggest they impose a 3-email limit on all exchanges, after which the participants call a meeting to discuss it in real time. Ask them to stop and consider the results as a group.
People don't even have to like each other to get better results from practices that agile has made customary. And, on the other hand, proximity, whether physical or virtual, creates a sense of team unity that cannot be gained any other way, particularly if the team is succeeding. (Or better yet, failing spectacularly and then succeeding due to your helpful process tips.)
In real life, most adults don't want to be lectured about how to get along with each other. Most adults prefer to know an actual corporate goal and be given the right tools to contribute towards the goal, along with appropriate reimbursement. People may even settle for inappropriate reimbursement so long as they choose the trade-off, and their immediate coworkers recognize their contribution.
As a coach, you have a very serious choice to make. Are you going to lecture people constantly about how they will behave when they are agile? Or are you going to help them achieve actual goals which contribute to the actual company mission, vision and values? And let them figure out how they want to get along. The choice is yours.
 |
| http://commons.wikimedia.org/wiki/File:Richard_Burton_and_Julie_Andrews_Camelot.JPG |
Comments
Post a Comment