RSS

Tag Archives: human dynamics

Agile Adoption, Second Order Change, and Mindset

I’m currently rereading Change and trying to see if I can learn to apply some of the ideas.  At a very high level, the book makes the argument that there are two types of change.  The first type of changed is described by the common saying:

The more things change the more they stay the same.

And this is described as first order change.  The second type of change – second order change, has a more lasting effect.  If we are dreaming we are being chased, there is nothing we can do within the dream to escape the dream.  We must wake up – which is a completely different state of being.  Or if we are driving a car, the gas pedal can only take us so far.  To accelerate beyond the given boundaries we need to change gears.  Second order change is like waking up, or changing gears.

I hope you’re with me so far 🙂 Theoretically this makes sense.  And being in the agile transformation space, I can see most of the current agile adoptions suffering from the fact that they are only first order changes.  Therefore, little really changes in terms of end results.  However, in the few great successes – it  is like being in another world.  Things are different, and can’t be explained as a result of just the agile practices.

So, what does it mean to create second order change on a team or organization?  What does that mean in business?  What is second order change in software development?  How does this theory translate into something concrete?  An example from Change makes a good illustration:

One of the changes affected by the Red Guards during the early stages of the Chinese Cultural Revolution was the destruction of all public signs (of streets, shops, buildings, etc.) which contained any reference to the reactionary, “bourgeois” past, and their replacement by revolutionary names.  Could there be a more radical break with the past?  But in the wider context of Chinese culture this break is fully in keeping with that basic rule which Confucius called the rectification of names and which is based on the belief that from the “right” name the “right” reality should follow – rather than assuming, as we do in the West, that names reflect reality.  In effect, therefore, the renaming imposed by the Red Guards was of the first-order change type; it not only left an age-old feature of Chinese culture intact, but actually re-emphasized it.  Thus there was no second-order change involved, a fact that the Red Guards would probably have had difficulty appreciating.

That’s what I’m exploring.  I’ve  participated in several successful and failed agile adoptions.  I have observed  the keys of success were in the individual human dynamics and the culture created by leadership.  So it seems to me that the change of mindset of the individuals and the change of culture have created that second order change.

The change of mindset supported by culture creates second order change.

By changing our perceptions of the world, we “shift gears” or “wake up from the dream”.  Changing mindset, however, is a very intimate event.  It is the moment that the proverbial light bulb turns on.  And that lightbulb can easily flicker off if not followed by actions and feedback that feeds that initial spark (yes I’m mixing metaphors – sorry).  This is really cool!

But for me, as a change agent, it is still unclear.  I cannot consciously repeat it, even if I have unconsciously, by gut, done so over the past several years.  I know there is something here – and making it concrete help me and my clients, and help me communicate it to others and if I’m extremely lucky be a real contribution to our community.  I am increasingly sure that this way of seeing the world of change is a piece of the puzzle.

So here is my proposal: let’s all go back to the moment(s) where the light-bulb turned on and we drank the kool-aid.  Let’s describe those moments.  Here, on you personal blog, or an email to me.  I’ll create a catalog and we can look at them for patterns.  I will publish the results and make them available to all at regular intervals.

 
1 Comment

Posted by on July 22, 2013 in Culture, Individuals, Interactions

 

Tags: , , ,

Culture or Individuals First?

So, the lean world says that environment trumps all – and it does, but it is not sufficient.

Individuals.  “Individuals and their interactions over process and tools” says the Agile manifesto.  Yep, that too.  Useful in context, but also not sufficient to produce high performance.

Lately, I’ve been reviewing Tribal Leadership in preparation for Dave Logan’s talk later this month, and he talks about the tribal culture being all-important and that it is the determining factor for the level of success achieved per group.  But what comes first, the tribal culture “chicken” or the individual behavior “egg”?

In my experience it always comes with the individual.  That individual shows the types of behaviors we expect to find in high performance teams: ownership, respect for others, ability to build trust by making and keeping agreements, and the ability to create a safe space for others to collaborate with him.  That person somehow finds others of like minds, or infects those around him.  And once they reach critical mass, they start to set the norms and expectations of their group (team/department/organization depending on their reach and circles of influence).

So my answer (for today) is that individuals come first.  That’s my story, and I’m sticking to it.

 
Leave a comment

Posted by on April 3, 2013 in Individuals, Organizations, Teams

 

Tags: , , , ,

Interpersonal debt

If you are in the Agile community, you probably know what technical debt is: the accumulation of work to do when you choose to patch/band-aid/short-cut your design and coding to save time and effort now.  Technical debt accumulates with interest, every time you choose to take a short-cut you make it a little harder to read, understand, maintain, and modify your code.  Eventually, if untreated, technical debt can bring the progress of a team to a standstill.  What is the solution?  Do the right thing,  slow down to speed up, leave code a little better than you found it – always, and refactor mercilessly.  Otherwise, pay the consequences.

 

So, what is interpersonal debt?  It is the price we pay in our relationships when we don’t address issues right away.  We tell ourselves that we don’t want to hurt the other person, or right now is not the right time because he’s in the middle of something and this will affect his performance, or I don’t want to deal with the headache now – I’ve got more important things to do, and so on and so forth.  

 

