Pink Rose, Beijing: Martin Harris.

I have been reading chapter 12 of Succeeding with agile by Mike Cohn.  The chapter title is Leading a Self-Organising Team. I have been reading it in the following context:

Strive for technical excellence and Improving technical practices is not optional.

Why is it that improving technical excellence is sometimes neglected on a project?  Why do developers think its ok to check in classes with warnings, leave essential and easily written tests out or add to messy code.  You must of heard the phrase “nobody cares about a building with broken windows.”  One more broken window will not matter. The same applies to software. Often you will find developers harboring some kind of guilt for not fixing things.

Once possible reason for this that I offer, is these teams although self directed are not being managed correctly. Draw a cause and effect diagram for your team, and include pressure or influence from management. Is there pressure to deliver at the expense of quality improvements?  Have you got managers using downward pressure to influence teams? There are other reasons but it seems to me that its more than just the scrum and agile practices, the team needs to engender a culture of self improvement and continuous change.  Conceivably a non scrum team with the right culture would work out its own scrum and agile systems if they had the right mindset.

I am of the view that building a team with a positive drive to deliver quality and meet deadlines is extremely difficult. Its hard to build up the right attitude and one short word, or foolish reaction from someone with influence can destroy that process.

So what is the alternative?  Unfortunately the alternative requires a great degree of skill and thought to pull off.  Its much harder than dragging a team into a room and attempting to bully them into submission.

Just to recap to improve technical excellence you need a team that actively engages in engineering practices.  Its easy to list them off: TDD, Refactoring, Collective Ownership, Continuous integration, Pair Programming.   Its quite another thing for a team to actively pursue the improvement of these processes and have the collective view that “Improving Technical Practices is not optional“.

Chapter 12 has the best write-up I have seen so far on how this might be done.  It suggests more subtle ways to influence your team to enable them to do this.   If anyone knows of similar works let me know as I want to build on this.

The following is just a list, read around and practice them to fully understand the processes.  Never be tempted to take the pressure your under and just apply it raw to the team.  This will have the opposite effect to the one you require often causing morale problems and damaging the team interactions.   This ultimately leads to reduced quality, higher defect rates and slower delivery and change.   All of these techniques require a deep understanding of how the team works.  Spend time working with your team to understand how its working or not as the case may be.

Once you have a handle on what is working and what is missing there are a series of alterations that can be made to change the balance.  The team will react to this and if you get it right adapt and improve from inside.

So these are the high level things I am looking at currently.  Check out the book for more detail.

Adjusting containers: Teams have boundaries and members.   This effects the way the team self organises.  Adjusting these changes the personality dynamics and can alter the skills balance in the team.
Example: Perhaps one member is too strong reducing discussion.  Another counter strong member might stimulate dialog and stand up to them.

Amplifying or Dampening Differences: The idea is to draw out those differences.
Example: Stimulate dialog by asking the team some hard questions about architecture or process that is not currently working.

Altering exchanges: Changing the way the team communicates with itself or other entities within the organisation.
Example: One team keeps impacting and rubbing up against another. Introduce a practice where individuals attend each others scrums. Mix it up, make it different individuals each day and get them to report back.

Apologies for the shallow list each of the above can be achieved in many ways, and a certain amount of creativity is required to make it work.  There will be failures but its important to keep experimenting and changing the equilibrium.  In summary its techniques like this that address the fundamental issue for me, how to get teams to fully take collective ownership and evolve towards continuous improvement.