This is the third of 12 posts about the principles of agile software development. Purpose is to go back to the start of the agile manifesto (http://agilemanifesto.org/principles.html) and discuss the implementation of the 12 principles in real life software engineering. Goals of agility are to go deliver software of higher quality, faster, with a higher acceptance to end-users and able to follow the changing business requirements to strive for competitive advantage.
The question is: is this going to work in practice or is this only based on a nice marketing and sales story.
Principle 3: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Old school linear development methods rely upon the assumption that an extensive specifications and design phase upfront will resolve all uncertainties and specify of all possible functionality in depth. After the design phase the development team retreat to their software factory to deliver the desired software in one big bang (in many cases many months or even more than a year later).
The result of this linear approach is a system; of witch the customer thought a year ago, he would need it in a year. As if the team could stop time to await the delivery of this system. Changes in environment and renewed insights are not incorporated in the end-product.
Besides this shortcoming there is a human drawback to this linear approach; the stakeholders of the new to-be-developed system (customers, management and of course the end-users) are not involved anymore with this system after one year. The systems purpose, functionality and design decisions are not on the top of their minds anymore. This makes delivery, acceptance and implementation of this system hard (or even impossible).
The reduced acceptance and the “off-sync” with reality are small drawbacks. Within a long development period the developers have enough time to create their own interpretation of functionality. This creates an opportunity for fundamental functional flaws in the software to be developed. This is a serious problem because the first moment this emerges is the feedback from the functional acceptance test after delivery of the whole system. At this time there is probably not much budget to resolve these problems.
To summarize of the drawbacks of linear development:
- the delivered system is not in sync with current reality;* by the time the system is delivered the stakeholders are less (or even not) involved in the delivered system;
- new insights in functionality or technical solutions are not met / implemented in the delivered system;
- during the development process there is enough time for personal interpretation of the developers and feedback is only given at the end of the project.
What issues will be resolved by using frequent delivery of software? Below you will find the advantages of frequent delivery.
Frequent feedback and sooner review moments.
Frequent delivery of working software will enable the stakeholders (e.g. end-users) to deliver their feedback and review on (a part of the) product sooner. Things in the design that remained unclear or where misinterpreted by the developers emerge at such review moments. This enables the whole project to adjust their interpretation of the design soon and keep the design aligned with the intention of the stakeholders. These frequent review moments can also be used by the development team to verify a certain solution with the stakeholders (with e.g. a prototype) before spending a lot of time on implementing it completely.
Acceptance and ownership of the product
Frequent delivery of working software will also keep the stakeholders involved in the development process. The end-users will have frequent moments to deliver their input on parts of the new system and are noticing their input to be incorporated in the next version. This approach will create a cooperative ownership of the proposed end-product that will facilitate acceptance and ownership of the delivered product.
Quick evaluation of usability
In case of an application with a Graphical User Interface the first version will most probably contain some screens. This is a great opportunity for the development team to ask the end-users their feedback on the usability of the screens. Changes in usability or look and feel are still easy to apply since there are little screens implemented. The second advantage of this frequent delivery is that the end-users are already used to the look and feel. They will not be surprised when presented the final system because they have seen it dozen of times. They have used and tested the system many times and are able to start working with the system right away. So this will reduce the need for training these users also.
Alignment with changing environment
Frequent delivery will enable the development team to keep the end product aligned with the changes in the environment. During the development period there are many factors influencing the environment of the project. Below some examples:
* Business; the business requirements can change during development period. Business strategy or competitive circumstances can require changes to the new system drastically.
* Technological. Technological changes in the environment can have effect on the new system. Changes in interfacing systems, new technological possibilities, changes in the operating or supporting platform can have a significant impact on the system.
* Organization as itself can have effect on the system to be delivered. Organizational changes or, even more drastic, mergers and takeovers can cause the need to changes the requirements of the system.
* Outside factors. In most cases these factors are changes in regulations and laws that require functionality or certain registration. These changes can be of significant effect on the end product.
With frequent delivery of working software there are frequent moments to test if the developed system is still aligned with the environment. You have to welcome these changes and handle these as proper change requests. In most cases you can incorporate these changes in the rest of the project scope or by dropping some other requirements. (see the “welcome change blog” https://technology.amis.nl/blog/2377).
Ease of deployment
One of the surprises you do not want to experience in your project is “The system cannot deploy on the intended system”. In worst-case, with linear development, you discover this after you completed the whole construction phase of your project. In this phase the project is often under high pressure and it does not look good when deployment is experiencing a lot of difficulties. .
Frequent delivery of working software, preferably on a representative environment at the customer’s site, will overcome this problem. By the time you deliver the complete version of the end-product deployment has been done many, many times. With this approach deployment of the complete version of the end-product is no problem anymore. Another advantage is that the system-operators responsible for the deployment are trained in deploying your product. The deployment manual is tested over and over and the employees have hands-on experience in deploying your application. This makes the transition to the maintenance phase of the application easier or even seamless.
Conclusion:
So, frequent delivery of working software will have profound advantages. Not only in the quality of the systems functionality but also in the acceptance of the end-product by the stakeholders. It will keep the project aligned with the environment and business needs and the stakeholders involved. Frequent delivery has also a communicative advantage. It will keep the stakeholders involved with the project and shows that the project is moving forward.
Other posts about the AGILE Principles (soon to come):
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity–the art of maximizing the amount of work not done–is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
And yet there is another principle to pay attention to in agile development: YAGNI (You Aren’t Going to Need It). You cannot start with a normalized, well-designed database from an overall perspective because you typically do not know, in the beginning, what the requirements are going to be. You have a set of things from the backlog you are going to work on and you can peek into the future to see what else MIGHT come down the pipe, but outside of that, it is irresponsible to spend time now to develop things that have not yet established themselves as requirements. So you build what makes sense now. And you do that *well* — which may mean a normalized, well-designed database for what you know now. But the odds are you will need to revisit it throughout the development of the product because new things will come up and no design can withstand the onslaught of changing requirements and new feature requests.
John, you are right. Working agile with frequent delivery of working software does not mean you do not have to think about the fundamental design. You have to wait for my blog #9 Continuous attention to technical excellence and good design enhances agility.
But implementing the complete correct functionality in the first iteration is hardly possible. It is better to strive at a 80% implementation of the functionality in the first delivery and converging tot final desired solution in the next deliveries. Working this way you will notice that the end-users will begin using the system before all alternative scenarios are implemented. This means that the database design will also be completed for a large part (e.g. 80%) in the first delivery and converges to the final model in the next iterations.
Change happens. Change is good. But, it is VERY important to put the project on a firm foundation that readily accommodates change. To me, that has to begin with a normalized, well-designed database. This cannot be created with a short-term view of just the next delivery – it must take into account the direction of future pieces of the project.
For instance, in a purchase request there are line items for the various articles being requested, but they are all part of the same request. Looking at the delivery of a sub-system to send the request through its various approvals and ending at the purchasing office, you might design this as a single purchase request object with multiple line items. But when designing the database, you must consider that the purchasing office may now want to combine items from this request with items from other requests and create several purchase orders to various suppliers. When the items arrive, they need to be distributed back to the original requesters. Obviously, purchase request line items need to be considered as separate entities so that they can be placed in a many to many relationship with order line items. You might not discover this if you are looking at the request process by itself.