RSS

Category Archives: Interactions

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. 

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