More and more organizations these days are adopting Agile ways of working. As an Agile Coach and Trainer I often meet people from these organizations who are talking about Agile-Scrum, which I think is great of course, since I’m a big fan of working Agile. However, I hear people talking about Agile-Scrum a lot, as if it’s the same thing. This is therefore the starting point of this blog, since I would like to add some clarity on the matter.

Summary

Agile Umbrella

Agile Umbrella

Agile: Agile is a mindset and it’s a set of values and principles. Agile is a way of thinking and acting. Agile is all about short cycles, iterative and incremental delivery, failing fast, getting feedback, delivering business value to customers early and about people, collaboration and interaction. Agile is a mindset which is all about transparency, inspection and adaptation. Agile however doesn’t consist of any roles, events or artifacts. It’s a mindset.

Scrum: Scrum is a lightweight framework for developing products and services in complex environments. Scrum is lightweight, which means that it only consist of 3 roles, 3 artifacts and 5 events. Scrum is pretty simple to understand, but can be pretty hard to master. Since every role, event and artifact in Scrum serves a specific purpose, it is best to implement Scrum by the book, as described in the Scrum Guide. Scrum is one of the frameworks under the Agile umbrella, which may help you in becoming more Agile, there are however many more frameworks within the Agile movement, like Kanban, XP, Crystal and many more.

What is Agile?

The Agile movement was founded in februari 2001, in the Snowbird ski resort in the mountains of Utah (USA), where seventeen people gathered to talk, ski, relax and to find a common ground for increasing the success of software development projects. The attendees at this gathering where the people who created frameworks like Extreme Programming, Scrum, DSDM, ASD, Crystal, FDD and many others. These frameworks were all created in order to increase the success of software development projects by their makers, but had no strict relationship with each other. All the frameworks or methodologies had something in common however, they were all lightweight frameworks and their creators were looking for alternatives for the heavy weight, process-based project approaches.This group of people has since then named themselves “The Agile Alliance”. During their time spend skiing, talking and having fun in the mountains of Utah, they have created the so called “Agile Manifesto for Software Development”.

Source: http://agilemanifesto.org/history.html

Agile Manifesto

The Agile Manifesto consists of 4 important values. The way to read the Agile Manifesto is not that the items on the right side have no value anymore, but the Agile movement values the items on the left more.

Individuals & Interactions           OVER          Processes & Tools

Working Software                        OVER          Comprehensive Documentation

Customer Collaboration             OVER          Contract Negotiation

Responding to Change               OVER          Following a Plan

So let’s take a look at the first line of the Agile Manifesto. This line states that we value people, their interactions, communication and collaboration more then having all sorts of extensive processes and tools in place. Of course processes and tools are valuable, however, they are much more valuable if they actually support people working together and delivering great products. What we see in a lot of organizations these days, is that the processes and tools are the goal themselves. From an Agile perspective, we value this differently. Processes and tools should be supporting people in working together and delivering value to customers.

Working software (or “done” products) is valued more than comprehensive documentation. This doesn’t mean that documentation isn’t valuable anymore. There is a lot of value in proper documentation! However, there is not so much value in documentation of hundreds of pages, which aren’t kept up to date and which nobody uses! But still, documentation may be very valuable. Think about user manuals or maintenance documentation for example, this may come in very handy. On the other hand, working software is valued even more! And in my personal experience, there is a self-reinforcing loop when you’re more focussed on working software then on documentation. For example, when you create very user friendly and easy-to-use products, the users may not even need any documentation at all!

Customer collaboration is valued more then contract negotiation. It would probably be impossible to work without contracts nowadays, and it’s not that there is no value in contracts at all. It would however be very helpful if your contracts would support collaboration with your customers. I’ve seen a lot of organizations where the customer and supplier have a need for extensive contract negotiation, not only about prices, but especially about scope, timelines and risks. What would be much more beneficial however, would be to focus more on how you will be cooperating together as partners in the project you’re about to start. I’ve seen a lot of suppliers focussing more on prevention of penalties, instead of focussing on their customer and what they really need. Organizations could deliver much more business value for their customers by focussing on their needs, rather than negotiating penalties and risks.

The last principle of the Agile Manifesto is all about being responsive. It’s not that planning or the creation of a plan isn’t valued anymore. It’s more that the world is changing in such a fast pace, that there is not a lot of value in creating extensive plans for months or years ahead. The need for adaptation is much stronger nowadays and it being able to respond to change quickly is therefore a much more relevant capability for organizations than the ability to create extensive plans which need to be followed.

Agile Manifesto Principles

Complementing the Agile Manifesto, the Agile Alliance has also defined a set of 12 underlying principles, which provide guidance and more detailed explanation in addition to the Agile Manifesto:

  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.
  9. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  10. Continuous attention to technical excellence and good design enhances agility.
  11. Simplicity–the art of maximizing the amount of work not done–is essential.
  12. 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.

Source: http://agilemanifesto.org/principles.html