So is this really a bad habit?  It is when this affects the nature of your relationship, if after a while you don’t trust, rely, and/or respect each other, and in my experience unresolved issues always lead to these problems. This is undermines the effectiveness of all collaboration and hence the effectiveness of your software development effort.  

 

So, does this mean we should bring up and make an issue of every single little thing?  Well, yes and no.  Yes we should resolve our issues quickly and not let them grow and fester.  And no, we probably shouldn’t be talking to our peers and colleagues about every single little thing they are doing wrong because it is not helpful and will create the exact problem we are trying to address.  So is this catch-22?  Is there no solution?

 

Obviously there is since there are teams and organizations out there who are extremely effective and having a blast doing their work.  What we have found at Gemba is the following:

 

  1. Self: start with yourself.  How did you cause this problem to happen?  How are you responsible for the issue that is bothering you?

  2. Clarity: when we come across an issue a problem, we are usually very clear about what we do not want.  Are we clear on what you want?  If not, get there first.

  3. Ask: Have you asked the person you have an issue with for what you now have clarity on?  I know that many times if I was not clear myself, then I have not communicated what I want to others.

  4. Agree:  Asking does not mean agreeing.  The next step is to get on the same page with the person.  Tell him what you want, and find an agreement that you can both buy into. 

  5. Confront: If you have done all of the above, then, and only then, can you take them to account if they fail to honor the agreement.  And even then, how you call someone on an issue is important.  

     

    For me personally, I’ve been learning every day about applying this to my personal and business lives.  The problem with not calling it is that it builds up resentment and detracts from our effectiveness.  I’m in the middle of doing a big interpersonal refactoring because I’ve done all the points above except the last and let issues build up because it was never the right time to call someone on an issue.

     

 
Leave a comment

Posted by on September 3, 2010 in Individuals, Interactions

 

Tags: ,

Gossip and self organizing teams

Gossip….  Boy!  What does that have to do with software development?  Well here’s the thing….  Gossip is the spread of words and ideas about a person that they would not appreciate; usually behind their back.  This action seriously impedes the ability of team members to work together effectively, and here’s why….

When I use my words and spread negative ideas about you, it may seem to me that I’m attacking you.  I may be doing that, but I’m also hurting myself and my ability to be effective in a team.  So, let’s say I think you are stupid and I talk about you behind your back.  What ends up happening is that you will eventually know.  You will hear it from someone else or my feelings will come out in conversation ,even if I don’t say the words.  There is a level of communication deeper than words.  And this ends up making you hate me for it.  And you hating me for it is not a good thing.  We won’t be able to work well together and we’ll be less inclined to solve the “in between” problems on our team.

Self organizing teams rely on everyone doing their part and also keeping an eye out for the “in between” issues that are no one person’s responsibility.  Gossip eats away at a team’s ability to do so effectively.

So where is the place for negative feedback?  That is a great question that has many parts.  I’m sure I’ll write about it soon.  But the short answer is : a) start with yourself before you criticize others, b) examine your agreements with others, have they been broken or do you need clearer agreements?, and c) once you do (a) and (b) then sincerely talk to the person either one-on-one or in appropriate group setting such as a retrospective.

Now I’ve got to go catch a plane and eat my own dog food; as I’ve been writing this I’ve noticed that I’ve been part of some gossip and I’m doing more harm than good.

 

 
Leave a comment

Posted by on April 27, 2010 in Individuals, Interactions

 

Tags: , ,

The importance of sincerity in software development

Being sincere is something that I learned as a child to be a good thing, just like telling the truth, and sharing with others.  Somehow, as I grew up the world stops being a world of black and white and became a world of grays.  I have observed that many of us continue to be sincere, and many of us do not and it seems that it is an optional attribute, one that we may use at home but not at work.  In many ways I found myself characterizing others as flat characters, inflating their faults or virtues as the context called for.  At work, if someone did not agree with me an internal switch would flip and I would start to see their faults and find ways that I was right and they were wrong.  I never really felt there was anything wrong with that; it became an adversarial relationship (sometimes for only that specific context) that was for the greater good because the person with the best argument would win over and that was good for the company.  Survival of the fittest.

Ok, so what does this have to do with business?  What does this have to do with software development?  Well, there is this little point: that software is created by teams.  Truly productive teams work well together and learn quickly from their mistakes.  Our sincerity or lack thereof directly affects our teamwork.  We all have a sense for when people are being insincere.  Two people may exhibit the exact same behavior – say and do the exact same things – and have completely different results.  Why?  Because we have an internal BS meter.  If you are insincere with me once or twice you may get away with it, but you won’t for long and I’ll quickly filter out what you are saying.

How does this affect software development?  Well, sincerity directly affects our trust and trust is the basis for any productive team.  To learn we have to admit and talk about our failures frequently.  We will not discuss our mistakes without trust.  Without learning, no matter how much we iterate, we’ll keep making the same mistakes.  Sincerity if necessary for trust, which is necessary for learning, which is the largest component of software development.

 
Leave a comment

Posted by on April 7, 2010 in Individuals, Interactions

 

Tags: , ,