The Agile Manifesto is a collection of 12 principles that were defined to address the challenges faced by software developers. I have been using these principles to manage software builds for a number of years. Here I draw on my experience to offer my thoughts on each one.
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
This is fairly obvious. It should be the aim of any software team whether they are using Agile or not, to deliver the required product. The key word for me is ‘continuous’, which could be interpreted as regular.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Many development teams are scared of change. They have definitions such as ‘feature creep’ and ‘technical debt’ which are used to discourage changing the scope of work. Agile actively encourages change. There is an understanding that this change becomes part of a prioritised stack of work. This stack can be manipulated and re-prioritised over time to suit the business or client need.
Sometimes it is difficult to listen to people changing their minds. If you have the appropriate relationship and understanding, these changes make sense. It is better to change the product so that it delivers something usable, than be blinkered and deliver a fantastic feature that is no longer fit for purpose.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Maintaining quick delivery means that stakeholders can see change and improvement. They can see the momentum of delivery that Agile brings. It also means that the business can contribute more readily to the features they are requesting. There is no 6 month wait for the build of a feature that doesn’t function as expected or is no longer required.
In our team we generally work in sprints of 2 weeks. In our case this is not strict. If a member of the team is away from the office on our next planning day, we sometimes add an extra day to the current sprint.
4. Business people and developers must work together daily throughout the project.
A project must always deliver what the business needs. Without effective interaction between the people who understand the business and the people who understand software development, the project will never deliver results.
In my experience, business people have very little idea what is possible and equally what isn’t possible in software development. They also don’t grasp the complexities involved in achieving reliable, usable software. The best relationships between the two parties are formed when there is a mutual respect. If the business knows that the team will give it their all to create functionality aligned to requirements, the business will listen to and trust the developers.