Test Your Agility

Of course implementing Agile is not a goal. It is a way to help achieve improvement in your IT-initiatives. Reaching the desired results however is greatly dependant on doing the right things, inspired by the right mindset. An early warning that things might turn out less successful than expected is when people say: ‘Yes we do Agile, but…’. Saying you want to do Agile as an organization is one thing. Really doing it is quite another. To get a grip on reality it sometimes helps to state what you should do to fail miserably. This is exactly what the AgileBut Manifesto shown in Figure 25 is all about.

Figure 25: The AgileBut Manifesto

A basic tool to see if a team will be able to self organize and work in an Agile way is provided by the Nokia Test. It defines the minimum prerequisites for a team to call its way of working Agile. It does this in two simple steps. First it determines if the team works iteratively using three simple questions.

Does the team work iteratively:

• Are iterations timeboxed to a maximum of 4 weeks;
• Are features tested and usable at the end of each iteration;
• Are features clear enough before the planning of an iteration starts.

Working iteratively is a prerequisite for the team to be Agile. The test goes on to determine whether the team is working Agile using Scrum using five simple questions.

Is the team doing Scrum:

• Does the team know who the Product Owner is;
• Is the Product Backlog ordered and does it provide insight into business value;
• Does the Product Backlog have estimates created by the team (using planning poker);
• Are the team velocity and work remaining toward the goal known;
• Can the team focus on their commitment without disruptions by management (or anyone else);
• Is the team able to self organize.

Another powerful tool is the XP Bill of Rights shown in Tabel 1. It provides a way to see if the right mindset is in place to succeed with Agile by stating basic rights for developer and customer. Looking at this table you will see that they often represent different sides of the same medal, balancing expectations from both sides.

Tabel 1: XP Bill of Rights

Developer Bill of Rights	Customer Bill of Rights
You have the right to know what is needed with clear declarations of priority.	You have the right to an overall plan, to know what can be accomplished when and at what cost.
You have the right to produce quality work at all times.	You have the right to get the greatest possible value out of every programming week.
You have the right to ask for and receive help from peers, superiors, and customers.	You have the right to see progress in a running system proven to work by passing repeatable tests that you specify.
You have the right to make and update your own estimates.	You have the right to change your mind, to substitute functionality, and to change priorities without paying exorbitant costs.
You have the right to accept responsibilities instead of having them assigned to you.	You have the right to be informed of schedule changes in time to choose how to reduce the scope to restore the original date.
	You can cancel the project at any time and be left with a useful working system reflecting the investment to date.

The message here is simple: make sure you pass the Nokia Test and that your actions adhere to the basic rights stated in the XP Bill of Rights before expecting major benefits from the use of any Agile or iterative method.