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
 

Popular posts from this blog

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.

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 applicable) and your analysts at the beginning of the project, as always, b…

Requirements Traceability in Agile Software Development

One of the grim proving grounds for the would-be agile business analyst (henceforth "WBABA")  is the "traceability conversation."  Eventually, you will have to have one.  You may have seen one already.  If you haven't, you may want to half-avert your eyes as you read further.  It gets a little brutal.  But if you close them all the way, you can't read.
Dialogue:
WBABA:   ...so in summary, we complete analysis on each story card, and then we support the developers as they build it that same iteration!Corporate Standards Guy:  but how do you do traceability in agile?  You have to have traceability.  It's broadly recognized as an important factor in building rigorous software systems. These software systems permeate our society and we must entrust them with lives of everyday people on a daily basis. [The last two sentences are an actual quotation from the Center of Excellence for Software Traceability website!] WBABA: [cowed silence]Corporate Standards …

The Agile Business Case

Many agile teams have never seen a business case, ever, and they may even be proud of it.

Our mantra is that we deliver "business value," not just "software," quicker, better, and faster, but if so, we certainly don't spend a lot of time reporting on value delivery, and in fact we may be scornful about "analysis paralysis."  As software developers, we consider ourselves to be doing quite well if we can deliver the software every two weeks (or continuously).  And this is particularly if we've enabled this frequent high-quality delivery through automated testing and automated build-and-release techniques.  We've reduced business risk by making results visible more often, and allowing the business to change direction more frequently.  We assert that along the way of course we're also delivering value.  But how would we prove it?

I've recently posited that we shouldn't even think of doing agile projects without capturing and recording s…