Introduction
Who, among every self-respecting agilist, doesn't know the Agile Manifesto! If you are reading these lines, this document is not unknown to you. You may know some of its values, perhaps all of them, and for the most academic among you, the principles … by heart.
But do you know the Declaration of Agile Rights? No? It's not surprising: this declaration clearly hasn't made a place for itself in the spotlight the way its cousin the manifesto did. Why do I say cousin? Because it was some of the signatories of the manifesto, during that same meeting in Snowbird, who wrote this declaration. (« sous la plume de Kent Beck, Ward Cunningham, Ron Jeffries et quelques autres »)
It was while reading the excellent «Agile Proprement» by Robert C. Martin ("Clean Agile") that I discovered it. If you haven't read it yet, I can only encourage you to get a copy of this book and devour it, like a captivating story told by your adventurous great-uncle. I will surely write a dedicated post to talk about it at greater length, but for now, I want to introduce you to this little-known nugget that is the Declaration of Agile Rights, discovered after the first 50 pages of this book.
Declaration of rights
| Client's rights | Developer's rights |
|---|---|
| You have the right to get an overall plan and to know what can be achieved, when, and at what cost. | You have the right to know what is expected of you, with a clear statement of priorities. |
| You have the right to get as much value as possible at the end of each iteration. | You have the right to produce high-quality code at all times. |
| You have the right to be able to see the progress of a working system, whose quality has been proven by reproducible tests that you have specified. | You have the right to ask for and receive help from your colleagues, your managers and your clients. |
| You have the right to change your mind, to replace one feature with another and to modify priorities without suffering an exorbitant extra cost. | You have the right to make your own estimates and to update them. |
| You have the right to be informed at any time of changes to the schedule and the estimates, and early enough to be able to decide to reduce the functional scope if you need to meet a fixed date. You must be able to cancel the project at any time and obtain a working system in proportion to the budget already consumed. | You have the right to accept responsibilities instead of having them forced upon you. |
I have deliberately presented the rights of the 2 parties in table form, because, as the author of the book says, each right answers the other and complements the right of the other party. I will let you discover the detailed explanations of each right in the book, but without paraphrasing it, I will allow myself to give you my view.
Point of view
-
(client) Surprising as it may seem, he starts by telling us that we must make estimates, and on the whole project! But with a certain nuance: this estimate must be as precise and accurate as possible, given the team's current state of knowledge. Nor should it lead to a commitment on date or scope. He recommends providing probabilities of delivery times. Which allows the client to properly steer their activities
(dev) On their side, prioritization is put in the spotlight. This precious knowledge may seem in opposition to welcoming change, which is normal in agility. That is why it cannot be fixed for the whole project; only, at a minimum, for the current iteration, at best for 2 or 3 iterations. -
(client) This is a right that bites its own tail a bit, since it is up to the client to prioritize production, but it is the devs' responsibility to respect it
(dev) This is a right that is often trimmed down, even though it is essential and inalienable. It touches the very reason for being of any self-respecting developer. Trampling it comes at a high price in the long run. -
(client) Any client who does a minimum of follow-up should be very demanding about this right. It's their money and their time that the devs consume. You might as well check that it's being put to good use.
(dev) Communication is at the centre of this right. Communicating knowledge, requirements, priorities. Without that, how can you demand estimates, quality, value production from devs? -
(client) Due to the immaterial nature of software, any change should be possible, while accepting the extra costs generated.
(dev) It's those who do the work who know! And it's by doing that you can better appreciate the amount of work needed. However, it remains an estimate, which can be false or inaccurate, and therefore not a firm commitment. -
(client) The client's right here is to be kept informed; they do not have the right to demand that deadlines be met. This is essential for them to react according to events, even if it means changing their mind, their direction or outright cancelling the project if necessary, without that being held against them. In the end, it is only the right to be a good manager.
(dev) On the one hand, you can see some Lean in it with a pull flow. On the other hand, you can see the developer's appreciation in it. Does he feel legitimate? Is the request legitimate? Does it go against his convictions? This right is, in the end, quite important and heavy with meaning. Nobody should be forced (trickery or manipulation included) to carry out a task that goes against their well-being.
Conclusion
This declaration of the rights of clients and devs is not revolutionary. It supports and reinforces what is already to be found in the manifesto. But its different angle of attack sheds a better light on the relationship that clients and dev teams should have. It was written with that intention: « réparer la fracture entre l'entreprise et les développeurs ».
