Agile makes me smarter!

Introduction

In a project scoping meeting this week I realised how much of my knowledge about Agile concepts and 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 Change Management! (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. Roadmap (Not Gantt chart)

Instead of bottom up planning based on requirements, the Roadmap is built on iterations, short bursts of work that deliver an outcome or a capability that the organisation did not have before. Make sure everyone is clear on what the project is expected to deliver and what we are going to get for our money.

So we are starting with the big question first (see Business Need). To get the flow of work right we 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 Need (Not requirements)

All our planning decisions are based on our view of what improvements we are making to the business.

The best Roadmap will be the one that delivers the most useful improvements to the business first. In my scoping meeting this week the business need 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 build this with related products services that extend the features of what we delivered first – so they buy more and they buy more frequently.

Identifying what the business needs is 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. If we don't know what we will be measuring we will not know what to measure!

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 need?
• What benefits will each element if the scope create?
• Are we putting the most valuable scope early enough in the project?

1. 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 deciding 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

Understanding Agile Change Management 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, register for this webinar to learn some quick and simple habits to increase your agility https://apmg-international.com/events/being-agile