1. Physical strength and fitness
2. Technical ability to solve the problem and create a route
3. Mental stamina and belief
In the last few months I’d like to think I have developed in all these areas and will now quite happily tackle and achieve results to V3 problems. It is fascinating how these factors interplay with each other. Some problems require a little more strength and some benefit from more technical ability, but all factors come into play to some extent. State of mind also makes a huge difference – a fear of falling or a thought that you cannot do it usually means that you aren’t successful.
What does this have to do with Programme Delivery?
Well it struck me that actually Bouldering is the same as programme delivery in many ways. The same 3 ingredients are required for success:
All too often when I’m reviewing and recovering programmes in crisis I find that some of these basic ingredients are lacking. Frequently, as I did when I began climbing, people assume that additional strength is required to succeed. Whilst you need sufficient strength to complete the problem, applying too much energy can easily cause you to loose grip or balance and fall. The same is true of applying extra resource to a struggling programme.
There is also another element intrinsic to climbing that is required for any successful programme. That component is a clear goal. In Bouldering you have to climb and touch the top hold with both hands. Having a common understanding of the required outcome is also essential for a successful programme.
What happens when you struggle with the ascent?
In climbing you are working against gravity. The same is true of any change programme – if you stop and let go you fall back to the starting position. Organisations and the individuals within it revert to the previous state.
It is often the case that half way up the wall you get stuck. The same is true of many programmes part way through. Generally problems at this stage are due to a shortage of one of the three ingredients mentioned. At this point you can do a number of things. As already discussed more resource is only a solution if that is the genuine cause of the problem. Appropriate interventions in this situation are generally:
Taking any other course of action or hanging in for too long without acting generally results in a fall. It is much better to make a controlled descent than fall and risk injury. Programme sponsors and stakeholders like to see that things are under control – even if that has to be a controlled change to the outcome.
A further challenge is often when your belief in the ability to succeed comes adrift from actual capability. I see this a lot on programmes when mid-plan challenges hit, stakeholders lose confidence and make personnel changes often based on perception rather than fact.
The power of coaching in sport is well established. It appears to be less so in programmes. Agile coaching is gaining momentum but is still some way from being accepted as commonplace. Help from friends on the ground has been incredibly useful for me while climbing both tactically in pointing out the foothold I haven’t seen, providing encouragement or just generally sharing ideas on problem solving. I believe the same benefit is up for grabs in programme delivery.
So what are the key elements for a successful ascent?
I find this analogy quite useful as a reminder of the key things required for successful programme delivery:
This probably seems like a very basic list, but all too often some of these basics are missed. In the menatime, I wish you a successful ascent!
This concern is particularly evident in organisations embracing Agile delivery for the first time. Whilst it is easy to see the benefits of having empowered teams working directly with product owners, striking the right balance between devolving control to delivery teams and maintaining the appropriate level of governance and providing suitable direction is less straightforward.
Executives in any organisation are keen to understand what will be delivered, by when and at what cost. To answer, what on the surface appear simple and perfectly natural questions, many turn to reporting and metrics.
Should we be measuring the performance of Agile delivery teams? If so how do you go about it?
Clearly having measures in place is not a complete solution to predictability, “past performance is no guarantee of future performance” but you do need to know where you are in order to move forward.
A full exploration of Agile delivery metrics would take many more words than is sensible for an artcle blog article but there are a few things that in my experience require consideration when putting in place delivery metrics and presenting data to stakeholders:
1. Have a clear objective
If you are going to measure the performance of delivery teams and meter your projects then start by asking, “Why?” and “What?” in order to be sure that you know what you want to get out of the exercise. Teams will be naturally suspicious and suppliers potentially defensive if they think it is going to impact their standing in the organisation or what they get paid.
Metrics should be targeted and focused on looking at what will provide insight into the direction of travel and the quality of the delivery. Ultimately any detailed measures need linking back to the overall Programme objectives and business case.
2. Whatever you measure will distort behaviours
What you measure and how the information is used will change behaviours within the team. This may or may not be a desirable outcome.
Thinking through the impact of any metric is essential. I’ve seen some pretty awkward measures being used in the past. For example, measuring developer productivity based on lines of code per day (seriously – people still think this makes sense!). This sends out a clear signal that more lines of code is what is required, but that is clearly not necessarily a desirable outcome – if not kept in check unnecessary duplication or deviation from a clear and simple design can occur.
There are of course times when distorting behaviours is exactly what is required and there is nothing like a prominent screen displaying a defect glide path or the number of failing tests on the build to focus attention on where effort should be directed.
3. Tell a story
Numbers in isolation are meaningless. People do not respond to purely charts and spreadsheets – they need to hear the narrative. Telling a senior stakeholder that you have a velocity of 52 or 187 open defects doesn’t tell a story, historic trends can help but don’t always provide the full picture.
As managers of technology delivery we add value by providing genuine insight and context over and above what the numbers are saying. Project managers should never just report the numbers but get under the skin of what is driving them and what the message is.
When reporting metrics it is essential to get to the root cause of any changes or deviation from expectation.
4. People are not machines
Buy-in and clarity of intention is essential if metrics are to be successful and to avoid demotivating a team or worse, inducing them to game the system. We are not measuring widgets coming off a production line but the process of creating a complex software system by highly skilled and highly paid professionals.
Getting the team on-board such that they not only get work with the process but also actively benefit from the information provided is a prize worth seeking. In fact, asking the team, “What information can we provide to our stakeholders to demonstrate the good work we are doing?” is a pretty good place to start.
I believe strongly that irrespective of what measures you agree with your team and stakeholders there are two key guiding principles:
1. Transparency – information should be taken directly from the teams and shared openly.
2. Traceability – it should be possible to relate data over time without changes in currency or dilution of measures.
So my answer to the question ‘Should we measure Agile delivery teams?’, provided these factors are take into account, is ‘Absolutely yes’ – it’s an essential part of keeping our stakeholders informed.
Metrics on their own will not guarantee delivery predictability, but without them you’ve no real way of having fact-based conversations about where you are.