AgileMalta

Building a Successful Team

Filed under: Agile, Events, Teams — Aldo Cauchi Savona @ 11:05 pm

This post is an overview of my talk at the December 2008 AgileMalta conference. It is slightly oversimplified, but there is only a certain amount one can say in a blog post I hope that this post will help you get more value from the talk slides. My main interest in Agile lies in the area of Process Facilitation and Team building. It is my opinion that the greatest investment a company can make, is to improve the quality of its workforce and in the creation of one or more Teams.

The presentation is based on the following observation: A team is inherently dysfunctional.

It is common knowledge that the greatest ‘resource’ of a company is its workforce. Also, the quality of these ‘resources’ has a major role in determining the outcome of a company’s projects. From a traditional approach, the idea of quality lies in the skill level and the experience the ‘resource’ has. The focus is mainly technical. The person is viewed as a ‘resource’, a replaceable part, a concept that stems from the idea of specialisation in the manufacturing industry (see Implementing Lean Software Development: From Concept to Cash, Mary & Tom Poppendieck, 2006).

The focus of attention is also on the individual. Most of our progress (from school to work) is measured on our personal ability. We have personal reviews with our managers who give us personal targets to reach in order to attain a new level in our career or change our pay-scale.

The talk also delves into a bit of psychology with regards to the evolution of the Ego… Over time (past couple of centuries) people developed an Ego and psychologists say that it has now reached its peak. By ego I refer to the psychological notion which allows us to say “I” or have a concept of “self” (see The Archetypes and the Collective Unconscious (2nd. ed), C.G. Jung, 2002).

As such we can say that, due to our individuality, we are naturally dysfunctional within a team. Companies further promote dysfunction by focusing on the individual.

In the presentation I also make a common distinction used in Agile between a Group and a Team. A Group is the most common setup within companies. Each person in the group has a particular area of expertise, role and responsibility. While working on the same project they are working towards different targets (namely, the ones set by management).

In contrast, a Team happens when each person in the team is moving in one direction. From an external point-of-view, the team is a single entity with one goal.

In team-building exercises, attendees are often shown an image of synchronised rowing. There is also a common cheesy poster I saw in a three companies I worked for with such a photo and the title “Teamwork”. However, when we set individual targets, each person is offsetting the rhythm of the group hindering the speed at which they reach their goals (see slide 10 in presentation). It is called synchronised rowing for one main purpose: each member in the boat rows to the same rhythm. The more synchronised the team is, the faster they reach their goal.

Should a company decide that they would like to have a team and not a group, it first has to realise that it is dealing with people that are more complex than a fixed ‘resource’. Also, since individual ‘treatment’ is not the solution, the next step to resolving dysfunction, is to decide on a single goal for the team. The decision is made together with the team and not for the team.

While the whole company is involved in creating the team, the emphasis is now on the team and it has to find a way to reach this goal as fast as possible. The team has the help of management or in Agile, the process facilitator, who helps them find the motivation required to reach their goal.

This is only the starting point. The common pattern that emerges is that individual traits that hinder development speed are brought to the surface. Other issues, technical or otherwise, that before were easily covered up are also exposed. The first reaction to this situation is usually a retreat to the safety of the past behaviour. This is where most teams fail. You will need to courage and persistence to surpass the difficulties that arise if you truly wish to reap the benefits of a team.

Click here to download the talk slides “Building a Successful Team”.

Agile Discipline and Quality

Filed under: Agile, Teams — Aldo Cauchi Savona @ 1:42 pm

Earlier this week, I heard a comment by someone I was speaking to that they do not like Agile methods as they proclaim that the developers should not product any documentation or else, that there is no need for any planning. This was not the first time I heard this comment. One person exclaimed that when he worked in a company that used Lean practices, bad quality products were delivered thanks to the Lean practices they used!

Apparently, the people they worked with interpreted reduced documentation and planning for no documentation or planning. This gives rise to the view that Agile = Lack of Discipline = Bad Quality Products = Bad Process.

Anyone who has decided to dig a bit deeper into Agile and their theory would know that they are founded on two fundamental principles: Discipline and Quality. A great example where adequate documentation and quality driven development was used is the Boeing 777 project. Their aeroplane was ready for in-flight testing after 2 years of development, 3 years ahead of the norm.

If at the moment your team is not producing any form of documentation, or have a poor development development process, then when transitioning to Agile, you will most likely have to produce more documentation and do more planning than you currently do. When Agile practitioners talk about streamlining your documentation, they mean reducing the amount of documentation an existing cumbersome process might require. Again using Boeing as an example, the 777’s electronics specification document was over 2500 pages. When Boeing increased the collaboration with their provides, they could reduce their specification. The end result was that the 787 electronics specification document was reduced to 20 pages.

Agile methods ask all committed people to be more involved in the project, and to always act in the best interest of the project. This requires great discipline and dedication with the end result being a high quality product!

_{See: http://leadinganswers.typepad.com/leading_answers/leadership/;}

_{Implementing Lean Software Development: From Concept to Cash by Mary and Tom Poppendieck.}