A question was asked in the LinkedIn Agile Project Management group “If you were to be given an opportunity to add one more line to the Agile Manifesto, what would it be?”
My answer is: “We value discipline over bureaucracy”
I have a saying: “You need to know the difference between discipline and bureaucracy”. A critical success factor in Lean and Agile is maintaining a high degree of discipline, while actively eliminating bureaucracy through continuous improvement.
Scott Ambler’s Writings on Disciplined Agile
In an Agile CMMMI LinkedIn group discussion on “How disciplined is your Agile implementation?”, Scott Ambler pointed out he had written an article on “Discipline vs Bureaucracy” in Agile several years ago:
- Bureaucracy Isn’t Discipline - in IBM Developer Works
Scott describes “Discipline over Bureaucracy” far better than I could… it’s well worth reading his material on the topic.
Also Scott has a web site Disciplined Agile Delivery dedicated to improving discipline in Agile development practices. The web site is a companion to Scott’s book of the same name Disciplined Agile Delivery
Scott has a written a wealth of material on the importance of discipline in Agile development - his book and web site are a great resource on Discipline in Agile development.
Read on for more details….
I believe this is the starting point for many deep discussions about Agile and Lean.
An common misconception is that Agile is an unstructured, “ready, fire, aim”, “make it up as you go” practice. This lack of discipline is often a cause of poorly executed Agile projects, especially for organizations adopting Agile. Agile teams must be highly disciplined to be effective.
One could argue that driving out bureaucracy while maintaining disciplne is a key principle of Lean, and of Continuous Improvement. Let’s define the terms in this context:
- A process, practice, or paperwork which purports to add to the effectiveness of achieving a result, or to promoting continuous improvement, which actually adds more work and cost than it saves. (i.e. Its ineffective.. its subtracts value in an ill-guided attempt to add it.) Discipline
- The ability to faithfully follow a practice or process which has been proven to be effective in achieving a result, and/or to promoting continuous improvement (i.e. A “good habit” which adds value)
Now what do we mean here by “value” and “adding value”? It boils down to two things:
- Value to the customer: the practice directly contributes to a positive customer experience, based on actual evidence and feedback.
- Value to the business: the practice supports continuous improvement, and maximising effectiveness in delivering value to the customer, based on actual evidence and feedback.
The “based on actual evidence and feedback” qualifier is crucially important. After 50 years of Software Development, you would think that Software Engineeing would be a fairly mature field, with good emperical data around which practices work and which don’t. You would expect that we would be “evidence based” like other engineering disciplines - that we would conduct well-designed experiments, and collect data to test new practices and measure how they affect the software development process. But typically we don’t. All too often, we base our selection of languages, tools, methodologoes and practices based on “gut feel”, and subjective argument.
This lack of evidence-based data is the source of considerable bureaucracy on one hand, and lack of discipline on the other.
- Much bureaucracy is introduced based on the need for management to feel they have a sense of control over a project, even though the literature is rife with evidence that for design-intensive work management control is at best ineffective, and at worst produces poorer outcomes.
- Software designers have a tendancy to eschew certain disciplined practices because they are “tedious”, or “not fun”, even through there is overwhelming evidence for their effectiveness.
- My favorite example here is the careful, detailed, disciplined peer review of designs, code and test cases. i.e. “Design Reviews” and “Code Inspections” (recognziing that test cases are code)
- Software designers will adopt languages, tools, and practices because they are trendy or cool, even though there is no evidence that they actually make software development more efficient.
- A good example here is the use of pair programming to improve S/W Quality. There are good reasons for a team to adopt pair programming … to help the team members get to know each other better, to train new or less experienced developers, to ensure the knowledge of the code is spread throught the team, etc. But there is no good evidence that pair programming can be used as a replacement for code inspections, or that pair programming improves code quality.
So how do we differentiate between Discipline and Bureaucracy? It’s actually not easy. Here’s an incomplete set of questions to ask:
- Who is demanding the particular practice? What specific benefit do they claim to be getting from the practice?
- Can the specific benefit be directly tied to either Value to the Customer or Value to the Business? If not, its probably “bureaucracy” rather than discipline.
- Exactly what is the use of the output of a particular practice? Who uses it, and what do they use it for?
- If the use of the output is not clear, and it can’t be tied to either customer value or business value, its bureaucracy.
Is there strong emperical evidence that a practice improves S/W development effectivness? (e.g. Like Code Inspections, Automated Test Cases, and Continuous Integration) Then the practice is a discipline that should be followed.
- Is the cost of the practice greater than the benefit? If so, its bureaucracy. In some cases the practice needs to be streamlined to reduce its cost, in other cases it needs to be abandoned.
- This includes what I call “spending 100,000 dollars to make a 10,000 dollar decision” - a form of “analysis paralysis” where an organization spends far more time and money analysing a decision than it would cost to simply make a choice and try it out.
- Prescriptive company rules and regulations that don’t allow working level staff leeway to “do the right thing” are a great source of bureaucracy where the cost is greater then the benefit. For example, I once spent 15 hours of my time, and estimate that my company spent 1,500 dollars because of a 4 dollar discrepancy on an invoice. The order management staff were outsourced employees who had zero permission to make judgement calls in the best interest of the company. So a small $4 issue drove 6 months of endless frustrating email conversations to get the invoice paid.