Introduction

What is a Development Model and why do you need one? And is it just another term overlaid on the Agile Methodology and does little to add to its understanding? The purpose of this term is to indicate that user stories are derived from the natural decomposition of a product into small vertical packages of functionality.

For example: An Account Management feature may be composed of:

• Account Creation – Registering and creating the account
• Retrieval – Retrieving and using the account.
• Update – Editing and modifying the account
• Deletion – Removing the account

Each of these capabilities are operations that the user needs to perform in order to manage an individual account. And each of these “units of functionality” slice through the layers in the system architecture:

• There is a UI component to Account creation.
• There is a middle ware/server side component to account creation.
• There is a data storage component to account creation.

In other words each user story that composes account management has functionality in the presentation layer, in the middleware layer and in the data storage layer. And once these user stories are determined, they can then be scheduled, monitored and evaluated in the development lifecycle.

The term development model attempts to reflect the process of discovering user stories in the product such that they can be implemented iteratively.

Without decomposing the system into user stories, developing the system becomes more difficult. Also system decomposition promotes looking at these user stories, grouping them into features and seeing how they makeup functionality of the system as a whole. A good development model is derived from the architecture, the domain model and the functionality of the system. Once the development model or any part of it is determined, it can be scheduled and developed.

Project Model

The diagram illustrates one way of mapping the product model to a project. Each feature and its user stories are mapped to users stories within the project. Once this mapping occurs, the level of effort, the timeframe, the resources, the tools required to build and track the project can be put into place. 

Conclusion

The purpose of discovering or making a Development Model of the system or the product is to discover a set of user stories (functional components) that can be developed, tested, integrated and deployed. The development model also implies that the way to build the system is to start from user stories and iterate over each of them to develop the functionality of the user story. By its very nature this approach is piecemeal growth and is an evolutionary approach to building a software product. It is noteworthy that this approach does not involve a SCRUM Master going in search of user stories and artificially classifying system behavior into one user story or another. Instead, the user story discovered in the product are used to inform Agile frameworks like SCRUM, on how to create backlogs, Agile boards, Agile cards, and how to track the progress of the product being built.

This development model needs to be discovered by interacting with the product right from its inception. The worst thing for an Agile process would be for an “architectural committee” to sit in a room and come up with a development model without any interaction with the product being built. In an Agile approach, system behavior, even well known ones, must be designed and developed iteratively. Any model that is not validated is theoretical and may or may not be implementable. In the Agile approach the focus is on designs that are implementable. Otherwise the Agile process breaks down and becomes rigid, brittle, hierarchical and dogmatic and therefore no longer Agile.

The effort involved in discovering the natural composition of a system and using that as a starting point is the foundation upon which the iterative development of the product is built.

Ideate Iterate Innovate