 |
 |
| Home: The Agile Developer's Life: Issue 1 |
Home 
Design Your Life
Personal Coaching
Team Coaching
free eZine
About
Articles
Links |
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Welcome to the first edition of The Agile Life, a new eZine devoted to the human side of software development. There are plenty of books, websites and journals out there that focus on the latest technologies and tools, hot languages, sexy programming techniques and cool new methodologies. These are all important things for developers to know about, but there is another side of developing software that is largely ignored: Software is created by people, for people. This has a number of implications: * Computer programs are the product of the human mind, and the size and complexity of computer programs are limited by how much the mind can comprehend. Almost all advances in software development over the last fifty years have been to get round this limitation. From structured programming techniques in the 70s, to object oriented programming in the 90s, from assembler to modern high level languages, from flow charts to UML diagrams and modern CASE tools, they have all increased our ability to create complex programs by reducing the amount of information that we have to hold in our heads at one time. * Software development is a social activity. Almost all development these days is done in teams of two or more people, and the resultant program is used by others outside of the team. How well a team works together and how well it interacts with those outside of the team are crucial to the success of a project. * Software development is an act of creation. Programming is a creative activity, and programmers must be creative to be successful. Creating a computer program also requires solving numerous problems and making countless decisions. There are many techniques for creativity, problem solving and decision making that can be applied to developing software. * Developers are human, and all humans are unique. They are not interchangeable 'resources' or 'roles', but each one has his or her own combination of skills, knowledge, beliefs, desires, strengths, weaknesses, ambitions, personality. They have lives outside of the project, and what motivates one person may turn off another. The beliefs that a person holds and the goals that they set for themself will determine what they can accomplish. * Users are human too. They are complex social creative beings with their own beliefs, motivations and expectations. Developers should let this fact permeate the whole design of the software - there is more to usability than cosmetic considerations of where the buttons should go, or what colours to use. * We are all systems, and part of countless other systems. A development team is a system, as is the organisation that employs it, and the program they are creating will become part of some other system. The sciences of cybernetics, system dynamics, chaos theory and complexity have much to teach us about how make these systems more effective. I will be exploring all of these subjects and more in future editions. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ When is a team not a team? How are software teams created? In many organisations, a team is formed by finding developers who are not currently working on project (or are on a less important project), informing them that they are now working on project X, and telling them what they are supposed to produce. Often, they are not even moved together, and may be left scattered around the building. They may be given a detailed design document, or a rough outline of the requirements and they have to fill in the details as best they can, often with little or no contact with the person who generated the requirements. Usually there is a team leader or project manager who divides the work up into isolated modules and assigns one or more modules to each developer. Each developer then works away for the next few weeks/months/years on their own part of the whole, with supposedly little need to communicate to the other team members. Eventually the separate modules are assembled together and the long slog of testing and fixing begins. What is wrong with this picture? The problem with the above scenario is that the 'team' members are not working together as a team at all, but are a collection of individuals who happen to be working on the same project. In a true team the members share a common vision and set of goals, and are continually collaborating to solve problems and support each other. Imagine a football team (or any other team sport) where the players ignored each other and each acted in isolation. Here is an alternative picture: The organisation forms a new team by carefully selecting people based not only on their knowledge and skill, but also to ensure there is a complementary mix of personality types - studies have shown that teams with a mixture of personality traits perform better than teams with only one or two dominant personality traits. The team is given its own space and the team members move into it. The team is encouraged to personalise the space, and gets to say who has access to it. The space is fitted out with plenty of whiteboards and flipcharts for group discussions. The person who generated the requirements becomes part of the team, at least part of the time, so the team members have frequent opportunities to clarify exactly what is required. The team members work together constantly as they create the program, holding design sessions round the whiteboard or with CRC cards, and programming in pairs so that all code is the product of two or more heads. Knowledge is routinely shared and discussed, so that everyone knows what everyone else is doing and there are no islands of information. At the end of the project the team is often kept together and given a new project, since the process of forming a new team will impact performance, at least temporarily. The above descriptions are two ends of a spectrum - there are a whole range of teams in between. If you are working in or managing a team right now, where in the spectrum would it fall? How often do the team members communicate? How much of the time do they work together, and how much in isolation? Are you happy with that? If not, what can you do to improve it? This article has only scratched the surface of creating a high performance team. For further reading, I recommend the following books: Agile Software Development - Alistair Cockburn Peopleware - Tom DeMarco and Tim Lister ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ BOOK REVIEW: The One Minute Manager Builds High Performance Teams This book, like all the books in the One Minute Manager series, is a quick and easy read - at 110 pages it can easily be read in one sitting. The book is in the form of a story, following Dan Brockway as he asks the One Minute Manager (who I shall refer to as TOMM, since he does not seem to have a real name) for advice on forming high performance teams. This format makes the information digestible, but don't expect the dramatic tension or character development that you would find in most stories. Firstly, TOMM describes to Dan the characteristics of a high performing
team, using the acronym PERFORM:
The bulk of the book discusses the four stages that teams go through to reach a state of high performance: 1) Orientation - the team is initially excited about being formed, often with high expectations. The team members are uncertain of their roles and need a lot of direction and structure from the team leader. 2) Dissatisfaction - morale drops as personality differences emerge and the team members compete against each other. Many teams get stuck at this stage. 3) Resolution - the team starts to learn to manage disagreement and conflict. Differences are accepted instead of becoming points of contention. 4) Production - the group works collaboratively and interdependently as a high performance team. Morale and team confidence is high. TOMM goes on to explain how each of the four stages requires a different style of management from the team leader. The Orientation stage needs firm, directive leadership, while the Dissatisfaction stage needs a combination of direction and support. In the Resolution stage the leader needs to continue to be supportive but less directive, while in the final Production stage the leader can effectively stop leading the team and empower it to make all the decisions. Leading a team through all four stages is not easy, and requires flexibility and sensitivity on the part of the team leader. In conclusion, I feel that the book does not cover all aspects of creating a high performance team, but does focus on one important aspect of team development and cover it in enough depth that any team leader reading the book can make significant improvements in how they manage their team. The ideas in the book are not new - when I was studying psychology twenty years ago the stages were known as Forming, Storming, Norming and Performing, and are still referred to by those names in much of the literature. However the concepts are well presented in a non-academic, easily digested and practical form. If you are interested in improving team performance this is a good place to start. Buy it from Amazon UK: Buy it from Amazon US: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ That's it for this issue. If you have any comments, thoughts or feedback on anything covered in this eZine, or have suggestions for future issues, then please email me at agile_life@thedeveloperscoach.com. As The Developers' Coach, I offer life coaching to software professionals wanting to make significant changes in their lives. I also offer team coaching for companies that want to forge their software developers into high performance teams. For a limited time, my unique three month telephone coaching program for development teams is available at an introductory 25% discount. For full details of all the services I offer, see my website at Until next time, Dave Kirby - The Developers' Coach
|
| Home
Design Your Life
Personal Coaching
Team Coaching
free eZine
About
Articles
Links |
|
© Copyright 2003. All rights reserved. |