How to make Agile Teams succesful

In addition to working in short iterations, or rather thanks to working in short iterations, there's something incredibly agile does differ from waterfall. And that's the way people in different roles work together. In waterfall, roles hang on stages. Analysts grooming requirements. Designers create a functional and technical design. Developers translate into code. Testers validate that the code implements the requirements. And if the application is complete, administrators take them into the database and let it run.

Since all phases are carried out only once, resulting in a final product, the so-called Milestone, it is typical that all the specific rolls, one after the other, work on the project. Sequentially. The transfer between the various phases takes place in that the final product is delivered to the people who occupy the role in the next stage.

This seems a practical and convenient model. During a phase is in fact only a specific roll actively used. Moreover, it seems cost effective. Indeed, during one phase, the other roles are not necessary yet, or they have already done and therefore outflow to the next project.

However, there are quite a few disadvantages to the waterfall model. Think about it. During each phase does one roll a lot of knowledge about the project, on the domain of the customer and the organization for which the project is implemented. While this knowledge has to be recorded as good as possible in the final product of the phase, it is impossible to transfer all the total knowledge into writing. After each phase as part of the knowledge remains behind in the minds of people who just abandoned the project. ‘Goodluck’.

Cooperate in agile projects
How different this is agile. Regardless of the approach or methodology agile projects are very focused on close cooperation between the different roles in teams. Not one after the other, but with each other. This provides immediate value on the subjects of:
? Focus. All roles in the team to focus on the same small set of work items which is realized in an iteration. This focus makes a team effective.
? Feedback. This joint work on this limited set of work items ensures that feedback from all roles is a work item and that it is processed within one or a few days. In a waterfall project often takes months.
? Different look. Each role in a team looks with its own eyes the work items to be realized. An analyst looks at a user story or smart use cases very different from a developer. And a tester is focused on exceptions and acceptance criteria. As a work item at one and the same time from all sides exposed.
? Transfer. No transfer moments as in traditional projects. No documents will be thrown over the wall. The different roles at the same time are working together work item.

Successful Teams
Cooperation in agile has a very different perspective on successful teams. Just like successful sports teams are agile teams much more than a collection of individuals with their own expertise. Optimal operating agile teams are characterized as follows:
? Multidisciplinary. An agile team employs all disciplines and roles that are needed to realize all work items. What roles that vary from project to project and organization to organization. In the aforementioned project, each team counts for example, a COBOL Designer, a .NET developer, a COBOL developer, and a tester. Sometimes even multiple roles in one person.
? Compact. Without exception, agile teams small and compact. Rarely do I create a team that is more than eight to ten people. Scrum defines team size is six plus or minus three people. Once teams are bigger, the efficiency decreases. With the growth of teams, the communication is indeed sharply. This example clearly visible on stand-up meetings. As a rule, these last ten to fifteen minutes. With a large team, meetings last much longer.
? Multiple teams. If a team is greater than ten people, then I recommend splitting the team into multiple teams, wherein each team does have the multidisciplinary composition that is necessary in order to realize the work items. Of course, sometimes it requires more coordination teams. For stand-up meetings, this means that each team has a stand-up meeting. Subsequently, a second stand-up meeting place, where one or two people representing each team. In Scrum, where the stand-up meeting scrum is called the second meeting is also known as the scrum-of-scrums.
? Responsible. Especially where traditional value placed on individual responsibility for individual tasks are agile teams and team responsible for all tasks. If someone is stuck with a job or a task remains for example due to illness, maternity or holiday, it will be taken as soon as possible by others in the team, in other roles. The team members are multidisciplinary.
? Self-regulatory. Much value is attached to the self-regulatory nature of agile teams. Teams make decisions about how to carry out the work and distribute. Agile teams function best when they get the confidence to take responsibility and not the entire hierarchy of the organization on their shoulders. So without directive control of project managers.
? Transparency. Teams in agile projects operate best when communication is transparent. Everyone in the team is aware of the ins and outs of the project. This creates confidence. The previously described example of closed-door meetings with some people from the team is out of the question.
? Co-location. The focus in agile is face-to-face communication. So it is wise to teams as much as possible to operate in one location. Preferably on-site at the customer. Co-location allows rapid alignment between people on the team as possible. When someone has a question, he simply steps to the desk of the person can give an answer. He will answer and to continue with virtually no overhead. The communication is direct and open. Once the physical distance increases between people in a team, the efficiency of their communication is greatly reduced.

People, projects, and teams
Usually, at the time of a start of the project, the best possible team is wanted. This is based on the availability of individual domain experts, developers, and testers. Once a project is completed, everybody runs out and will be available for next subsequent projects. This is the world for many years the standard model of waterfall. But it is questionable whether this is optimal for organizations that agile work. The model is based on the best available individual. and not the best available team. It takes in every project for some time for a group of individuals is actually a team.

