ADD (Accountability Driven Development) - The Original Software Development Driver
Hi Andrew.
Lately the Agile community has been inundated with acronyms and abbreviations describing what should be driving software development or design. First it was TDD (Test Driven Development), then FDD (Feature Driven Development) and BDD (Behavior Driven Design). My favorite is ATDD for Acceptance Test Driven Development which I learned from Richard Watt at Thoughtworks. Most recently Alistair Cockburn has introduced us to XXD, pronounced Dos Equis Driven, for eXecutable eXample Driven Design.
I really don't get annoyed by these variations on a theme as I learn something from each one of them. I just hope that they don't create confusion for those that are trying to embrace Agile in their organizations or cause schisms within the Agile community. But what is yet to be acknowledged is the granddaddy of them all, a driving principle of software development that has been around for decades and continues to drive software development in many organizations today: ADD or Accountability Driven Development.
With ADD, you make sure you have someone to be held accountable during each phase of the software development process. You get someone to be accountable for getting the requirements right from the start. And then you have someone who is held accountable for getting the architecture of the software right before development begins. Accountability is then thrust upon the Project Manager and developers for delivery of the software and eventually onto QA for testing it. I call this Role Based Accountability.
Tell me Andrew, doesn't it seem like a reasonable thing to hold people accountable for getting their job done? Actually son, Role Based Accountability isn't a reasonable thing at all. Let me explain.
First of all, Role Based Accountability is based on the mistaken notion that specialization of skills is a good thing, that somehow it makes the process more efficient. Agile software development has learned from Lean Manufacturing and from the Theory of Constraints that specialization does not improve quality or time to market or even profitability. Specialization leads to Local Optimization which creates unnecessary bottlenecks within the system. Global Optimization or Systemic Thinking should be the goal. (We have already talked quite a bit about Local Optimization so I won't go into more detail here. I will direct you back to Eli Goldratt's book The Goal or Peter Senge's The Fifth Discipline if you need a refresher on the subject.)
Secondly, Role Based Accountability makes people hesitant on moving the development process along. For example, Business Sponsors will want to spend weeks reviewing a requirements document before approving it to make sure that every possible feature they may want is included in the document. Software Architects will want to research new technologies and design architectures for the application before they let developers proceed with development. QA will not want to start testing until the software is at a 'code complete' state.
Third, Role Based Accountability tends to create 'contracts' between Roles, the kind of contracts that are designed to protect an organization from a self serving vendor or a vendor from scope creep from its customer. The contracts between customer and vendor are understandable as the two organizations typically don't have the same goals. But within an organization, having a Functional Requirements Document as a contract between the business and IT often does not foster a trusted relationship between business and IT and it definitely does not promote development optimization.
Finally, Accountability Driven Development is often not about getting software into production but about making sure that there is someone to be held accountable in the case of failure, someone that is either downstream from you in the development process or below you in the org chart. Read Machiavelli's The Prince and you will see this medieval principle that is applied throughout business today.
All too often IT projects are not organized around getting quality software quickly into production that adds value to their customer. Even as organizations try to adopt Agile principles I see them getting too fixated on defining Roles within the Agile process. Agile is not about Roles and creating a process around these Roles. Agile is about maximizing throughput – the right requirements to code as fast as possible. Therefore, any Role that gets between the customer and the developer will diminish your throughput.
Lately the Agile community has been inundated with acronyms and abbreviations describing what should be driving software development or design. First it was TDD (Test Driven Development), then FDD (Feature Driven Development) and BDD (Behavior Driven Design). My favorite is ATDD for Acceptance Test Driven Development which I learned from Richard Watt at Thoughtworks. Most recently Alistair Cockburn has introduced us to XXD, pronounced Dos Equis Driven, for eXecutable eXample Driven Design.
I really don't get annoyed by these variations on a theme as I learn something from each one of them. I just hope that they don't create confusion for those that are trying to embrace Agile in their organizations or cause schisms within the Agile community. But what is yet to be acknowledged is the granddaddy of them all, a driving principle of software development that has been around for decades and continues to drive software development in many organizations today: ADD or Accountability Driven Development.
With ADD, you make sure you have someone to be held accountable during each phase of the software development process. You get someone to be accountable for getting the requirements right from the start. And then you have someone who is held accountable for getting the architecture of the software right before development begins. Accountability is then thrust upon the Project Manager and developers for delivery of the software and eventually onto QA for testing it. I call this Role Based Accountability.
Tell me Andrew, doesn't it seem like a reasonable thing to hold people accountable for getting their job done? Actually son, Role Based Accountability isn't a reasonable thing at all. Let me explain.
First of all, Role Based Accountability is based on the mistaken notion that specialization of skills is a good thing, that somehow it makes the process more efficient. Agile software development has learned from Lean Manufacturing and from the Theory of Constraints that specialization does not improve quality or time to market or even profitability. Specialization leads to Local Optimization which creates unnecessary bottlenecks within the system. Global Optimization or Systemic Thinking should be the goal. (We have already talked quite a bit about Local Optimization so I won't go into more detail here. I will direct you back to Eli Goldratt's book The Goal or Peter Senge's The Fifth Discipline if you need a refresher on the subject.)
Secondly, Role Based Accountability makes people hesitant on moving the development process along. For example, Business Sponsors will want to spend weeks reviewing a requirements document before approving it to make sure that every possible feature they may want is included in the document. Software Architects will want to research new technologies and design architectures for the application before they let developers proceed with development. QA will not want to start testing until the software is at a 'code complete' state.
Third, Role Based Accountability tends to create 'contracts' between Roles, the kind of contracts that are designed to protect an organization from a self serving vendor or a vendor from scope creep from its customer. The contracts between customer and vendor are understandable as the two organizations typically don't have the same goals. But within an organization, having a Functional Requirements Document as a contract between the business and IT often does not foster a trusted relationship between business and IT and it definitely does not promote development optimization.
Finally, Accountability Driven Development is often not about getting software into production but about making sure that there is someone to be held accountable in the case of failure, someone that is either downstream from you in the development process or below you in the org chart. Read Machiavelli's The Prince and you will see this medieval principle that is applied throughout business today.
All too often IT projects are not organized around getting quality software quickly into production that adds value to their customer. Even as organizations try to adopt Agile principles I see them getting too fixated on defining Roles within the Agile process. Agile is not about Roles and creating a process around these Roles. Agile is about maximizing throughput – the right requirements to code as fast as possible. Therefore, any Role that gets between the customer and the developer will diminish your throughput.
posted by Tom Looy, Tacit Knowledge PM at 2:18 PM
33 comments
