Agile and the Project Environment

Agile and the Project Environment

Recent years has seen an increased interest from project management professionals in the potential of Agile methodologies known primarily from Software development and maintenance. By many Agile is seen as a cure to some of the ills that ail the traditional waterfall project models. Many organizations are in the process of creating hybrids that take the best from both worlds: the overall structuring, controlling and reporting from project management and the change embracing delivery model represented by Agile methodologies.

However, it may not always be advisable to apply this hybrid model to projects. Some project types lend themselves more easily the project management with Agile delivery model method. Some organizational environments make combining Project Management with Agile delivery fairly easy. Other project types and different organizational environments may mean that applying Agile delivery will cause more problems than the benefits we may expect to gain.

So when can we go ahead and have both project management and Agile in attendance and when should we invite only one methodology to the party? The PRINCE2 Agile methodology employs an agile assessment which is reflected in an “Agilometer”. Depending on our scores in 6 different areas, we are able to assess whether a project is suited for Agile delivery. Let’s have a look at which areas are accessed.

Flexibility in What is Delivered

Traditional waterfall projects typically operate with a fixed scope/quality and may flex on time and/or cost. The Agile approach locks time and budget, but displays much flexibility in what is delivered. Requirements are prioritized, e.g. using MOSCOW. New requirements may come and push other requirements further down the priority hierarchy. Is our organization comfortable with creating these prioritizations, of swapping requirements, not just adding more and more to what must be delivered on time and within budget.  Does our organization accept that not all is known and specified from the start, but that the delivery emerges as we carry out the project?

Level of Collaboration

Does our organization have good collaboration between teams, departments and divisions? Or are we saddled with silos, turf wars, blame culture and old but well-remembered situations of feeling let down by others? Does everyone involved in the project see themselves as part of the same team, regardless which part of the organization they may come from or whether they are internal or external participants? Agile requires an environment high in trust and partnership.

Ease of Communication

Do the people involved in the project sit close to each other or are they spread out between different parts of the building, different buildings, different cities or countries/time zones? Do people communicate face to face, use video-conferencing or phone calls or is e-mail and written communication the preferred method. To be able to use Agile in our projects communication must be rich and frequent which means as much face to face and as little e-mail, reports and memos as possible. Further, all information about the project and the deliveries is presented succinctly and visually and is available to all participant and stakeholders at all times.

Ability to Work Iteratively and Deliver Incrementally

Is it possible to break down the deliverables into separate parts that when delivered on their own still bring value to the customer and can be used as learning and input for the following delivery rounds? Is the product to be delivered of a nature that allows this incremental approach? Are the people who are to receive the increments capable of keeping up with the speed with which deliveries arrive? If the solution/product to be delivered cannot be delivered in increments due to its nature, due to integration to surrounding solutions/products, or if the organization is not ready for increments, Agile delivery may not be the best way forward.

Environmental Conditions

Do we have a stable dedicated project team working full time on the project? Are our project participants skilled at the work they need to do? Are the surroundings set up to support the Agile methodology with relevant tools and agile-oriented contracts with suppliers? If our project has many part-time participants, if participants join and leave frequently and partners do not necessarily wish to work using Agile, we may want to stick with a more traditional waterfall approach.

Acceptance of Agile

Does our organization have enough knowledge of Agile and thus have the correct perception of what Agile means? Not just in terms of understanding what Agile means for the way products are delivered, but also in terms of what kind of behavior this necessitates from the project team, stakeholders and the rest of the organization. If our organization does not understand that Agile is not implemented by decree, but needs changes in organization of tasks and in behaviours, then Agile may not get us the results we hope for.


The “Agilometer” gives us a way to measure how well-set we are to use Agile delivery for our project. We should not create an average of the scores across all six categories, but rather look at each category in isolation. Each area that scores medium or below should give us serious cause for pause to consider whether the issues identified here can be helped sufficiently or whether we are better advised to run our project in a more traditional waterfall approach.

Feel inspired? Have ideas? Need to launch initiatives?
Get in touch with NT Management Consulting today.