(From “Extreme Programming Installed” Addison-Wesley, 2001) 1 You have the right to know what is needed, with clear declarations of priority. 2 You have the right to produce quality work at all times. 3 You have the right to ask for and receive help from peers, superiors, and customers. 4 You have the right to make and update your own estimates. 5 You have the right to accept your responsibilities instead of having them assigned to you. ...
(From “Extreme Programming Installed” Addison-Wesley, 2001) 1 You have the right to an overall plan and to know what can be accomplished when and at what cost. 2 You have the right to get the most possible value out of every week. 3 You have the right to see progress in a running system, proven to work by passing repeatable tests that you specify. 4 You have the right to change your mind, to substitute functionality, and to change priorities without paying exorbitant costs. ...
Kent Beck said the goal of agile software development is to heal the divide between the business and development, and he was right! The Bill of Rights - created by Kent, Ward Cunningham, Ron Jeffries, and others — defines complementary expectations: the customer’s rights and the builder’s rights. When both sides know their rights and honor the other’s, collaboration replaces conflict. The customer has the right to a plan, to see progress, and to change priorities. Builders have the right to know what’s needed, to produce quality work, and to ask for help. These aren’t rules, they’re agreements that create balance and trust. ...
Things move fast, if you stop learning, the product and the team will fall behind. Find ways to grow: When the company can afford look for suitable, high ROI courses, books, and conferences. And teach what you learn. Teaching cements knowledge and spreads it across the team. Make knowledge sharing part of the workflow so new people ramp quickly and everyone improves together. The “Whole Team” practice supports this type of thinking: continuous learning and teaching are core to a resilient, adaptive team. ...
I’ve joined teams that have a pervasive team culture of always saying “yes” when asked about the feasibility of the schedule, even when the real answer is “no”. As a professional, it’s our duty to say “no” when something can’t be done. We aren’t only hired to deliver, we’re also here to surface technical reality. As builders, we are the ones who know whether an approach is feasible or not, and if it can be completed within the allocated timeframe and budget; when it’s not, it’s vital that we speak up, even when under schedule pressure. ...