Friday, July 22, 2011

Personal conflicts and feedback

Solving personal conflicts and giving constructive but personal feedback are two of the hardest parts of being an Agile Coach. I usually say that most problems are quite easy to solve once identified, but personal conflicts and issues between team members can be very difficult and require great creativity to solve.

Two great blog posts on this subject are:

Handling a team member who talks too much which uses the ladder of inference technique, and this post on creating the preconditions for constructive discussions

It is also extremely important to focus on the behaviour not on the individual. A persons actions are not who they are and you shouldn't assume to know the persons attitudes or reasons for the exhibited behaviour. Dominance, for example, usually turns out to be a sign of insecurity. You may find that building the persons confidence with positive feedback and encouragement (often counter-intuitive when dealing with a dominant person) will accomplish just the change in behaviour you are looking for.

Be concrete in your examples, cite specific instances but nothing more than 4-6 weeks in the past. Remind the participants of the situation and then state how this situation made YOU feel. Do not judge or criticise, merely explain how this behaviour affected you and what emotions you felt. Try to get the person to empathise with your feelings and situation and then ask them how they can help you to avoid this feeling in the future.

A talking stick is often useful when exploring an issue in a group as it allows people to talk through until they are finished without being interrupted. Always use an arbitrator - a neutral party - that can act as referee and make sure we stay constructive.

All coaches and managers should receive regular training in communication and conflict resolution. But the most important is that they maintain a neutral and non-judgemental attitude to all of the team members.

Thursday, July 21, 2011

The Kanban board

This is one of my favourite pictures of a Kanban board:


What is the function of a Kanban board?

Many people think it is too keep track of status. For example, I hear all the time teams say that it helps testers to know that a ticket is ready for test. No,  the daily stand-ups (and other verbal communication) are for this. Possibly a note on the ticket saying "test this" but even that I would disagree with. Testing should be an integral part of the development process. Developers should not hand-over a ticket to QA. QA should already be preparing the tests as soon as the tickets enters the team. QA is a parallel process to coding and is as much a part of development as programming code is.

It is my firm belief that the board should have two primary functions:

1. It gives the team an overview of everything, something easily lost in an iterative, ticket-based process. But to do this requires no more states than ready, ongoing, and done. This is important because we don't want to give the false impression that things are nearly done. We've all seen bugs surface at the "last minute" that increase development time by a large %. Using Lean as a guideline; stories/tickets have no value and are considered waste until they are done. Therefore the only important states are Ongoing and Done!

2. The Kanban board helps us to improve our process. Limiting WIPs and columns means problems create bottlenecks which slow us down short-term but force us to fix problems thus speeding up the process long-term. This is the principle from Lean that we fix our problems now, even if it means stopping production, because it is more expensive to fix them later. It is this drive to solve problems in the process that make Kanban an effective tool for improving the development process. Otherwise it's value is severely limited.

Tuesday, July 19, 2011

People are NOT resources.

I just read Ken Schwaber's latest blog post. I felt I just had to quote the following text which lies at the heart of everything I strive for in Agile implementations:
The new VS measures a person’s available capacity. You have to wonder. People don’t have measurable capacities when they are performing intellectual, creative work. Things move back and forth between different parts of the brain and some of the best ideas come at 2:00am in bed.  Scrum and XP are sneaky. A team of people sign up to solve problems within a Sprint. They are engaged in group problem-solving for the duration, and the problem never leaves some part of their brain. They are engaged. Brian’s comments and the consequent tooling reminds me of ideal days: a person is only working when his or her fingers are on the keyboard.
He made, of course, a lot of other good points and I recommend you to read his post.

Monday, July 18, 2011

Encourage failure

The best way to improve a complex system is by trial and error. Don't just take my word for it; watch this Ted Talk presentation by Tim Harford, or this TEDxEutropolis talk by Paul Ilske. Of course, if you use trial and error then you have to accept failure. Not all of your changes will turn out to be improvements. It is equally important to learn what NOT to do as to learn what you SHOULD do. In fact, Thomas Edison once said when he was reminded how many failed experiments it took him to build a functioning light bulb: "I haven't failed, I now know over 300 ways NOT to build a light bulb".

