Rights and Responsibilities

Becoming agile requires a culture change within your organization, and all cultures have rules, some explicit and some implicit, so that everyone understands their expected behavior.  One way to define expected behavior is to negotiate the rights and responsibilities that people on agile teams have.  Interestingly, a lot of very good thinking on this topic was done in the Extreme Programming (XP) method, ideas which we’ve evolved for Disciplined Agile (DA).

The following lists of potential rights and responsibilities are meant to act as a potential starting point for your team.  We’ve found that it’s very effective to get the team together, discuss these potential rights and responsibilities, and collaboratively evolve them to meet your needs.  We also found that many organizations will first evolve this list to reflect their desired corporate culture, then provide it to teams to modify as appropriate for their specific situation. Note that we use the term “potential” reluctantly – our experience is that the rights and responsibilities described below work very well in practice and that very little tailoring, if at all, should be required.

Potential Rights of Agile Team Members

As an agile team member, we have the right to:

  • Be treated with respect. Let people be heard, don’t talk over people, listen to what they have to say, no name calling, and so on. Every one of your team mates brings something of value to the team so show them the respect you expect in return.
  • Work in a “safe environment.” This goes hand in hand with treating people with respect. Everyone needs to feel they are in a psychologically safe environment, that they can offer input without being mocked or ridiculed. For everyone to freely collaborate they need to know that their input is valued.
  • Produce and receive quality work based upon agreed standards. Establish the work standards up front. Make sure everyone on the team understands the standards and agrees to the standards. No one can be expected to meet moving standards.
  • Own the estimation process. The people doing the work get to estimate that work, resulting in more realistic estimates that people are willing to commit to. Estimates should not be imposed on the team.
  • Determine how the team will work together. The team has the right to determine who is going to work on what task when. The team knows the strengths and weaknesses of the team better than anyone else so they know best, how to meet the team goals
  • Be provided good faith information and decisions in timely manner.  For the team to be effective they need good information to work with and information must be available when they need it. Any delays in providing requirements or answers to questions will reduce team productivity.
  • Choose and evolve our way of working (WoW). Teams should be allowed to work in the most effective way they can given the situation that they face. In agile we call this “owning your process” or “choosing your WoW.” DA helps teams to understand the process-related decisions they need to make, potential options to choose from, and the trade-offs of those options.

 

Potential Responsibilities of Agile Team Members

To misquote Uncle Ben Parker, with great rights come great responsibilities. Agile team members have the responsibility to:

  • Optimize their WoW. Optimizing how we work together should be looked at from a long term perspective. Allowing a specialist to take on 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 ask someone to pair with the specialist, even if it takes longer to complete the current task, to allow them to pick up new skills.
  • 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.
  • Share all information including “work in progress. ” One of the keys to successful agility 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.
  • 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.
  • 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.
  • 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 strategies such as pairing or mobbing are great for this because it reduces the feedback loop to almost zero since several 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.
  • 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.
  • 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 recent work went and talk about things that went wrong and how to fix them.
  • Avoid accepting work outside of the current iteration without consent from the team. For teams following an agile lifecycle (Agile, Continuous Delivery: Agile) commit 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 and put it onto the backlog for consideration.