- Professionalism
- Reasonable Expectations
- The Bill of Rights
- Conclusion
This chapter is from the book
This chapter is from the book
This chapter is from the book
The Bill of Rights
During the Snowbird meeting, Kent Beck said that the goal of Agile was to heal the divide between business and development. To that end, the following bill of rights was developed by Kent, Ward Cunningham, and Ron Jeffries, among others.
Notice, as you read these rights, that the rights of the customer and the rights of the developer are complementary. They fit together like a hand in a glove. They create a balance of expectations between the two groups.
Customer Bill of Rights
The customer bill of rights includes the following:
You have the right to an overall plan and to know what can be accomplished when and at what cost.
You have the right to get the most possible value out of every iteration.
You have the right to see progress in a running system, proven to work by passing repeatable tests that you specify.
You have the right to change your mind, to substitute functionality, and to change priorities without paying exorbitant costs.
You have the right to be informed of schedule and estimate changes, in time to choose how to reduce the scope to meet a required date. You can cancel at any time and be left with a useful working system reflecting investment to date.
Developer Bill of Rights
The developer bill of rights includes the following:
You have the right to know what is needed with clear declarations of priority.
You have the right to produce high-quality work at all times.
You have the right to ask for and receive help from peers, managers, and customers.
You have the right to make and update your own estimates.
You have the right to accept your responsibilities instead of having them assigned to you.
These are extremely powerful statements. We should consider each in turn.
Customers
The word “customer” in this context refers to businesspeople in general. This includes true customers, managers, executives, project leaders, and anyone else who might carry responsibility for schedule and budget or who will pay for and benefit from the execution of the system.
Customers have the right to an overall plan and to know what can be accomplished when and at what cost.
Many people have claimed that up-front planning is not part of Agile development. The very first customer right belies that claim. Of course the business needs a plan. Of course that plan must include schedule and cost. And, of course that plan should be as accurate and precise as practical.
It is in that last clause that we often get into trouble because the only way to be both accurate and precise is to actually develop the project. Being both accurate and precise by doing anything less is impossible. So what we developers must do to guarantee this right is to make sure that our plans, estimates, and schedules properly describe the level of our uncertainty and define the means by which that uncertainty can be mitigated.
In short, we cannot agree to deliver fixed scopes on hard dates. Either the scopes or the dates must be soft. We represent that softness with probability curve. For example, we estimate that there is a 95% probability that we can get the first ten stories done by the date. A 50% chance that we can get the next five done by the date. And a 5% chance that the five after that might get done by the date.
Customers have the right to this kind of probability-based plan because they cannot manage their business without it.
Customers have the right to get the most possible value out of every iteration.
Agile breaks up the development effort into fixed time boxes called iterations. The business has the right to expect that the developers will work on the most important things at any given time, and that each iteration will provide them the maximum possible usable business value. This priority of value is specified by the customer during the planning sessions at the beginning of each iteration. The customers choose the stories that give them the highest return on investment and that can fit within the developer’s estimation for the iteration.
Customers have the right to see progress in a running system, proven to work by passing repeatable tests that they specify.
This seems obvious when you think about it from the customer’s point of view. Of course they have the right to see incremental progress. Of course they have the right to specify the criteria for accepting that progress. Of course they have the right to quickly and repeatedly see proof that their acceptance criteria have been met.
Customers have the right to change their minds, to substitute functionality, and to change priorities without paying exorbitant costs.
After all, this is software. The whole point of software is to be able to easily change the behavior of our machines. The softness is the reason software was invented in the first place. So of course, customers have the right to change the requirements.
Customers have the right to be informed of schedule and estimate changes in time to choose how to alter the scope to meet the required date.
Customers may cancel at any time and be left with a useful working system reflecting investment to date.
Note that customers do not have the right to demand conformance to the schedule. Their right is limited to managing the schedule by changing the scope. The most important thing this right confers is the right to know that the schedule is in jeopardy so that it can be managed in a timely fashion.
Developers
In this context, developers are anyone who works on the development of code. This includes programmers, QA, testers, and business analysts.
Developers have the right to know what is needed with clear declarations of priority.
Again, the focus is on knowledge. Developers are entitled to precision in the requirements and in the importance of those requirements. Of course, the same constraint of practicality holds for requirements as holds for estimates. It is not always possible to be perfectly precise about requirements. And indeed, customers have the right to change their minds.
So this right only applies within the context of an iteration. Outside of an iteration, requirements and priorities will shift and change. But within an iteration the developers have the right to consider them immutable. Always remember, however, that developers may choose to waive that right if they consider a requested change to be inconsequential.
Developers have the right to produce high-quality work at all times.
This may be the most profound of all these rights. Developers have the right to do good work. The business has no right to tell developers to cut corners or do low-quality work. Or, to say this differently, the business has no right to force developers to ruin their professional reputations or violate their professional ethics.
Developers have the right to ask for and receive help from peers, managers, and customers.
This help comes in many forms. Programmers may ask each other for help solving a problem, checking a result, or learning a framework, among other things. Developers might ask customers to better explain requirements or to refine priorities. Mostly, this statement gives programmers the right to communicate. And with that right to ask for help comes the responsibility to give help when asked.
Developers have the right to make and update their own estimates.
No one can estimate a task for you. And if you estimate a task, you can always change your estimate when new factors come to light. Estimates are guesses. They are intelligent guesses to be sure, but they’re still guesses. They are guesses that get better with time. Estimates are never commitments.
Developers have the right to accept their responsibilities instead of having them assigned.
Professionals accept work, they are not assigned work. A professional developer has every right to say “no” to a particular job or task. It may be that the developer does not feel confident in their ability to complete the task, or it may be that the developer believes the task better suited for someone else. Or, it may be that the developer rejects the tasks for personal or moral reasons.6
In any case, the right to accept comes with a cost. Acceptance implies responsibility. The accepting developer becomes responsible for the quality and execution of the task, for continually updating the estimate so that the schedule can be managed, for communicating status to the whole team, and for asking for help when help is needed.
Programming on a team involves working closely together with juniors and seniors. The team has the right to collaboratively decide who will do what. A technical leader might ask a developer to take a task but has no right to force a task on anyone.