Agile Manifesto, Team Phases and Project Management

The agile manifesto puts the human factor first: „Individuals and interactions over processes and tools“ is its first claim. Here, the people in teams, their interactions and relations have priority over processes and the application of tools. The statement also places special emphasis on the team. But what is a team? Or rather, what is not a team? Not every working or project group is a team by default. A shared vision, mutual support and assistance, active exchange of know-how, collective problem solving, co-operative work and trust are distinctive of a team. Self-organisation is a further characteristic. A truly self-organising team is capable to act autonomously in the midst of crisis and make decisions to effect the purpose of the project objectives. This gives us at least an idea of what a team really is. More gripping, though, is the question of how a ragtag bunch of people can be formed into a team before the end of a project. The characteristics of a team, that we mentioned above, cannot be taken for granted nor do they emerge perforce overnight. They develop in the course of a process of phases that every group inevitably passes through. Following Tuckman those phases are labelled   ((Tuckman, Bruce W.: Developmental Sequence in Small Groups, Psychological Bulletin, vol. 63, 1965, pp. 384-399.)): Forming, Storming, Norming, Performing and Reforming.

Because of the uniqueness of the individual team member and the framework conditions, however, the progression of the team building process is singular. It is never the same, even if it was the same group doing the same project all over again. Thus it is possible that a group repeats a phase – eg the forming because of a change in staff – or skips over a phase just to catch up on it later – we all know the storming rows and dread them in the last week before the deadline, don´t we? Also the length and intensity of the phases and the entire team building process can be completely different from group to group. Some may not even make it to the performing phase before the end of the project. What is really being negotiated are the topics of „membership“, „roles“, „power“ and „trust“   ((Antons, Klaus et al. Gruppenprozesse verstehen: Gruppendynamische Forschung und Praxis. Wiesbaden: VS Verlag für Sozialwissenschaften 2 2004)). Furthermore there is the issue of the unique culture of a team that usually develops. It distinguishes one team from the other   ((Cleo Becker, Eberhard Huber, Entstehung von Projekt- und Teamkulturen und ihr Einfluss auf den Projekterfolg in: Projekte als Kulturerlebnis, dpunkt.verlag 2009 ISBN 978-3-89864-629-1)) and helps the individual member identify with the team and its aims.

During the first phase „Forming“, the group members clarify the topic „membership“, ie the question „who belongs to this team“? Then, over roughly estimated a third of the project time, members will start to make sure of issues like „roles“, visions and norms of the team. Each team has to come to its own role allocation. Some roles, like that of the project leader, are specified structurally, others are open. Besides the role of the Leader you find, for example, the Implementer, the Specialist, or the Teamworker   ((Belbin, R. Meredith Team Roles at Work, Oxford, Butterworth-Heinemann 1993)). Who is going to fill which role is a question of the individual qualities of each team member and the composition of the team as a whole. There can be a good deal of commotion until everybody has found his or her role and position in the team. Quite often even the formally set roles are being challenged – this can result in heavy „Storming“. Some project leaders may groan over all this nagging (and yes: it is bugging!), but in actual fact it is the completion of a very important step in the team building process.

The next phase – nota bene: it might already start while the „Storming“ is still going on! – is the „Norming“: The team members unconsiously negotiate and agree upon a set of rules and norms, eg how is the team going to organise itself and work together? How are decisions (really) being made and by whom? Without a workable agreement on these issues, the team will not be fit for the challenges of a demanding project. If the phase is concluded successfully, however, everybody feels committed and the former bunch may even become a high performance team.

Agreement on team roles and norms is also the soil on which team culture grows: some teams develop a fondness of certain sweets, others crack up on in-jokes, or perform rituals which seem weird or even bizarre to outsiders. Team culture marks how the team building process is going on: however strange or then again unobtrusive the culture of a team may be – if you don´t have it, you don´t have a team!
With these three phases accomplished, the team enters into the next phase of „Performing“. Problems are being solved, aims achieved, the project is being succesfully concluded within time and budget. The team is working together and every one has the feeling that he or she is contributing to the overall success and in doing so is also gaining personally.

Last and definitely not least is the phase of „Reforming“, some also call it the phase of „Parting“. If you have ever accomplished a project in a really good team, you know how it feels: a mixture of elation and pride of what you´ve achieved together with a grain of sorrow over the loss of a great team. If it was really good, the team should take some time to celebrate. This is by far more important to the future motivation of your team members than the bonus they will get. If it wasn´t good, the team needs some time to reflect on what went wrong (honestly!), and what should be changed. So, if you have a „kick-off“ for your project, why not also have a proper „kick-out“?

Now, what does this have to do with Project Management? The successfull accomplishment of a project relies heavily on an efficient and target-oriented team. In other words: a project team must arrive at the phase of performing. But not one day or other: It should be performing at the latest at half-time of the project plan, otherwise there might be bitter consequences. Encouraging the team building process very often is a task that is being neglected by the project management – frequently due to sheer lack of awareness. Project leaders who know how to facilitate the team building process are much more likely to conclude a project successfully. They don´t leave group dynamics to chance – they take chances!

In the framework of agile software develpoment the imperative to mind the team development has been recognised. Scrum, for example, assigns this task to the so-called Scrum-Master. It is his or her responsibility to care for and support the team on its way through the phases. This approach should not be limited to agile software projects but ought to become state of the art of Project Management. Project leaders need to develop a „sense of teams“ plus the capability and knowledge to purposefully intervene and adjust the course of the project to the dynamic process of the team. The „clockwork model“ (Teamuhrwerk®) builds in the team phases as well as the previously mentioned topics and team culture:

The basic idea is to distribute small work packages with short deadlines during the first third of the project. They function like small circles within the big team or project circle. This way the members are encouraged to work together and enter into making relationships. Regular feedback supports communication and the building of trust – which is the basis for real co-operation. Systematically clarifying the individual skills of the team members facilitates the allocation of roles within the team. Problems are detected at a very early stage. As the project advances, the plan is being adjusted to the phases in team building – keeping within realistic bounds, of course. Should the team need more time for „stoming“ or „norming“ – so be it! They can catch up later. But should the team skip those phases, be careful – they might catch up on it later (like, a week before Deadline!)

So, after all those decades putting technical proceedings in the centre of project management without substantially improving project results, why not finally pay heed of the human factor and give team processes a fair chance?

Time to rewind your clocks!