Thursday, April 4, 2013

Why Design is Critical with Agile?


Summary:
One of my observation to software development with Agile process is that design of the product is not addressed far enough. Often, the team collects user stories and then assigns them to developers. The design of the product is mostly up to the developers. How to assure the team sharing a vision of the product and all work towards that vision? In this post I would like to reiterate the importance of design.


I see many "Agile" projects fall into “quick and dirty” track - the structure of the products are not consolidated. They work, but when you look at the inside, you don't see a good design. After a transition from Waterfall to Agile, we seem to have moved too far from one end - a fully prescriptive approach to the other end - a mostly pragmatic approach. To enforce the quality of the product, we need to address design efforts in the development process. Agile has no intention to eliminate design efforts, but to have design in an iterative manner, instead of BDUF, and to have it light weighted or as needed. In essense, a design serves as the team's agreement and it forces integrity for the product/solution. Actually, Scrum contains refactor stages that are not only to keep the code dry, but also to align with the design. Why I address design? Because design is the only thing that can align the development to the goal of the product to be developed.

Any product has to be designed, because any product has a goal and there are many ways to achieve it. Design is to identify and choose, or to innovate, if not yet a thing is available to choose. Design is to find the “simplest” solution for the product. Leonardo Da Vinci put: “Simplicity is the ultimate sophistication”. Biochemistry Michael Behe coined a term “irreducible complexity” when he had examined creatures in the world and their evolution.  After all, design is absolutely essential for working out a great product.

However, design in Agile development is a quite different process – it evolves along the product development instead of a final version being completed before the construction start. It is hard to imagine that we conduct design-development iterations while we are building a bridge and many other things. An exclusive aspect of software development is that we can adapt what we have developed to requirement changes and design changes in the development process while in a much easier and less costly way comparing to that with a bridge project, for example.

While pursuing “agility” – fast adaptation to requirement changes, with Agile process the team must enforce design which serves as a vision of the product and an agreement among the team. In this regard, choosing a development framework, such as MVC, does simplify design effort by providing standard architecture for an application. However, since they are general frameworks, they don't cover application specific problems, such as the design for the business logic layers, for example.

Hence, in Agile design has to be a process which runs side by side with the development process, to direct the development and refactoring iterations. When development is completed, the final design artefacts become part of the product deliverables, and the stakeholders would like to have it for training or future product enhancement.

No comments: