Team Member Responsibilities

 

As mentioned in a previous post on Team Member Rights, transforming to Agile is a culture change, and all cultures have rules so that everyone understands their expected behavior. DAD has inherited some of the basic rules from the XP world. Each time I present these rules in the training course, inevitably they end up on the list of things that “freaked us out”. That means to me that the rules are really important and that the community needs to be talking about them and getting a clear understanding and acceptance.

The Responsibilities of Everyone:

1. To produce a solution that meets the needs of stakeholders given the resource constraints. The primary goal of the team is to meet the stakeholder needs as best they can.
2. To optimize the use of those resources. Optimizing the resources should be looked at from a long term perspective. Tasking the specialist on the team with a particular type of task may seem optimal in the short term because the task is done quickly. In the long term it may be more optimal to assign a new team member to train with the specialist to do that type of task even if it takes longer to complete the current task.
3. To be willing to collaborate extensively within your team including those outside your specialty. Gone are the days when a developer could go hide in a corner and hack away at code. Collaboration is required across all team members.
4. To share all information including “work in progress”. One of the keys to successful Agile is transparency. If you run into a problem, tell the team so they can help out or at least re-plan. If you complete something quickly, tell the team so they can work on next steps whether that be: testing, or documenting or promoting. Everyone should know what everyone on the team is doing all the time.
5. To coach others in your skills and experience. The goal is to increase the skill set of everyone on the team so be prepared to teach your skills to the other team members. Previously the performance of people was assessed on their ability to perform specialty tasks. The focus needs to shift to how well a person collaborates, shares and increases the teams ability to perform.
6. To expand your knowledge and skills outside your specialty. Again, the goal is to increase the skill set of everyone including you so everyone needs to be open to learning new skills so they can help the team do every required task.
7. To validate your work as early as possible, working with others to do so. No more writing code and getting it promoted directly to production or producing documents that haven’t been reviewed. All code should be reviewed by another developer; non-solo development is great for this because it reduces the feedback loop to almost zero since 2 sets of eyes are always on the code. And all code needs to be tested against the acceptance criteria in the user story. Nothing goes out without someone else on the team reviewing it because it is a team responsibility to ensure quality.
8. To attend co-ordination meetings in person or through other means if not collocated. The co-ordination meeting is the most important meeting of the day and nothing else takes priority. Get to the meeting and get there on time. If you are late then you are holding up the whole team.
9. To proactively look for ways to improve team performance. The retrospectives are designed to fix and improve the team’s process. Come prepared to the meeting to discuss how the iteration went and talk about things that went wrong and how to fix them. However, if you see something during the iteration that can be fixed, don’t wait for the retrospective!! Bring it up at the co-ordination meeting and suggest a fix right away.
10. To avoid accepting work outside of the current iteration without consent from the team. The team commits to complete a specific bundle of work when they start an iteration. That means that all team members have made a commitment to complete all the work in the iteration. If you as a team member take on work from outside the iteration (whether it be from a colleague or an old boss or your current boss) then it means you are not working on tasks for the iteration and you are letting your team down. You should refuse all outside requests for your time. If that doesn’t work tell them they need to talk to the team lead. The team lead should refuse the request. If that doesn’t work then tell them to talk to the Product Owner. The Product Owner should refuse the request but offer to write it up as a user story and put it onto the backlog for consideration.