Many organizations are staffing a project as soon as it occurs. For movie lovers: this is called the Hollywood model. In agile organizations is a very different model of resourcing projects at hand: let successful teams intact and distribute projects on these teams.

Again for movie lovers: this is how Pixar Studios works. Perhaps it is for many organizations still in the future, but this model makes it easier and understandable to project model makes it easier and insight to plan projects. One no longer has any project looking for the right people, but has projects to integrated and equipped teams, often focused on specific technical knowledge, frameworks or platforms.

This has not always succeeded me at the present company, as too little capacity in the company were available to hold this successful team. But the idea of successful teams and makes it easier to keep prioritizing the portfolio of projects or parts of projects within an organization.

Projects with a high priority are simply previously granted to an already successful operational team. It can even be assumed to be the rate at which realize teams work items. Some teams are simply faster than others. That does not mean that they thus are better. But when the speed of the various teams is known, for example, projects that are urgent be assigned to high-speed teams. This innovative model also offers the possibility to put an end to the role-identified-department-structures that so many organizations have.

Meetings and techniques for working together
Multidisciplinary team collaboration is essential in agile. Meetings and agile techniques, therefore, focus aimed at encouraging cooperation and provide a team of work items:
? Kick-off. the whole team is present during the kick-off of an iteration. So everyone starts with the same idea of what should happen in the iteration.
? Daily stand-up meeting. Every day there is a short stand-up meeting place where everyone talks briefly about the team what he called the day before made on the project, what he is doing today, what challenges and obstacles (called impediments) it imposes encounter and whose he needs help to get it.
? Evaluation. During the evaluation of an iteration, the whole team is present. Everyone delivers so directly contribute to the optimization of the process.
? Workshops. Many works in agile projects is carried out in workshops. Here too, are again represented various roles in the team. For example, when developing user stories into tasks or specifying smart use cases.
? Pair programming. Developers like to work together. Two are now seeing more than once. There are several techniques to promote cooperation between developers. One is pair programming in which two developers sit behind a computer and develop together. Pair programming is great to share knowledge and to write complex code.
? Side-by-side programming. A similar technique is side-by-side programming, where two developers working together on a personal computer at the same work item. Side-by-side programming increases especially effective.
? Pair testing. Also, testers are not alone in the project. They test the work items with the end users. This is true both for the preparation of the functional test scenarios and as test cases to perform these tests. The feedback from the test is then directly related to the processed with the developers.

Daily stand-up meetings
The daily stand-up meeting is one of the most applicable techniques from the wide spectrum agile. During the stand-up discussed the progress in the project from day to day with the team. Thus, everyone is constantly a good idea of where everyone is now working on. Moreover, it has been easy to determine whether a person needed help from others. A stand-up meeting will take ten to fifteen minutes and the whole team participates. During the stand-up, everybody made a questiontour along the fields. Thus, the overhead of these daily meeting remains limited. During a stand-up everybody is there.
The procedure of a stand-up meeting is simple. Everyone in the team briefly answers the following questions, preferably 30 to 45 seconds:
? What have I worked on yesterday?
? At which will I work today?
? What challenges, or obstacles I see, and from whom do I need help?

Thus, everyone in the team gets a great view of where the others are working on and everyone can offer help when someone has a challenge. An additional and often overlooked benefit are that it quickly notice when someone is doing very long about finishing his work item. This is difficult to hide if someone tells every day to work on the same subject.

Of course, all kinds of reasons for this may occur. A work item can be complex, one can be discouraged, but one cannot have the capacity to complete its work item, or too stubborn or too shy to ask for help. It is important to identify as soon as possible and take action. The daily stand-up does just that.

A few tips:
? Park substantive discussions. During the stand-up teams often lapsed into substantive discussions. Of course, these are useful and necessary, but in most cases, they will have one work item that only works part of the team. It is important during the stand-up to identify the debate, park it, and to propose further to talk about after the stand-up. At ‘petit committee’.
? Time Boxing. Run the stand-up meeting in a timebox. Projects usually choose a timebox a quarter an hour. In many projects, the ScrumMaster have to maintain this timebox by putting down a kitchen timer, which is run at the start in fifteen minutes. This practical tool helps the team not too much to elaborate.
? Time. A question I get a lot is what time is most suitable for the stand-up meeting. Naturally, this is preferably in the morning. As the work is discussed the next day. Many projects organize stand-up at ten o'clock. In an ideal situation, the stand-up every day at the same time place. And at the same location. Thus, it is clear to everyone when he is expected.
? Dashboard. Almost all projects have a dashboard that has sticky notes on the wall. I recommend organizing the daily stand-ups around the dashboard. This makes the discussion of the progress even easier. The daily stand-up meeting is a simple technique that I that I recommend to all projects. Traditional projects also benefit from such a simple daily progress meeting.