– Back to the Agile Practice Guide (all) –

The Agile 12 Clarifying Principles

These are the principles that dig deeper into the Agile Manifesto and mindset. Check out the video and article below to see if your team truly follows the Agile concepts in the way that is right for you.

We’ve already had a look at the Agile manifesto and mindset where we value the items on the left:

• Individuals and interactions
• Working software
• Customer collaboration
• Responding to change

…more than the items on the right, which are your typical linear methods or waterfall approach. Now we’re delving into it in a little bit more detail using the Agile 12 clarifying principles. When we’re delivering in an Agile way of course you know we’re using iterations where we’ve got time boxed work of between two to four weeks and we’re often delivering an increment to the customer, which is a “feature” that they can see, feel and touch, just to make sure that everything is on track, that they understand what’s being delivered and that the requirements are fit for purpose. So number one is:

1. Our highest priority is to satisfy the customers through early and continuous delivery of valuable software.

And that’s done through that iterative and incremental approach that we will be looking at in this series. You’ve got iterations of between two to four weeks where we’re putting all that feedback back into the product and we’re getting that feedback from the customer. And increments, where we’re delivering a feature so that the customer can just tell for themselves whether the requirements are fit for purpose.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

In some cases in a Waterfall approach you may have the scope all upfront and then develop something over a period of a year before delivery but what we actually
want in an Agile approach is to get regular feedback using iterations, and then we want to make changes to the product if necessary along the way.

The reason for this is it’s much more expensive if we’ve just delivered something in one big bang at the end to make those changes, to go back into the code and retest, and to get everyone back on board. It’s much more expensive to do that than it is to just change and adjust along the way. So not only is it good for us as the project management team or the Agile development team, it’s also good for the customer because we are ensuring that they’re getting what they want.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with the preference to the shorter timescale.

Again this is where the iterations come in, of between two to four weeks where we’re delivering something to our customer but they can see, feel and touch it.

4. Business people and the developers must work together daily throughout the project.

This is where the Whole Team Approach comes into it where, we’ve got people from the
the Product Owner who usually represents the business or the customer, and then we’ve got developers, we’ve got testers, we’ve got designers, anyone who needs to be in this
cross-functional team they’re all in the one place and they can actually work together daily. They can easily communicate because they’re all in the same team and they’re not having to go across silos or organizational structures it’s all in the one place. That’s really important and they can work together daily because of that.

5. Build projects around motivated individuals and we give them the environment and the support they need, and trust them to get the job done.

Using that Agile environment, the whole team approach and making sure we’ve got daily stand-ups to remove blockers and solve our problems if we have them. Using visual management in the Kanban board, just so that we can see where everything is up to and everyone’s on the same page. Once we have that supportive environment then we if we have the right individuals on board we just 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.

A lot of communication is not just verbal, or not just in the words themselves – we’ve got things like our body language, we’ve got things like verbal intonation, all of these contribute to the communication. But not only that when we’re standing face to face it’s much easier to get a response quickly than it is when you’re sending an email or if you’re having to pick up the phone and call someone. So now this is very fast and we’re getting information quickly as opposed to having to pick up the phone  or sending that email which could take a lot longer and it definitely delays the progress that we’re making.

7. Working software is the primary measure of progress.

This is where we’re measuring and delivering in an Agile way, you’ll see a burn down chart or a burn up chart, and this is where we can actually see the progress as it relates to the working software in the increments that we are delivering. And those increments have been checked by the customer using the demonstrations or reviews, where we demonstrate at the end of the iterations of around two to four weeks. So it’s regular feedback.

The customers are getting that regular input into what’s being developed and we can
clearly see that working software becoming more and more whole as time goes on using the agile methods of measuring progress.

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

This means the sponsors, developers and users should be able to maintain a constant pace indefinitely and this also means we’re not burning the midnight oil – we’re not
working 24 hours, staying up late, we’re not going in peaks and troughs. We’re really wanting to maintain a steady pace whatever that pace is. We do this so that people
don’t get burnt out, don’t have to take leave or stress leave. We want that pace of work to be able to be sustained indefinitely.

9. Continuous attention to technical excellence and good design enhances quality.

This can be with the design practices of the team, or it could be the development practices of your team – how often you refactor the code for example. How often do you simplify the practices that you’re using as a team?

10. Simplicity – the art of maximizing the amount of work not done – is essential.

Let’s say you have 10,000 reports that need to be sent up the line. Is that really the best approach? Or can you just invite one of those stakeholders to your daily stand-up or one of those feature reviews that you do at the end of an iteration. There are definitely different ways of communicating and you know that’s not the only thing that can be simplified. Looking at everything that can be simplified is very important and maximizing the art of work not done.

11. The best architectures, requirements and designs emerge from self-organizing teams.

Once we’ve got the structure in place, and the habits in place to support a team, the best teams are actually self-organizing and also cross functional. With cross-functional you’ll see more about it in the whole team approach where we’ve got everyone within the one team who needs to be there, and you don’t have to go elsewhere or need to look elsewhere in the organization (or external to the organization) to get what you need. The teams that come together naturally are often the best ones.

12. At regular intervals the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

This is seen in the retrospective. A retrospective is at the end of our iteration of two to four weeks where we say what went well, what didn’t go well, what have I learned and what still puzzles me. And by asking those questions as a team, being anonymous if we have to in order to get really true and honest feedback and then putting that feedback back into the approach that we’re using to develop or create or project manage. We’re actually continuously improving and we’re improving the way that we work on a regular basis.

And those are the Agile twelve clarifying principles.

– By David McLachlan

– Back to the Agile Practice Guide (all) –

Get the Leadership Card Deck or the Five Minute Lean Book:

View All The Leadership Cards (48)

- or - Have the Leadership Cards delivered for your next meeting

 

Want to learn about Lean? Get the book "Five Minute Lean", by David McLachlan - a wonderful book that blends teaching of the tools, culture and philosophy of traditional Lean with a modern-day Lean parable. You can get the whole book on Amazon here and enjoy your own copy.