Agile Prouct Development... How to manage Requirements?
25/09/06 00:24
It has been a while since my last post, I have been a bit busy in real projects... Particularly a topic which seems to be very hot is how to concile "Agile Development Principles" with "Product Management and Development" where:
Agile Development Principles: "Among the most important principle of agile development there are the need to have a customer playing an active role into the product development, the fact that changes of requirements or change requests are mostly welcome at any time and that for many of the agile practices any written documentation should be limited to the minimum and verbal communication should be preferred". (Agile Manifesto)
and:
Product Management and Development: "It is the set of practices that aims to define, plan, implement, support and promote a product - or a line or family of products - to the market. In the general conception of the product, it should be the response to a need present on the market, and the interpretation of a specific company on how to solve the identified target needs". (Wikipedia)
There are indeed some questions that should be answered and leveraged in order to make it possible to adopt and Agile approach into a industrial - or even not - product development environment. Without involving specific quality standard or regulation issue (such as traceability from requirement to code through tests whenever "safety" or "security" concerns are implied, as for FDA and GxP, or even CMM-* in some specific environments) there are some key issue to address, in particular:
• The product development targets a specific set of "needs" belonging to a market, rather than to a single customer, therefore it is impossible to involve all the potential customers into the product development. As suggested - see also the post in the newsgroup - from and agile perspective it would make sense to have a Customer Proxy that act as a collector of information from the market and a single point of contact for the development. It is anyway not so easy to be "agile" in the respect of the customer, and to use as much as possible the "agile" successful principle to share results and participate to the success with the customer. This is no trivial problem, and is not only an organization issue, the value of agile is into people - motivation and commitment - my experience is that people involved with the customer are motivated and share with him experience, this improve the final result and the customer satisfaction. In a scenario with a Customer Proxy this advantage is nearly lost...
For treacability reasons it is mandatory to have Requirements written, and versioned, it often happens that while requirement are implemented, somebody else is changing them under the hood, with an Agile approach this is mostly welcome, and should be merged directly into the project, but in the end it is all a matter of complexity, and above a certain level it is not acceptable to initiate changes which are not synchronized and regulated between teams or even between people working in the same team. There is the risk that some changes will result in mulfunctioning sub-systems, that even with the Parachute of Unit Testing (TDD is a very effective practice of XP) can result in huge refacoring costs.
It is nothing more than common-sense to understand that with growing complexity, more infrastructure and rules are needed, and not all the Agile principles (at least as stated - I believe that a principle is always valid for itself, for what it represent, and that its applicability may vary from one situation to the next) are always adoptable. A good example of a scalable approach in this respect are the Christal Methodologies developed by Alistair Cockburn in the early '90.
I am working now on a possible Scrum (I believe that Scrum is the most Agile way to manage a project, is a complementar practice to XP and can incorporate Requirement Management techniques to correctly feed development teams) approach to Requirement Management, that should fullfil the following requirements:
Agile Development Principles: "Among the most important principle of agile development there are the need to have a customer playing an active role into the product development, the fact that changes of requirements or change requests are mostly welcome at any time and that for many of the agile practices any written documentation should be limited to the minimum and verbal communication should be preferred". (Agile Manifesto)
and:
Product Management and Development: "It is the set of practices that aims to define, plan, implement, support and promote a product - or a line or family of products - to the market. In the general conception of the product, it should be the response to a need present on the market, and the interpretation of a specific company on how to solve the identified target needs". (Wikipedia)
There are indeed some questions that should be answered and leveraged in order to make it possible to adopt and Agile approach into a industrial - or even not - product development environment. Without involving specific quality standard or regulation issue (such as traceability from requirement to code through tests whenever "safety" or "security" concerns are implied, as for FDA and GxP, or even CMM-* in some specific environments) there are some key issue to address, in particular:
• The product development targets a specific set of "needs" belonging to a market, rather than to a single customer, therefore it is impossible to involve all the potential customers into the product development. As suggested - see also the post in the newsgroup - from and agile perspective it would make sense to have a Customer Proxy that act as a collector of information from the market and a single point of contact for the development. It is anyway not so easy to be "agile" in the respect of the customer, and to use as much as possible the "agile" successful principle to share results and participate to the success with the customer. This is no trivial problem, and is not only an organization issue, the value of agile is into people - motivation and commitment - my experience is that people involved with the customer are motivated and share with him experience, this improve the final result and the customer satisfaction. In a scenario with a Customer Proxy this advantage is nearly lost...
- The "Product" is an asset for the company who is building it, in software this asset is mostly "untouchable" and - fortunately - not protected by any Patent (at least in Europe) therefore its values is in the knowledge that developers and analysts put inside the software itself. This asset has to be protected, and in a real product development scenarios it has to be kept safe. The Agile approach - sometimes extreme ;-) - is that documentation (including requirements) has to be kept to the minimum, and the Code is self-explanatory. Of course this is a provocation, but on the other side to find compromises between the need to have "Requirements" - easy to understand, realistic and achievable descriptions of what the needs are, and how to measure their achievement, and trace their orign and what has been generated out of them - of product development, and the need to limit as much as possible the written documentation is not so easy...
For treacability reasons it is mandatory to have Requirements written, and versioned, it often happens that while requirement are implemented, somebody else is changing them under the hood, with an Agile approach this is mostly welcome, and should be merged directly into the project, but in the end it is all a matter of complexity, and above a certain level it is not acceptable to initiate changes which are not synchronized and regulated between teams or even between people working in the same team. There is the risk that some changes will result in mulfunctioning sub-systems, that even with the Parachute of Unit Testing (TDD is a very effective practice of XP) can result in huge refacoring costs.
It is nothing more than common-sense to understand that with growing complexity, more infrastructure and rules are needed, and not all the Agile principles (at least as stated - I believe that a principle is always valid for itself, for what it represent, and that its applicability may vary from one situation to the next) are always adoptable. A good example of a scalable approach in this respect are the Christal Methodologies developed by Alistair Cockburn in the early '90.
I am working now on a possible Scrum (I believe that Scrum is the most Agile way to manage a project, is a complementar practice to XP and can incorporate Requirement Management techniques to correctly feed development teams) approach to Requirement Management, that should fullfil the following requirements:
- Respect Scrum approach to be highly reactive to changes;
- Support Product Release Planning needs from Product Management and Marketing;
- Synchronizes requests for various product subteams, or components teams;
- Support traceability to source code and tests (coverage, results, acceptance)