#begin
With the 2020 election just, sort of, finished with America mostly fighting for equality I thought it would be fun to talk about (not that I want to get political): The Customer Bill of Rights and it’s complementary Developer Bill of Rights. I read this years ago but got reminded of them last year by the book Clean Agile by Uncle Bob[1].
This was written all they way back in 2001 during the famous snowbird meeting while discussing the Agile Manifesto, at least, that is what the Clean Agile book says. Kent Beck, Ward Cunningham, and Ron Jeffries, among others, wrote down the following statements. It is part of the eXtreme programming Bill of Rights.
To put these rights into context properly, you need to read them with the Agile Manifesto and methodology in the back of your mind. Like; no big upfront design, working in iterations and having deployable software each iteration. By the way, notice how each developer’s right is complementary to the customer’s right while you read them:
Customer Bill of Rights
- 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 the 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
- 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 estimates.
- You have the right to accept your responsibilities instead of having them assigned to you.
So let’s go over each of them and discuss their meaning.
Customers have the right to an overall plan and to know what can be accomplished when and at what cost. While, developers have the right to know what is needed with clear declarations of priority.
For many people in the Agile community, the words `upfront design’ are pure evil. They claim that upfront design is not part of Agile. But, of course, every business and project of decent size needs a general direction to be heading to. Agile simply disproves BIG upfront design, like with the waterfall method.
Upfront design with Agile simply requires, just enough, pragmatic and accurate documentation in order to properly start and finish an iteration. The plan must match with the level of uncertainty that can be mitigated. This means developers will not be able to promise to deliver at specific dates, instead, developers might be able to deliver in a date range with a certain probability. Customers have a right to a probability based plan because they cannot manage their own business without it.
Now, on the other hand, us, developers are entitled to precise and accurate requirements with a clear prioritization. Yes, the same constraint of `probability’ the customers have for estimates holds for those requirements as well. Customers often do not exactly know what they want or even need. So there needs be some kind of consensus between the customer and programmers.
This right only applies for the requirements in the boundaries of an iteration; outside the iteration, requirements will of course change. But within an iteration, developers have the right to accept the requirements as immutable. However, to the advantage of the developers, if the requirements are still unclear or somehow impossible to achieve within the given iteration time, they are allowed to waive the requirement. They can ask for a revision of the requirement and discuss it with the customer in order to clear it up or fit it in the given timeframe.
Customers have the right to get the most possible value out of every iteration. While, developers have the right to produce high-quality work at all times.
An important aspect of Agile is that a project is done in iterations. During these iterations the most important requirements (user-stories) are taken on for maximum business value. The customer can choose these requirements as long as they fit within the timeframe of an iteration.
Now, the developers, they have the right to always produce the highest quality work possible. Neither the business or even the customer are allowed to push and force the developers to cut corners and rush the work they are doing. Doing this will hurt their professional reputation but also impact the product they are working on.
When I first read this right, I though it was profound; I have been in this situation before where we knew, even before the iteration started, there was no way of getting things done. Ever since I read this, I try to remind myself to check the stories before the sprint is started, and if I suspect they do not fit within the iteration I will call it out before the sprint starts. For the good of the development team, the business and ultimately, the customer. This opens up room for discussion and fine-tuning of the requirement. The good part is, that you will most likely have to involve the customer again which will make him/her feel involved in the project. The customer will probably also better understand how properly formulate a requirement next time.
Customers have the right to see progress in a running system, proven to work by passing repeatable tests that he specifies. While, developers have the right to ask for and receive help from peers, managers, and customers.
The customer must be able to observe progress that match the stories in the iteration. They must be the ones defining the criteria for acceptance of this progress. This all seems obvious but I can remember projects where we did over 8 (1 week) iterations until the customer even got to see the project, which of course did not match his expectations. The customer must be involved since the beginning of a project. On the other hand, I also remember iterations where the customer was deeply involved and where each sprint there was a proper delivery, that the customer would test and play around with. The customer would then provide meaningful feedback for the current and next iterations to come.
Developers have the right to ask any stakeholder on the project for help. This means, other programmers on the team, for solving problems or pair programming. They could also ask the customer to refine the requirements of certain stories that they are working on in order to manage his expectations. This right essentially gives programmers the right to communicate, which is very good for the team and overall morale in a team.
Customers have the right to change their minds, to substitute functionality, and to change priorities without paying exorbitant costs. While, developers have the right to update their own estimates.
Customers must be able to change their minds about the software as it is being developed. Many times have I experienced a situation where a project completely changes during it’s development time because the customer gets more insight into the problem space and capabilities the software might have to solve it. This is a good thing! This way, the customer gets the highest value from his investment. As a business, manager or development team, we should not fight this, but support it. With agile, there should be some deployable system each sprint so changing direction should not hurt the customer.
Developers, and no one but the developers, are able to make their own estimates. I remember needing to implement a networking solution in Unity3D for a customer. Now, someone else on the team had estimated this to be 2 weeks worth of work. However, they forgot to estimate that this particular customer required a very custom solution, on a privately owned network, with no central server, and custom git-like merging of their data. It took me about 5 weeks to fix this, even without the merging of data. I should have re-estimated all these tasks before I started on them, and well, the fact I remember this quite fondly indicates I will not allow this to happen again. I can also remember a particular requirement where I needed to essentially implement recursion in our tree-walking-like algorithm (yeah, recursion in a tree structure sounds weird). I thought this would take me 2 weeks at least, however, I was able to get a prototype running within half a day. Then, the entire thing was implemented in 3 days. Then I gave an early demo to the customer and he was amazed that it was already finished and he could start to create new user stories for the next iterations based on this. Also, developers must be allowed to update these estimates as new information emerges. Then again, these are estimates, which are uncertain to say the least. Developers try their best making sure that estimates are correct, but they might still be wrong, that is why estimates are never commitments!
Customers 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. They may cancel at any time and be left with a useful working system reflecting their investment to date. While, developers have the right to accept responsibilities instead of having them assigned to them.
Customers have the right to always be informed of the schedule, they can however not demand to conform to the schedule since is not their business and software is still very hard. Their right is limited to managing the schedule and scope of the project. More importantly, they have the right to know if the schedule is in jeopardy in order to manage it on their end. When customers deem the project done, for now, they must have a deployable solution at the end of the iteration.
Developers have the right to accept responsibilities, instead of having them be assigned. This particular one also made a huge impact on me personally. I have experienced people higher up in the food chain making their problems my own just because they knew I could fix them. When this happens now, I gladly tell them I do not accept this particular task within a given iteration. Now, of course you should discuss this because many times a task can be broken down and be fit within an iteration. So I would not blindly refuse to do something but always try to find a middle ground or postpone it until the next iterations where it might fit.
But what about managers?
You might be reading this, and thinking; Ruben, you spoke about customers and developers but what about managers, don’t they have some rights in all this. And yes, you are correct, there is apparently a manager side to all this. It was not even in the Clean Agile book[2]. Nevertheless, it goes as follows:
Manager Bill of Rights
- The manager has the right to an overall estimate of costs and results, recognizing that reality will be different.
- The manager has the right to move people between projects without paying exorbitant costs.
- The manager has the right to monthly updates of progress, and to help the customer set overall priorities.
- The manager has the right to cancel the project and be left with a working system reflecting the investment to date.
The manager’s bill of rights is very similar to the customer bill of rights, let’s quickly glance over them as well:
The manager has the right to an overall estimate of costs and results, recognizing that reality will be different.
Just like the customer has a right to be informed about costs and estimates the manager has this right too. The Manager needs to make intelligent decisions about scheduling and agreements he or she makes. He must however recognize that the reality will always differ from the estimated costs and time. This allows him to properly do his job, namely, manage the project. He could discuss the progress with the customer and come to an agreement that some requirements should be improved, even more new features could be added or that some features are not cost effective to implement at the moment.
The manager has the right to move people between projects without paying exorbitant costs.
This is a very important and powerful right for a manager to have and it essentially means that everyone in the company should be replaceable at any time (to a certain degree of course). Now, how would a manager accomplish that you might ask? Well, by allowing the developers to share their knowledge across teams and having a well defined work-flow, architecture design and coding standards. Easy ways of introducing developers from other teams might be through code reviews, internal tech-talks and maybe even like a short weekly meeting with all developers. The manager must be able to switch developers around, maybe based on their specialism, to accomplish the goal(s) of the iteration.
The manager has the right to monthly updates of progress, and to help the customer set overall priorities.
A manager has the right to be informed of all notable things that are going on in the company or involve the company. This way he or she can properly align the customer’s wishes with the company’s strategy. While working at my previous job, this was really done well. We would even implement key features of our product that were highly dependent upon the customer’s wishes in order to progress our own product. One thing to keep in the back of your mind here, is not to allow the customer to shape your product, or company even, in such a way that you, become dependent on him.
The manager has the right to cancel the project and be left with a working system reflecting the investment to date.
This might sound counter intuitive, why would a manager ever do this, but it could drive profit in a positive manner. If a project was agreed upon with a fixed price, and it is successfully finished and deployed before the estimated deadline, a manager must be able to stop the project. Now, you should not exploit this completely to maximize your profits but it can be a good move to call off a project when all requirements are met and the customer is happy with the end result. Another option when a manager must be allowed to call off a project is when there is no apparent ending and the project just keeps getting more expensive, complex or information has come to light that simply makes the project impossible to finish with the given requirements. Imagine some new law being taken on that simply forbids certain key features of the software like tracking privacy related information.
Conclusion
Now, why would all this be important for software quality? Well, because having all these points straight with the customer, the development team and the managers is a recipe for a good quality project. It increases the involvement of the customer which is a good thing. It provides rapid feedback and allows him to be in control of his investment.
Having the technical aspects in place will increase morale on the development team, which will make a large impact on their involvement. It will make the team feel heard when they speak up, it will also make them feel in control of the development process and not just blindly accepting any tasks that come in and hope to have them finished at the end of an iteration. As Martin Fowler put it: Developers are not just code monkeys!
Then, having a manager that understands both the point of view of the customer and the developers will make a key difference in management of the project. Also, understanding his bill of rights will allow him to make better choices.
I think it is interesting that all parties involved feel like they will have full control of an iteration (and the project), however they all have about equal rights.
As it should be…
#end
01010010 01110101 01100010 01100101 01101110
References
[1] Clean Agile – https://www.amazon.com/Clean-Agile-Basics-Robert-Martin/dp/0135781868
[2] Bills-of-Rights – https://alvinalexander.com/programming/extreme-programming-bill-of-rights-programmers-customers-managers/
Recent Comments