Image courtesy of publicdomainpictures.net
This week’s blog post is based on a chapter from our book, Scrum 101: the most frequently asked questions about Agile with Scrum, which is available to buy for £9.90.
There are twelve principles behind the Agile Manifesto (Beck et al., 2001). Here they are with an example of why they might be beneficial.
“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
“Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”
Both of these principles allow product teams to get feedback, and to start to get a return on investment, as early as possible.
“Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”
If the world changes, our original plan may no longer be the best option. Therefore, we need to be able to change direction. By enabling this flexibility, our customers can get ahead of their rivals!
“Business people and developers must work together daily throughout the project”
We should not be defining the whole product upfront; together with the business, we should create a vision of where we want to go, then work collaboratively with the customer to deliver what is best. This allows a speedy change of direction if necessary.
“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”
Don’t communicate by sending emails when you can talk to someone in person; it is rarely as effective.
“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”
“The best architectures, requirements, and designs emerge from self-organizing teams.”
Giving the team autonomy is better than micro-management. Decisions are made for the team, by the team: they are self-organising. The team knows how best to achieve the vision.
“Working software is the primary measure of progress.”
If you want to know if something is done, look at whether it is working in production. End users don’t care how close to going live something is: if they can’t use it, it has no business value – not even if it is 99% finished.
“Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”
Maintaining a steady output of small, releasable features is not only a more maintainable working approach, but also helps you forecast when features might go live. Erratic, pressurised working practices are not only unpleasant, they make planning very difficult.
“Continuous attention to technical excellence and good design enhances agility.”
If you cut corners, it will come back to bite you later. For example, if you create a poor foundation of code, then all future work building on top of this code will take longer.
“Simplicity–the art of maximizing the amount of work not done–is essential.”
Do what is requested to fulfil the goal, then get it live. This does not mean cutting corners, it means not over-working it (also known as ‘gold-plating’).
“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.”
We can all improve. Even if you think you are working really well, there is always room for more improvement. Just look at Formula 1 teams. Review … change … monitor … review … change … monitor … and so on.