Skip to main content

Agile Without Social Engineering

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!
http://www.pbpp.state.pa.us/portal/server.pt/community/human_resources/5364/how_to_apply/494613
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.
  • 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.
Coaching the team is going to consist of finding the points where the team members' self interest overlaps with the company's goals.  As a coach, you will provide some helpful scaffolding which can support employer and employees as they pursue shared goals following some modified processes.  Once they're used to the new techniques, you go away.  Here's my advice to you, and this is coming from a person who really does prefer to work with humans, not FTEs:

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 timeAsk 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

Popular posts from this blog

How Do You Vote Someone Off of Your Agile Team?

One of the conundrums of agile conversion is that although you are ordered by management to "self-organize," you don't get to pick your own team.  You may not have pictured it this way, but your agile team members are going to be the same people you worked with before, when you were all doing waterfall!   I know I wasn't picturing it that way for my first agile team, so I thought I should warn you.  (I thought I was going to get between six and eight original Agile Manifesto signers.  That didn't happen.). Why "warn" you (as opposed to "reassure" you, say)?  Because the agile process is going to reveal every wart, mole, quirk, goiter, and flatulence issue on the team within a few hours.  In the old days, you could all be eccentric or even unpleasant in your own cube, communicating only by document, wiki, email, and, in extreme situations, by phone.  Now you are suddenly forced to interact in real time, perhaps in person, with written messag

A Corporate Agile 10-point Checklist

I'm pretty sure my few remaining friends in the "small, collocated team agile" community are going to desert me after this, but I actually have a checklist of 10 things to think about if you're a product owner at a big company thinking of trying out some agile today.  Some of these might even apply to you if you're in a smaller place.  So at the risk of inciting an anti-checklist riot (I'm sorry, Pez!), I am putting this out there in case it is helpful to someone else. From http://www.yogawithjohn.com/tag/yoga-class/ Here's what you should think about: 1.        Your staffing pattern.  A full agile project requires that you have the full team engaged for the whole duration of the project at the right ratios.  So as you provision the project, check to see whether you can arrange this staffing pattern.  If not, you will encounter risks because of missing people.  Concretely it means that: a.        You need your user experience people (if a

Your Agile Transformation Needs to Start with a Quiet Phase

From a really great blog post on agile adoption:  http://smoovejazz.wordpress.com/2011/02/16/an-agile-approach-for-adopting-agile-practices/ I've observed some different agile transformation patterns, and maybe you have too: Just Do Standups   (Shoot, then Aim):   some people feel that since you're "agile," you should just start doing stuff, like daily standups, and then build more of the the plan as you go.  Find a team and start doing some agile with them!  Start a revolution one practice at a time, one team at a time. Pros:   you're very busy from the start. Cons:   what exactly are you doing and why? KPI-Driven Change (Aim, then Shoot) : some people who have worked in large corporations for a while will tell you that to get the respect of the people, you need to start with a plan, support the plan with awesome printed and online collateral.  Then you "kick off," tell teams what to do, and measure them using "Key Productivity Indica