Home

How to Use Agile Principles of Teamwork in Your Project

|
|  Updated:  
2017-10-27 12:06:57
|   From The Book:  
No items found.
Software Project Management For Dummies
Explore Book
Buy On Amazon
Teamwork is critical to agile projects. Creating good products requires cooperation among all the members of the project team, including customers and stakeholders. Agile approaches support team-building and teamwork, and they emphasize trust in self-managing development teams. A skilled, motivated, unified, and empowered project team is a successful team.

Although all 12 principles support the goal of teamwork, principles 4–6, 8, 11, and 12 stand out as supporting team empowerment, efficiency, and excellence:

(4) Business people and developers must work together daily throughout the project.

(5) Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

(6) The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

(8) Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

(11) The best architectures, requirements, and designs emerge from self-organizing teams.

(12) At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Agile approaches focus on sustainable development; as knowledge workers, our brains are the value we bring to a project. If only for selfish reasons, organizations should want fresh, well-rested brains working for them. Maintaining a regular work pace, rather than having periods of intense overwork, helps keep team members' minds sharp and quality high.

Here are some practices you can adopt to make this vision of teamwork a reality:
  • Ensure that your development team members have the proper skills and motivation.
  • Provide training sufficient to the task.
  • Support the self-organizing development team’s decisions about what to do and how to do it; don’t have managers tell the team what to do.
  • Hold project team members responsible as a single team, not individuals.
  • Use face-to-face communication to quickly and efficiently convey information.

    Suppose that you usually communicate by email to Sharon. You take time to craft your message and then send it. The message sits in Sharon’s inbox, and she eventually reads it. If Sharon has any questions, she writes an email in response and sends it. That message sits in your inbox until you eventually read it. And so forth. This type of table tennis communication is too inefficient to use in the middle of a rapid iteration.

  • Have spontaneous conversations throughout the day to build knowledge, understanding, and efficiency.
  • Collocate teammates in close proximity to increase clear and efficient communication. If collocation isn’t possible, use video chat rather than email.
  • Make sure that lessons learned is an ongoing feedback loop. Retrospectives should be held at the end of each iteration, when reflection and adaptation can improve development team productivity going forward, creating ever higher levels of efficiency. A lessons learned meeting at the end of a project is of minimal value.

The first retrospective is often the most valuable because, at that point, the project team has the opportunity to make changes to benefit the rest of the project moving forward.

The following strategies promote effective teamwork:

  • Place the development team in the same location — this is called collocation.
  • Put together a physical environment that’s conducive for collaboration: a team room with whiteboards, colored pens, and other tactile tools for developing and conveying ideas to ensure shared understanding.
  • Create an environment where project team members are encouraged to speak their minds.
  • Meet face-to-face whenever possible. Don’t send an email if a conversation can handle the issue.
  • Get clarifications throughout the day as they’re needed.
  • Encourage the development team to solve problems rather than having managers solve problems for the development team.

About This Article

This article is from the book: 

No items found.

About the book author:

Mark C. Layton, "Mr. Agile®," is an executive and BoD advisor. He is the Los Angeles chair for the Agile Leadership Network, a Certified Scrum Trainer (CST), and founder of agile transformation firm Platinum Edge. Mark is also coauthor of Agile Project Management For Dummies.