Disciplined Agile

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.

Transforming to Agile is a culture change and all cultures have rules so that everyone understands their expected behavior. Disciplined Agile (DA) 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.

Let me first address The Rights of Everyone:

1. To be treated with respect. Whether you are going Agile or not, this is a good thing to promote. Let people be heard, don’t talk over people, listen to what they have to say, no name calling etc etc. Every one of your team mates brings something of value to the team so show them the respect you expect in return.
2. To work in a “safe environment”. This goes hand in hand with treating people with respect. Everyone needs to feel they are in a 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.
3. To 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.
4. To own the estimation process. The people doing the work get to do the estimations so that estimations are not being imposed on the team
5. To determine how teams resources are allocated. 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
6. To 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.
7. To own the team’s processes and be enabled to improve them. DA recommends an initial process but as the team matures the team has the right to adjust and improve the process so that it works for them. The whole point of doing retrospectives is to have the team reflect on how well the last iteration was performed, keep doing the activities that worked and fix the activities that didn’t.

See the post Responsibilities of Everyone where I discuss the other side of the coin and look at responsibilities that pay for these rights.