RSS

Category Archives: Teams

How Self-Organizing Teams Get Stuck

Self-organizing teams are those teams that are given a goal and decide amongst themselves how best to solve the problems at hand to achieve the goal.  In the agile world, these teams also work in small cycles and use feedback to learn quickly and adjust course as needed.  When things go well – these teams do extremely well.  In software that usually means building great software that delights the customer.

But things don’t always go so well.  I’ve been on many such teams that don’t achieve those levels of performance and sometimes fall flat on their face and fail miserably.  What happens?  Here are some common stumbling-blocks that I’ve observed:

  • Lack of safety.  When individuals on a self-organizing team feel unsafe to share their thoughts and experiences and ideas the team is unable to leverage that expertise to make decisions and learn quickly.  Therefore the teams learn more slowly and make more mistakes and are blocked.
  • Lack of ownership.  When individuals don’t take ownership for the success of the team, they watch mistakes happen within the team and “don’t step up” to fix them because that is not their responsibility.   However, self-organizing teams kick-ass because they are able to leverage the diversity of the group.  They make great decisions and learn quickly because everyone takes ownership for the success of the group.
  • Not addressing problems early.  No matter how safe things are, or how much ownership you take, if you don’t see problems and address them when they are small, you have no chance of achieving high performance.  The problems grow and become significantly harder to solve.
  • Not caring about human dynamics.  Sometimes we get annoyed with each other.  Sometimes we have disagreements and some bad feelings linger and may fester.  Great teams don’t let these things build up and have the difficult conversations quickly.  However, for the rest of us, this is the beginning of the end.  We end up spending too much of our time working with things.  We start to feel unsafe around others.  And we disengage.
  • Not using consent.  Self-organizing teams do the best they can to get everyone’s input and make it real.  That is best done by consent – not majority rules – or leader rules – or more experienced rules.  You miss too many opportunities to do the right thing and catch mistakes early if you discount someone’s ideas.  They have legitimate concerns even if they are the in the minority.  Effective teams take the time to listen and address those concerns.
  • Not able to confront and learn from failure.  Knowledge work is all about creating something new.  And creating something new is always fraught with mistakes and missteps.  However failure is often unsafe and painful.  Teams that are unable to confront failure will not learn from those opportunities and will often take much longer to get to a less effective solution than teams who fail fast and learn from those failures.

And, if you manage to get it right at the team level – how does this scale?  Or does it?  In many organizations, a small team doing well will only be a blip on the radar and won’t really affect the success or failure of a product, let alone the organization.  But that’s a topic for another post, stay tuned….

 
Leave a comment

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

 

Tags:

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

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

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

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

 

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. 

Forces: 

  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.”

Therefore:

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.)  

But:

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.

Variations:

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?

 

References:

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, http://en.wikipedia.org/wiki/Map-territory_relation, 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: , ,