Category Archives: Interactions

How Great Teams Make Decisions

So I’ve been reading We The People: Consenting to a Deeper Democracy which is a book recommended in The Culture Game by my good friend Dan Mezick.  This book describes sociocracy which is a consent-based governance system that looks a whole lot like scalable self-organizing teams.  Ok, sounds esoteric, right?  I agree, the book has been on my bookshelf for at least 6 months and I’m not quite sure why I picked it up, but am really happy I did.

Ok, I just lied, I picked it up because I’m trying to start a new user group in NYC focused on the the human dynamics and culture of high performance teams and I want to create a great self-organizing leadership team.  But I digress……

This morning in the subway, I read the following in a description of teams that practice sociocracy:

The requirement to resolve objections transforms decision making from a struggle for control into a process of puzzle solving.

That resonated for me.  In my experience on the few “magic teams” throughout my career that had really achieved high performance, they made some really great decisions.  And it wasn’t about power or the leader or anything else – it was really about the best decision.  It also wasn’t because we wanted what’s best for the team (although we did), but our mindset was different; it was about solving the problem at hand. And when we had a breakthrough – no matter who suggested the original idea – there was a collective feeling of success.  The mindset here was decisions are all about problem-solving”.

I didn’t realize it until this morning, but decision-making techniques are a really good way to evaluate the ability of an organization to get things done.  Those who can make good decisions repeatably will be much more effective.  And, as the wisdom of crowds tells us, a diverse set of independent non-experts will make better decisions than experts every single time.

Again, looking back at my experiences, but this time with teams and organizations that are struggling, they had difficulty making good decisions.  They could not leverage the expertise of the people they hired and payed good money.  Decisions were often made by managers and those in power who were usually several levels removed from the problems at hand.  This, unsurprisingly, led to low performance and mediocre results.  In these cultures, decisions were tied to power.   The mindset was “the important people make the decisions.”

Ok, so why am I blogging about this?  Well, the idea of “self organizing teams” has always been an ill-defined part of the message of the agile community.  How do they scale?  (Scrum of scrums has never worked for me.)  How do self-organizing teams work together?  Can we get the same level of performance that we get in small teams?

This is a step along the way of answering these questions.  Effective self-organizing teams make decisions with a mindset of “problem-solving” instead of “power”.  Mindsets can scale.  In fact, changing your mindset is often instantaneous.  Also, this is a good diagnostic tool when looking at teams and organizations – how do they make decisions?

Leave a comment

Posted by on April 12, 2013 in Interactions, Organizations, Teams


Tags: , , ,

Instilling Ownership

So, back in 2005, I was introduced to the importance of ownership in software development teams by Ashley Johnson who had just met and attended a presentation by Christopher Avery on The Responsibility Process.  Over the next few years, I met Christopher, attended what I could of his presentations, and eventually started my own journey to learn about they human dynamics of high performance teams.

So, these days when I tell people I work with about Avery’s model and ownership, the number one question is “how do I get others to take ownership?”

In general, I don’t have one answer that is independent of context, but here is a list of techniques that I’ve found useful:

1) Always start with yourself.  You need to take ownership for your actions, and the results you and your team are responsible for.  (Yes, you read it correctly, responsibility for the results of your team, not just yourself.)

2) Respect the people you work with.  We have bulls**t sensors, and we know when someone asks us to do something because they are looking down at us or see us as obstacles.  In other words, we must see other people as people and equals, before we start talking about difficult issues like taking ownership.   (See Anatomy of Peace and Mike Sahota’s write up.)

3) Explain ownership then ask for agreements to come from ownership.  I shamelessly steal Avery’s model and relate it to software development and how a lack of ownership can bring a team’s productivity down significantly.  At Gemba Systems, we thought it was important enough to put it as our first value in our code of conduct.

4) Make it safe.  It is really difficult to take ownership when everything is going wrong.  It is difficult for us to confront and admit our failures.

Hope this helps – amr

Leave a comment

Posted by on April 11, 2013 in Individuals, Interactions


Tags: ,

Avoiding Invisible Impediments to High Performance (QCon NY)

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

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

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

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

Evocative Documents, An Example Agile Adoption Pattern

Here is an example pattern from Agile Adoption Patterns: A Roadmap for Organizational Success:


Definition: Documents are created that evoke memories, conversations, and situations that are shared by those who wrote the document.  They are more meaningful and representative of a team’s understanding of the system than traditional documents.


Business Value: Evocative documents help prolong a product’s lifetime by accurately representing the team’s internal model of the software and allowing that model to be handed down from master to apprentice.  The better understanding of the system over time also reduces the maintenance cost of the system over time because appropriate changes reduce the deterioration of the software. 

Sketch: Aparna and Dave were on their way home from a week long UML training course and discussing what they had learned.  “UML certainly provides a rich and detailed tool for describing our software,” Dave noted.  “But it can still be misleading,” Aparna responded. “Remember our discussion about the customer class?”  “I do,” said Dave, “and I remember how we got into that discussion of what ‘is’ is – when people started using our UML description  as if it was a customer.”  “Oh yes, and that guy in the back talking about Alfred Korzybski and ‘the map is not the territory,’ that was weird,” Aparna added.  “But he was right, really,” continued Dave. “No matter how much detail you get in your UML model and templates, something is always missing.  The model is never the real thing.”  “And our understanding of what the real thing is keeps changing, and changes from one context to another,” Aparna said. “How can we put all of that in a model?”  “Well,” Dave suggested, “we probably don’t need to if we can find a way to remind ourselves of everything we know about something when we need it.”  “How would we do that?” Aparna asked.  “Remember that icon on the wall of the seminar room,” Dave enquired. “Remember when we asked the facility manager about it and she talked for half an hour about its meaning and history, and everything.”  “Sure do,” Aparna responded. “One simple symbol evoked a huge amount of memory.  Maybe that is the secret …”

