How to Organize a GSD Gold Agile Scrum Team
It’s time to get organized for success. So, what is the best way to organize a scrum team? We’ve all read many theories on this topic, but we’re not about theory. We’re about practical application of agile principles to get stuff done.
We’re agile. We know there is no single right way to do anything, but we do follow these guiding principles when we are asked to help organize new agile scrum teams:
- Make sure you have the right people in the right roles.
- Don’t make your team too big.
- Make communication and collaboration easy.
We have all worked on those golden teams where everyone clicks and synergy abounds.Those teams are rare and awesome! We have also worked on teams that suck. What made all the difference? Can you pinpoint what characteristics help make a successful team? Agile is about self-managing teams, so our list starts with empowerment, followed by the right skill set and good mix of personalities.
Agile scrum only requires 3 roles:
- Product Owner
- Scrum Master
- Development Team
Product Owner
The Product Owner is the person who represents the people that decide what your team needs to build. In project management lingo, those people are your stakeholders. Stakeholders can be anyone from the owner of the company to the Product Manager to what we in IT affectionately call “The Business.” Whoever your stakeholders are, they are the people who decide whether your team is building gold or crap. Successful Product Owners have an in with your stakeholders and they know what you need to develop to please them.
The Product Owner translates big product features into small sets of requirements. Then, the Product Owner sets the development priority. After your software is built and tested, the Product Owner knows whether your team is on the road to gold or crap. Successful scrum teams have Product Owners that are fully engaged with the team and are willing to make hard decisions.
Product Owners must commit to be joined at the hip with the rest of the scrum team.
What does this mean?
- They translate business requirements into Stories (Chapter 3)
- They prioritize the backlog (Chapters 4 and 5)
- They attend all daily standups and demo sessions (Chapter 6)
- They resolve questions about requirements
Get it? Product Owners are crucial to the success of the team.
What this does NOT mean: They are NOT executives who pop in twice a month.
Expectations of the Product Owner should be articulated and agreed to up-front. If the proposed Product Owner cannot step up to the commitment, then another Product Owner should be identified.
If there is a latency, for example the Product Owner leaves the department or gets pulled away in an emergency, the Business Analyst or Scrum Master can work with the Product Owner offline to clarify the requirements. Not ideal, but this is the real world, right?
Scrum Master
The Scrum Master knows the rules of agile scrum and knows how to apply those rules to get stuff done. Agile is about self-managing teams. Yes, scrum has rules, but not all rules are created equal. The Scrum Master gets to know the team and decides which rules must be followed and which rules the team does not need to follow. The Scrum Master sets the boundaries to ensure the stuff gets done.
Successful teams have Scrum Masters who know scrum, know the team and they are willing to take a stand on processes to keep the team on track.
Scrum masters are NOT task masters or micro-managers who make assignments and set due dates.
It is the Scrum Master’s job to remove roadblocks and ensures the team can stay the course and get stuff done. Examples of everyday roadblocks that the Scrum Master removes include:
- Development team not getting access to an environment they need – Scrum Master chases down infrastructure resource
- Project manager from another team wants a development resource on your team to do a task that “only takes a few hours” – Scrum Master holds team to committed sprint.
More every day examples can be found in the GSD Blog.
Development Team
Let’s be clear from the beginning: Agile scrum is NOT the Wild West. We all know that programmers are the heart of software development, but agile is NOT an excuse for cowboy coding without architecture consideration or design, as witnessed many times in our career by teams claiming to be agile.
GSD Gold scrum projects, have a defined scope and roadmap and release dates. GSD Gold applications are based on clear requirements, analysis and design and quality testing.
How To Make Your Team a GSD Gold Team
In addition to top notch programmers, we advise that GSD Gold Development Teams also include a Business Analyst, Tech Lead or Architect and Quality Assurance testers.
What Number is the Right Number?
Agile scrum recommends your team size range from 7-9 people. Given the roles required to organize a gold development team, we tend to agree. If your team is bigger than that, we recommend dividing your big team into multiple teams. If your project has more than 3 development teams, we recommend dividing up the standalone features into multiple sets of requirements. We’ll show you how to divide and share requirements in a later post.
Is Co-Location Necessary?
Agile scrum experts tell you that the team must be co-located to succeed. In today’s distributed business environment (crossing geographies, telecommuting), few of us have the luxury of working with co-located teams. The unicorn situation is when everyone on the team sits in one common work area.If your team is not co-located, does that mean you cannot use scrum? Of course you can. The key is to provide tools and team rules that enhance communication, such as video meetings and instant messaging and group chats.
Yes, we believe that co-location should be mandatory for local teams. However, you can still be agile with geographically dispersed teams with the proper team contract and tools.
Team Contract
Agile scrum takes the concept of self-management seriously. As soon as the team members are organized, they lay the ground rules and set expectations for respectful member behavior. Successful agile teams then walk the talk of their contract. Team contracts vary by team, but they all outline how team members expect to work together. These contracts are especially important when multiple teams plan to work on the same project and for geographically dispersed teams.
Here are some example ground rules that make up a good team contract:
Respect all team members. For example, always be on time for all meetings and allow all team members to voice their opinion.
Disagree and commit. We don’t always have to agree, but we have to listen to other points of view and come to consensus. Once the team agrees to a consensus, we all move forward to the agreed-upon solution.
Standup attendance is mandatory. If we cannot meet in person, we must dial into the conference line. If we cannot make Standup, we must send an email before the meeting with our status. Again, not ideal, but this is the real world (We discuss Standup in Chapter 6).
Demo early and often. For technical stories, we demo for the team each Retrospective. For high-priority stories, we can demo at the end of Standup after the story closes. We demo for our stakeholders after every sprint. If that is not possible, we must demo for our stakeholders at least once per month.
Direct communication is best. We prefer face-to-face communication, but if that is not possible, instant message and phone conversation are the next best alternatives. We will setup a team chat room.
Every team has different priorities. By agreeing to specific ground rules at the start of the project, when the team first forms, everyone knows what is expected behavior.
< Back to Introduction —– Chapter 2 Project Planning >
Want your very own pdf copy of the handbook?
Click Buy Now and we’ll email you a copy for 50% off the Amazon cover price.