What does it take to create an agile project that will produce a new system or product? A team, of course. Not to mention the infrastructure required to facilitate the cooperation among stakeholders and within the team. How do you form your teams and how do these teams cultivate a unified vision?
When you are tasked with a complex project that requires more staff capacity than an agile team ideally can muster with 3 to 9 people, then it’s probably best to use many small teams. It would not be very efficient to carry out planning sessions, daily stand-up meetings and retrospectives with teams of about 20 or 35 staff members. Not to mention how difficult the management of such large teams can be. It’s very important to define the teams in such a way that every team member has the necessary know-how for their respective architecture level or system component. Avoid creating component teams, i.e. database teams, usability expert teams, business logic teams etc. At the end of every sprint every team should deliver a potentially applicable product increment or mini product. No team should deliver results to another in such a way that dependencies in terms of time or content develop, which in turn lead to additional coordination and integration expenses. Instead of component teams go for feature teams.
Feature teams are interdisciplinary which means that the know-how regarding all of the architecture’s components is available to the whole team. It is a broad misconceptions that members of teams need to be generalists. Individual members can and should have specialized knowledge so that the feature team is capable of realizing the feature that has been requested by a stakeholder.
The team building process
Naming the group is the first part of forming a team, but only the first part. If your organization is scrum oriented and the role of the scrum master has been implemented, then this is a crucial moment for him. He leads the team through the team building process which begins with a kick-off meeting at the start of the project and which spans the entire duration of the cooperation. This process often takes place in phases¹:
Forming – Introduction and orientation phase
This phase is about getting to know each other, creating rules for the cooperation and the discussion of expectations.
Storming – Conflict phase
Sooner or later every team will experience conflict. That’s when skills like moderation and conflict management are needed. It’s important to recognize when the conflicted parties are operating on the factual level (saying things like: “Your solution is too narrowly conceived.”) to communicate messages on a relational level (meaning things like: “You just don’t get it. You aren’t really the sharpest tool in the shed.”).
Norming – Forming rules and stability phase
Once the conflicts have been overcome and the team has been formed then rules for the cooperation can be developed and optimized and best practices can be distilled. The roles are seen more flexibly, personal relationships prosper and become more harmonious.
Performing – Effective and productive phase
Once the members have got used to each other, the team can attain high performance levels. Synergy effects begin to be felt. The team is flexible and roles can switch among team members as needed.
Reforming/Adjourning – New orientation and conclusion
High performance levels cannot be maintained forever. Changes in the team that result from the departure or introduction of new members force everyone to re-orient themselves. They cycle through the above-mentioned phases until the team is finally disbanded. But the dissolution phases should also be managed by taking a look at the “lessons learned” so that they can be applied in future projects². This provides an opportunity for perspectives from former projects to enrich future ones.
Preparing the cooperation
Even the very best team will struggle to reach the performing phase if the necessary infrastructure for the cooperation is lacking. The purpose of this step is to create the special and technical requirements for the cooperation, both within in the teams and among the stakeholders. Ideally, depending on the teams, one or more team rooms will be necessary to visualize the various possibilities. Try to avoid clichéd environments like: a tiny meeting room with tables that cannot be moved, with a flip chart stand and a dried out magic marker. Don’t just depend on whiteboards, paper walls and colorful moderation material. Use technology whenever appropriate. It can be efficient, for example, if you, together with stakeholders, can directly access the results that were just gathered using a tool so that you can make changes immediately. The tools you use will depend on whether you are communicating with internal or external stakeholders or if the work is taking place with a local team or with team members that are spread out.
Once the project has been established then everyone needs to be informed about the technical details regarding the infrastructure, the organization of the cooperation and the work with the tool. This would ideally be communicated in the context of a kick-off meeting at the beginning of the project. If the stakeholders are to get direct access to the results of the requirements engineering then they need to get an idea of how to use the tool, the type of artifacts that will be used and the storage structure. The best venue for this is a workshop.
Developing a unified vision
So you have everything figured out and are ready to get going. But in what direction? A clear conception of the stakeholders’ goals forms the foundation for a content driven project planning session. It is the requirements engineer’s task to elicit these goals and to analyze them in order to derive concrete requirements. But before that can happen in any detail you need a project manager or product owner and the team needs a vision for what is going to be achieved by the end.
The project manager is responsible for making sure that participants don’t begin working with divergent assumptions. What would happen if you do not manage to get a unified vision in the heads of everyone concerned? Everyone will begin to develop their own ideas about what needs to be built and achieved. The result: the communication will become confusing to the stakeholders. Decisions will be delayed. Misunderstandings will proliferate and the general motivation levels in the team will dwindle. Teams with a unified understanding of what the project aims to achieve are generally more productive than those that are lacking a common vision. The shared vision offers self-organized teams a sense of orientation without impairing their creativity.
A unified vision is best developed in the context of a workshop. Here are some tips for running one:
- Invite requirements engineers and the development team to a workshop. Mention the goal in the invitation and indicate the time frame. Should stakeholders attend too? If you have many stakeholders then the logistics become tricky. You may need to represent the stakeholder’s goals in the meeting through the knowledge brought in by the requirements engineers. If you are developing a new product for the market then the group could get quite large, in which case it might be good to have product managers, UX experts and marketing personnel who represent the future users. You can define personas in advance, i.e. fictional users of the system under development.
- Provided that the central stakeholder goals are clear and the system is known then you can begin establishing the main features of the solution in the workshop. Perhaps the requirements engineers have already derived requirements from the goals. Work out which of the features are particularly important to the stakeholders. If you are developing a product for the market then figure out which qualities will allow your product to stand out from the competition. And remember that when it comes to software and software intensive systems a fundamental understanding of the system architecture is necessary for a unified vision.
- Document the vision. If you want to remember the results of the vision workshop in more detail, create a vision document. You could theoretically create a unified understanding through an 80 page paper. But that’s not very useful. We also would not advise you simply present a business case instead of developing a vision. Try to find a short concise statement that encapsulates what you want to do. Here’s a useful rule of thumb: the vision statement should be so short that it passes the elevator test. That means the statement should be formulated in such a way that you can communicate it in a minute – in a trip from the ground floor to the fifth floor. Difficult? The following can be helpful:
How you use the pattern can be seen in the example:
A well-functioning team, ideally organized as an inter-disciplinary feature team with specialized knowledge by individual staff members, is an important factor for the successful development of products. Every team goes through phases – from the orientation phase, via the conflict phase, the forming and stabilization phase, all the way through to the performing and conclusion phases. It is helpful to have a unified vision for the cooperation. Try creating a pattern for the vision so that you do not limit it unintentionally during the description process.
Formulate the vision so simply and understandably that everyone concerned has a unified idea of the project’s goals. Because the goals and requirements can change throughout the project (e.g. due to changes in the market place), the vision can also change. The vision that you had in the beginning may not be appropriate a few months on. Evaluate the vision regularly and rework it if necessary. The real vision document should be versioned. And once your team is defined and your vision has been established then you need to figure out the path on which the vision will be achieved and if the stakeholder goals should be achieved in concrete applications. How you define a strategy is a matter for another day.
What experiences did you have when forming your team or in using a vision statement?
 Tuckman, B. (1965). Developmental Sequence in Small Groups. Psychological Bulletin 63, S. 384-399, as well as Tuckman, B., & Jensen, M. A. (1977). Stages of Small-Group Development revisited. Group Org. Studies 2, Pg. 419-427.
 Learning from mistakes for future projects. Documenting suggestions for improvement with some capturing help – free download at the microTOOL Download Center.