The Agilometer is a ranking system similar to DSDM’s Project Approach Questionnaire that can be used to assess how ready the project environment is for using Agile delivery methods.
There are 6 key areas defined in the Agilometer:
- Flexibility on what is delivered
- Level of collaboration
- Ease of communication
- Ability to work iteratively and deliver incrementally
- Advantageous environmental conditions
- Acceptance of Agile
Each key area has a definition, and it’s up to you to assess it objectively and assign scores between 1 (worst) to 5 (perfect) to it.
If you have a set of values such as (1,5,4,4,4,5) for the six key areas respectively, you should have plans to improve your weakest point, which is “flexibility on what is delivered” in this example. You should also understand the consequences of this weakness and tailor the system accordingly.
The scores change during the project, and you should keep updating them and applying the required changes to the system.
Flexibility on what is delivered
Agile projects are based on adaptation: you’re not sure on the scope of the product, and let it evolve by using feedback loops and focusing on the outcomes and business values.
This adaptation sometimes results on dropping some of the initially identified features, because they don’t have enough business value, or you have to swap them with higher priority items in a fixed-price contract. The customer-side stakeholders should understand and accept this fact, otherwise, the ability for accepting changes and adapting (Agility) would be limited.
Level of collaboration
Adaptation (Agility) is based on feedback loops that require Rich Communication and a high level of collaboration. For example, user acceptance testing has to be done continuously. As a result, the customer should make enough representatives available for these tests all the time. On the other hand, frequent Review Meetings have to be done with the presence of the customer. If the customer is not available enough, useful feedback won’t be generated.
On the other hand, development team members should also collaborate with each other in a self-organized environment to have innovation, creativity, and productivity maximized.
Ease of communication
Rich Communication is required for enabling useful feedback, which is the basis for adaptation (Agility).
The two main keys to making communication easy and effective are:
- Co-locating the team to have face-to-face conversations, and if not possible, make the best use of communication technology such as video chat.
- Using simple and low-tech communication methods. Using sophisticated software for communication may have a negative effect on projects.
Ability to work iteratively and deliver incrementally
Adaptation is based on creating usable (potentially releasable) subsets of the product in a short time, receive feedback from them, and use the feedback to plan for the next cycle. This is made possible by the following two:
- Incremental delivery: the product is delivered step by step, to create the feedback loops. A big-bang product delivery doesn’t create enough chances for adaptation. Not any deliverable satisfies this: it should be usable (potentially releasable) to create a real experience. A “solution architecture” document, for example, is a deliverable, but not an increment of the product, therefore, it doesn’t help with adaptation.
- Iterative development: real increments can be created when they are 100% done, and all the development processes are repeated for them. After all, if you don’t know the whole scope from the beginning, it’s not possible to run processes such as design (solution architecture) upfront, and you have to repeat it in each “cycle”. Repeating the development processes is called iterative development.
Advantageous environmental conditions
This key area includes everything that doesn’t fit into the other groups; e.g. availability of training.
Acceptance of Agile
Not every stakeholder is comfortable with Agile methods, and this will create problems along the way.
- Helps you tailor PRINCE2 Agile by understanding the level of Agility that suits your environment
- Helps you identify Agile related risks for further risk response planning
- Helps you find the weakest areas to plan for immediate improvements in the system
When to use it
- During the pre-project period, in the Starting up a Project process. The result will be captured in and influence the Project Brief
- During the initiation stage, in the Initiating a Project process. The result will be captured in and influence the Project Initiation Documentation
- During the delivery stages, normally at the end of each stage in Managing a Stage Boundary process. The result will be captured in and influence the Project Initiation Documentation.
Written by Nader K. Rad
This is (and will be) a work in progress: More details will be added in the future, depending on the feedback.
This wiki is developed and managed by an accredited trainer, independent of AXELOS. While aligned with their guidelines, it’s not an official resource.