Context: You are on a software development project where product lifetime and reducing the cost of software are important – you are building a system to last for several years.  Documentation isn’t working – as a document is passed from one person to another much of the context and value is lost, and as a result, the maintenance team’s understanding of the codebase constantly deteriorates.  This is resulting in the calcification of your software system. 


  1. Literate and legalistic societies and organizations share a deeply held, though often non-conscious, belief that written documents are representative in nature.

  2. A contract IS the agreement among parties to the contract.  The blueprint IS the building, albeit in a different format.  

  3. The specification IS the software artifact desired.  This belief is so strong in the arena of software that many believe that it should be possible to formally and mechanically transform specifications into an artifact with no interpretation or ambiguity.

  4. Documents that are built collectively – by having a conversation – are much more valuable to those who were part of the conversation.  These documents are evoke memories of the conversation, its context, and much more than what is merely written on paper.

  5. Agile development is the embodiment of group “theory building” as described by Peter Naur [Naur 1985].  That is, the software we build is directly related to a mental model – the ‘theory’ – that the programmers share.  To impart this model to others traditional documents fail miserably.  Naur suggests that the only successful way to share this model is through apprenticeship.

  6. Agile practices, more than any other kind of development practice, require the creation of a rich and easily accessible “external memory”.

  7. Representational documentation is notoriously limited and has a long track record of failure in supporting “theory building” and acting as an “external memory.”


All documentation should be evocative rather than representational.  Anyone that has read a good novel is familiar with the notion of an evocative document – one that enables the reader to “recall to mind” thousands of sensations, emotions, even details of time and place that the author could not possibly have included in the text of the novel.  

This is how you can truly preserve the shared knowledge and understanding of the team and pass it along to new members.  There is no “one way” to put together such a document, so the distinguishing factor in an evocative document is that it is a reminder of the real information and knowledge in a person’s head – it is not the knowledge itself. It is not directly representational.

A team that relies on evocative documents spends more time in face-to-face conversation and less time building and maintaining documents.  The documents they keep tend to be simple and only comprehensible to those in the conversation – therefore to transfer the knowledge behind the document to someone who was not there, the conversation and context have to be repeated and the document built from scratch.  What is gained by this is a much better transfer of knowledge within context that ultimately leads to more proper understanding of the application and reduced maintenance costs.  

More specifically, evocative documents tend to have the following characteristics:

  1. • Informal – 3×5 cards rather than syntactically correct and detailed UML diagrams.

  2. • Natural language based – both in terms of the natural language used by the team for communication inside and outside the office, but also in terms of the domain driven vocabulary of the project itself.

  3. • Rich in references to people, time, and place.

  4. • Contextual in nature, photos that are rich in color and detail communicate much more than simple UML diagrams. 

Evocative documents are an external memory to a previous conversation.  Evocative documents have value to those who took part in the conversation.  To share such a document with someone who was not part of the conversation they must reconstruct it with someone who was part of the original conversation.  This means that evocative documents are not very scalable.  (The problem is that neither are traditional documents, we just assume they are and are unaware of/ignore the information loss and corruption.)  


Your documentation has probably slipped into representational form and is no longer evocative if:

  1. It takes longer to produce the documentation than it does to comprehend and use it.

  2. Anyone in the organization begins to express a belief that the documentation has intrinsic value and not just utilitarian value.

  3. Documentation that is highly stylized and that uses precisely defined and context free syntax (e.g., UML) will almost certainly be perceived as representational rather than evocative.  However, it need not be, as long as it brings up a shared conversation and/or experience.

  4. There is any kind of movement to make the documentation archival.

  5. Specialists are employed to produce the documentation.  There is an exception to this rule:, technical writers (who should really be more novelist than tech writer) charged with producing manuals and books for users of the software that were prevented from participation in its creation.


Agile modeling, as originally described by Scott Ambler, is a form of just-in-time modeling.  People model to have a conversation and then take a digital photo of that model to remind them of the conversation.  This is a form of evocative document that uses highly stylized languages such as UML.

One last note on evocative documents – they point out a limitation of our current culture and what many of us take for granted.  Accepting the value of evocative documents means rejecting the notion of accurately communicating detailed information in context by writing them down.  You have to have a conversation, the document is there only as a reminder.  As the eminent American philosopher, Dr. Phil says “how’s that working for you?” – how have the reams of requirement, design, and planning documents been working for us?



Ambler, S., and Jeffries, R., Agile Modeling: Effective Practices for Extreme Programming and the Unified Process, Wiley, 2002.

Dahlstrom: external memory

Larman, C., Applying UML and Patterns: An Introduction to Object Oriented Analysis and Design and Iterative Development 3rd edition, Addison Wesley, 2004. 

Korzybski, A., Science and Sanity: An Introduction to non-Aristotelian, Systems and General Semantics (5thedition), Institute of General Semantics, 1994.

Map-territory relation, Wikipedia,, accessed November 2007.

Naur, P., “Programming as Theory Building,” Microprocessing and Microprogramming, 15:55, 253-261, North Holland, 1985.  (Also reprinted in Cockburn’s Agile Development)


Leave a comment

Posted by on March 18, 2010 in Interactions, Organizations, Teams


Tags: , ,