Knowing Agile makes me cleverer!

Introduction

In a project scoping meeting this week I realised how much of my knowledge about Agile techniques has seeped into my DNA.

Agile contains so many practical ideas for scoping, planning and resourcing, I can’t remember how I managed projects before Agile! (And this is from someone who used to be global head of project and programme management for one of the largest banks in the world – when PRINCE2? techniques dominated).

These are the elements of Agile that solved the most problems in our project scoping meeting:

1. Delivery Plan (Not Gantt chart)

Instead of bottom up planning based on requirements, the Delivery Plan is built on releases. Make sure everyone is clear on what the project deliver and what we are going to get for our money.

So you are starting with the big question first (see Business goals). To get the flow of work right you have to know:

• What you are going to deliver first?
• Then what would make sense to give them next?
• What would build on the first deliverable?
• What would make sense to your customers?

2. Business goals (Not requirements)

All your planning decisions are based on your view of what improvements you are making to the business.

The best Delivery Plan will be the one that delivers the most useful improvements to the business first. In my scoping meeting this week the business goals is new revenue streams.

All our decisions are focused on how early we can get something to the market that customers will buy. And then I need to think if they like the first outputs from the project, how can we building this with related products services that extend the features of what we delivered first – so they buy more and they buy more frequently.

The business goals are another way of talking about benefits, and the sooner we put these into measurable statements, the sooner we can think about how to track progress towards them.Staying at the high level (the team can break the work into specific tasks)

I think this focus on the main outputs from the project stops me going off at tangents. Instead of getting caught up in the detailed planning for how we will create the project deliverables I can more productively use my time on the value and benefits.

3. Staying at the high level (the team can break the work into specific tasks)

I think this is the greatest value of Agile approaches. I add more value by not getting caught up in the detail:

1. Staying at the high level enables me to take a much wider view of what the project is trying to achieve. I can question if the scope overlaps with other projects, or worse if it conflicts with what other projects are trying to do. I can also keep bringing the scope conversation back to the essentials:

• What does each element add to the business goals?
• What benefits will each element if the scope create?
• Are we putting the most valuable scope early enough in the project?

The detail belongs to those who are going to do the work. They are closer to it. They have more up to date technical knowledge than me. If I step in and start giving detailed instructions I am lowering my teams motivation. I am stopping them decide exactly what to do and how to do it.

That autonomy is essential to their motivation. Self-choice creates an enthusiasm and a desire to get things right that no amount of pushing from me could ever create.

Staying at this high level gives me a chance to explore the quality of what is needed, again at the high level. In a world of uncertainty it is more useful to identify the criteria by which deliverables will be acceptable than to come up with detailed requirements for quality.

In my Project scoping meeting we were able to have a useful brain storming session on what good means. We looked at factors including:

• Usefulness – ease of use and how simple to operate the products would be.
• Accuracy – how many sources of research do we need to use to decide if our products are right. Do we need to bring in experts from outside our company to assess and endorse the quality of our products?
• Level of tailoring – should we make different versions for different customers? Should we create standard and premium versions of our products?

This high level approach, driven by my focus on the business goals is empowering. In more traditional project management I feel I am a taker not a maker. I take in detailed requirements and use my talent to turn this into detailed plans and then spend my time chasing everyone for their progress against the plan.

Conclusion

Agile makes me a leader not an administrator. I ask the big questions about what we are trying to create and what we are trying to achieve. I feel closer to the business strategy, which is motivating. I feel I am part of the objectives and more relevant because of this.

What is your experience of Agile? If what I am saying makes you realise you don’t know enough about Agile, have a look at these resources to get yourself up to speed:

https://agilechangemanagement.co.uk/2018/04/27/adopting-agile/

https://agilechangemanagement.co.uk/2018/10/11/start-learning-agile/