Organizational and Team Best Practices
While it might seem that adopting the agile-scrum framework to distributed teams is all about the right tools (especially if you read marketing materials from tool makers), in general, it is more about how you organize your teams and processes than anything else. For that reason, we decided to break this part of the discussion into two sections. Our assumption is you are only going to read so much during your breaks between meetings, on your smartphone….
Project Initiation
There are all sorts of reasons that a “kick-off” meeting is critical for project success, in fact, we’ve already talked about a few in the earlier posts from this series. But in this part of the series, we’re focusing on the organizational elements of a successful agile-scrum software development team.
One of the areas that are especially important is the cohesion and understanding between the individual members of the team. If it is not taken care of the upfront, it can take a long time to build. If you are not aware of the teaming model developed by Bruce Tuckman, this is a good time to start considering it. In short, Mr. Tuckman found that teams follow a regular pattern of “storming, norming and performing” during their lifecycle. If you can shorten this cycle and get too strong performance sooner, you are better off. We have found that kickoffs that include games, team-building, and participative events go a long way to achieving this goal. In fact, for longer projects, planning similar events around specific milestones prevents teams from going back through the cycle later in the process.
There are many guides available for these activities, but regardless of which ones you find useful, the actual activities are not something you can simply jump into and do from a book. It takes practice and experience to successfully integrate team activities into project initiation so the sooner you start using them the better. We have found teaming model to be an excellent resource, but again, it requires some hands-on experience to use successfully.
What do you need to do to assure success for project initiation meetings?
- Include as many team members as possible in a single location, even if some must travel greater distances. The time and expense will pay off handsomely in the end.
- If some team members or teams cannot attend, arrange parallel events that the teams can report on or share in an online conference format (voice, video, photos, etc.).
- Sync your agile – scrum processes, artifacts, and ceremonies across teams and participants with actual sessions during the joint event. Execute sprints if possible (use Sprint 0 as a base). Set expectations with everyone that the processes will be standardized and adhered to across the entire team.
- Establish a shared product vision with presentations, question/answer sessions, product games, etc.
- Agree on core project hours for the entire team (including product owners, proxies, etc.) and communication standards. Core hours should overlap considering the time zones involved. Ensure everyone commits to core hours and provides proxies if they cannot be reached.
- Agree to set regular meetings during core hours even if not everyone expects to be in the meetings. This assures if questions come up during the meetings, they can be quickly answered.
- Agree on timing for sprint planning, retrospectives, and other planning activities. The more standardized the timing for these meetings, the more likely they will be to be integrated into individual routines.
- Learn and respect cultural viewpoints across the team, festivals, language preferences. Plan to share status around holidays, common activities, etc.
- Encourage an atmosphere of fun, respect, and collaboration.
This is a lot to accomplish in any timeframe, much less a day or a few hours. Project kickoffs must be carefully planned and managed. They could and often should take more than a day. We’ve had initial meetings, including initial work, take as long as a week. Once you have dealt with them to and from aspects of the travel, the rest is relatively inexpensive – so don’t push to shorten the time more than necessary.
Best Practices for All Scenarios
Planning component breakdown during the kickoff.
We’ve said that part of making agile-scrum for distributed teams successful is including many of the necessary best practices in all projects, not just the ones with distributed members. These best practices are critical for distributed teams, but also just good practice in any software development project. Your distributed teams will “catch on” quicker if these are part of your regular practice and adapt to new situations better.
- Participation by every individual in the team in meetings is always important. That said, it isn’t natural for everyone. Team members must be positively coached to engage in active, personal participation. Avoiding situations where one person becomes the de facto spokesman for the team helps to ensure team members don’t sit back and not contribute. Trust is an important element in participation. Team members must feel comfortable questioning ideas and playing devil’s advocate when necessary to draw out concepts and beliefs. Each team member must feel enabled to speak directly with the client/project team to avoid forming communication chains that will inevitably muddle and shorten their message.
- Plan frequent live demos and retrospectives with time for questions and clarifications. Communication in these meetings should not be more tightly time-bound than necessary, but when long conversations do surface, don’t be shy about moving them to a parking lot to be addressed in a specific meeting meant to resolve that issue with the right people involved.
- Scrum masters should be careful to practice servant-leadership roles. They need to concentrate on removing impediments so tasks can move forward rather than prescribing how tasks should be done.
- Pre-plan a larger window of future sprints on a weekly basis (depends on the length of sprints) specifically to expose interdependencies between teams, roles, etc. and groom backlogs with the team as a whole.
- Lean to short sprints rather than long and synchronize/prioritize between teams regularly. Avoid situations where a team could go too far down a path before syncing with others.
- Have irregular, casual “brown-bag” sessions to discuss technical alignment, decisions and common ground among members and teams.
- Find ways to rotate team members. Rotation can be between locations, roles, among teams, etc. Don’t allow individuals to become insular units by themselves or with specific team members. Accomplishing this goal can be challenging, but it is especially important in longer projects. Rotation should not be “one way” (always to the client site for instance) and where it isn’t possible, consider remote pairing too as an alternative.
Granted, these points are not easy to accomplish. They take planning and practice to get right – but the aim is to ensure a successful project and enough cannot be said about how much of success is preparation. The next installment in this series will continue to explore organizational and team issues, there is a lot to cover. We will also cover issues related to specific scenarios that we have found take a slightly different approach. I hope you will stay with us to see how important it is to understand software development projects in an agile-scrum environment and learn more about what is needed to extend it to distributed teams.
If you are coming in the middle and want to jump back to the start of the series, you can start here. Or if you are looking for a software development partner and want to contact us, just click here and leave us a message and we will be contacting you ASAP.