Too many organisations have an explicit or implicit dislike for failure. In business development organisations this is even more common than in software development organisations. This fear of failure leads to stagnation and playing it safe and I think is one of the primary reasons great start-ups lose that dynamic and explosive feeling. At the beginning you have nothing to lose and therefore experimentation (and therefore failure) is more acceptable. But as the business grows so the organisation becomes more afraid of failure and more conservative. Trial and error are no longer acceptable. It is no longer enough to say "I have this great idea I'd like to try out", you now have to provide days of analysis work, risk assessments, etc. etc. and above all be absolutely sure that it will not fail!

Instead of focusing on how to prevent failure, organisations should focus on ways to evaluate the results of changes. We need to be able to assess if a change was an improvement or not. If it was an improvement we want to keep doing it, or even better build upon it. If it wasn't an improvement then we want to go back to the previous successful state. This process should be simple and there should be tools and metrics in place that allow us to make this evaluation. There needs also to be a culture that allows us to make changes and more importantly to reverse our changes in a positive way. There should be no negative stigma in discovering a path of development we shouldn't take, be it in our process or our product.

I think this is one of the drivers as to why Fed Ex days, innovation days, and other such initiatives work so well; they allow experimentation. And through experimentation we learn and improve, because we are hard-wired to learn this way. We are hard-wired to learn through trial and error how to walk and talk. When children play they are constantly experimenting. So why, when we become adults is experimentation suddenly taboo? Why must every change succeed? Food for thought I think...

Monday, July 11, 2011

Continuous improvement

While I would define Agile development as something along the lines of "Delivering the most business value with the least effort" a lot of what Agile is about is continuous improvement. Small incremental improvements done over a period of time that lead to a large improvement in efficiency and effectiveness.

My new job has given me cause to ponder this. Most of my Agile career I have dealt with organisations at the beginning of this process. Organisations implementing Agile or wanting to improve it due to some problems. Now, I find myself in a relatively mature Agile organisation where my team has been practicing Kanban for some two years or so. However, compared to other organisations I have met my teams process could be considered rather sloppy and immature. This has ledd me to ponder the possible causes and my money is on some kind of change friction. Just like a ball rolling will eventually roll to a halt so has the continuous improvement process in my team slowed down to zero. In fact, I would go as far as to say it has gone backwards slightly. The team has shrunk with no change to the WIPs resulting in a large amount of parallelism and the expected lack of focus. The stand-ups are tired and bored (at least that is my feeling) and certainly not indicative of a energetic focused team in a mature phase of Agile implementation. I believe that my team are simply tired of constantly looking for improvements. They have reached a phase where they think everything works pretty well and see no real gains in changing things from where they are. Has anyone else seen this effect? I am now thinking about how to broach this subject at the upcoming retrospective. Anyone got any ideas?

Wednesday, July 06, 2011

Teams of 3-4 members gives optimum productivity and team development.

I just read a very interesting study on group size vs performance. According to this study we really should always aim to be working in groups of 3-4 members and not the 5-9 that is typically quoted.
This research investigated the impact of small and large work groups on developmental processes and group productivity. There were 329 work groups operating in for-profit and nonprofit organizations across the United States in this study. Groups containing 3 to 8 members were significantly more productive and more developmentally advanced than groups with 9 members or more. Groups containing 3 to 6 members were significantly more productive and more developmentally advanced than groups with 7 to 10 members or 11 members or more. The groups with 7 to 10 members or 11 members were not different from each other. Finally, groups containing 3 to 4 members were significantly more productive and more developmentally advanced on a number of measures than groups with 5 to 6 members. Work-group size is a crucial factor in increasing or decreasing both group development and productivity.
Source: http://sgr.sagepub.com/content/40/2/247.abstract