RSS

Category Archives: Individuals

Avoiding Invisible Impediments to High Performance (QCon NY)

09 Apr

I’ve been invited to present at QCon NY this year in the tutorials track by Peter Bell (organizer of the culture track).  Jim McCarthy and Dan Mezick will be there – and they should be great presentations!  But I digress…

So “Avoiding Invisible Impediments” is a full-day tutorial on avoiding….  well… invisible impediments.  All those issues around human dynamics and culture that aren’t necessarily obvious and get in the way of true high-performance.  

No matter how good our technical ‘chops are, if we don’t have the human dynamics and culture for high performance, we’ll experience mediocre results.

Some of the topics that we’ll cover are:

  • Ownership and responsibility,
  • Way of being,
  • Safety,
  • Making and keeping agreements,
  • Ability to fail,
  • Paradox, and it’s place in teamwork,
  • “Seeing” culture,
  • Culture design,
  • ….

We’ll spend all day exploring these topics, making them real and concrete by looking back at the work we’ve done in the past and how these issues can easily block our effectiveness.  

Finally, we’ll discuss practical ways of making these “touchy-feely” topics a reality in our teams and organizations.

 
Leave a comment

Posted by on April 9, 2013 in Individuals, Interactions, Teams

 

Tags: , , , , , , , ,

Culture or Individuals First?

03 Apr

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: , , , ,

Getting away from “agile” and focusing on “high performance”

02 Apr

I’m tired of the “agile” umbrella term even though I’ve made my career being an agile coach and helping teams adopt and adapt agile practices.

So why am I tired of the term?  Well….  Because the value from using it to help people build better software has decreased over the years.  I’ve seen more and more people “do agile” and “be agile” and be “certified agile” without creating high performance teams or getting results.  (Check out the shallot for a humorous version of why I’m disillusioned with the term.)

So, instead of being agile, I prefer focusing on the results – high performance teams and organizations.  Am I trading one catchy phrase for another?  Yes, in a way I am, but not to build another umbrella term – instead I want to shed the baggage and assumptions that come with “agile” and restart our conversation.

So what do I want to do differently?  Well, it turns out agile practices are neither necessary nor sufficient for high performance.  Many teams practice agile practices and fail to get great results and many teams get great results without doing agile.  So what gives?!

It turns out, that every high-performance team (that I’ve witnessed directly) has a culture (to be read “set of implicit and explicit expectations”) that encourages the performance.  And, furthermore, it turns out that these cultures produce certain common behaviors in individuals.

So, I’m not only tired of hearing “agile”, I don’t think agile is the solution.  Culture and individual human dynamics together are sufficient and necessary for high performance.  What type of culture?  What specific individual behaviors?  I’m still learning – and I’m not sure we – the software community – have it totally figured out.  However, here are a list of ideas that haven’t quite coalesced:

  • Mindset is just as important as, if not more important than actions.
  • Respect – both respecting others and feeling respected helps.  
  • Safety.  Feeling safe is needed for innovation.
  • Succeeding together instead of alone (not a zero-sum game).
  • Taking ownership for the success of the group and the problems that arise.
  • Empirical evidence is frequently assessed and taken seriously.
  • Ability to fail gracefully.

But, I’m far from being happy with this list.  I’m getting much better at helping form and join high-performance teams, but there is more – much more – to learn.  So, my solution?  Get as many smart people together to talk about these things and take notes!

Agile Culture New York hopefully will bring together like-minded individuals and world-class speakers to take help us all answer this question of high performance.

 
Leave a comment

Posted by on April 2, 2013 in Individuals, Interactions, Teams

 

Interpersonal debt

03 Sep

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

27 Apr

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

07 Apr

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: , ,

Newer posts →