Agile software development, the principles. Principle 8: Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

This is the eight 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 8 : Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely

Sustainable development means constant production of softwarefeatures during a long lasting period. This is done without loss of concentration within the team or a rising amount of errors as a result of fatigue or frustration. Software development is like running a marathon and not 100 meters sprint. You have to keep up to speed but not run so fast that you exhaust yourself or your team members.

I (and many of my colleagues) recall working on projects that start relaxed and easy (deadline is still 4 months in the future) and end up working long hours, nights and weekends fixing the project and delivering the end-result. During this period frustration rises and concentration falls. This often leads to situations where we have to fix errors made during last evening of hard working.

The amount of time and effort the team invests in a development process has to be more or less constant during the whole process. This is not only the case for the developers but also for the other team members / stakeholders like testers, designers, sponsors and users.  All these groups suffer when the pace varies a lot. During periods of little activity the focus and interest in the project / product demises and in periods of peek activity the stress and frustration reduces the accuracy needed to perform the work correctly(e.g. testing, deployment etc.).

 Having recognized this, why do so many projects keep their deliverables with them as long as possible and then (without announcement) throw their artefacts (designs, products, applications and test results) over the wall. Creating a sustainable development process requires your whole team to work together from the first day of the project. All efforts during the process need to be a team effort guided by the process-step expert (designer, developer, tester, application manager, end user etc.). As a project manager you have to prevent a waiting attitude with the team members. Examples of this undesirable attitude are:

• Senior users: “so, we have stated our requirements. Let’s see what they (the developers) come up with”
• Developers: “We have realized all features ad stated in the requirements specification. Even those requirements where that we found confusing, contradictory and wrong. We probably hear about this during the acceptance test (or not)”
• Testers: “fortunately the requirements do not state anything about usability and performance, so we do not have to do anything about this”
• Application managers: “I hope the architects do not use the single sing on option that is not supported on our platform”
• Stakeholder: “So, this project has started. I do not have to do anything and delivery will be on time and on budget”

As a project manager you have to make sure the team communicates and discusses the process and the product under construction constantly. This will enforce a common ownership about the product and the process. This way you will keep all team members and stakeholders involved in your project.

You can enforce a constant ownership of the product by requiring the project to deliver a new version every week. This requires a smooth running and well oiled build, test, delivery and deployment process. By scripting these process most of these tasks can be performed automatically. Using the correct tools it is possible to compile, deploy and deliver a new version quickly. Within our factory (using maven, continuum/Hudson, Nexus and subversion) we can deploy a new version from scratch within 5 minutes. This creates a constant state of near-shipability of your software. Your team will have a constant productivity during the whole project and not just a huge productivity during the last few weeks.

Stay Alert and creative

Constant and sustainable development enforces alertness and creativity within the team. Team members are not stressed to the maximum to deliver functionality. They are given the time to come up with a creative solution and are alert on the tings happening with other team members or in the project’s environment. This means that the team has to be focussed and aware of the pace of productivity it has to meet. On the other hand, there has to be room for free time and relaxation. This is also known as the 40-hour work week. This does not mean that you have to limit your work to 40 hours a week. When you gain extra functionality (with the same quality) in 50 hours a week you save a 1 month within a project of 5 months. You have to make sure the quality, creativity and focus does not suffer under the fatigue of the team members. Working e.g. 80 hours a week is asking for errors and sub-optimal solutions in the long rung.

Deliver what the organisation can process

To be sustainable in development the user-organisation not only has to be ready to process new version frequently. The project team needs to take into account the amount of new versions and functionality the user-organisation is able to process also. The productivity of these two groups needs to be aligned with each other. This way the development team can produce software that is immediately tested and (preferably) immediately used by the end-users without stressing the end-users with an unmanageable amount of sub-version. On the other hand the user community is able to give the development team direct feedback on the new version delivered. This way the users and developers create valuable software in a combined team.

Conclusion:

To execute your agile projects you have to make sure all stakeholders in the project are constantly aligned with each other. Make sure all stakeholders are in pace with the speed of the project and they are able to participate and absorb the deliverables from the project. Do not stress the team members in such a way that creativity and alertness suffers. During the whole project’s execution keep the effort off all stakeholders as constant as possible. Make sure that running your project is not like running a 100meter sprint but more like running a marathon.

Good Luck!!

Other posts about the AGILE Principles (soon to come):

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity–the art of maximizing the amount of work not done–is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Google