Posted on

Trust

When I ask people about the key characteristics of great teams, one word is used above all others – trust.

It has certainly been my experience that all of the best teams I have been a part of have composed of people who trusted each other. It’s such a fundamental tenet of teamwork that I honestly don’t believe any group can become a team without it.

I have been a member of teams where that level of trust has become so strong, and that team bond so enduring, that many years later I know that I can ask for the help of my fellow team mates and to the best of their ability, they will provide it, no matter how far away they are, or how long it may have been since we last met.

To build that bond, it’s often that case that we have shared adversity together, and have a collective memory of support, collaboration and individual effort for the team’s welfare. In most cases, we never explicitly discussed those things – they are just part of what we each took away from the experience.

We saw people do the right thing for the team in difficult circumstances. We also shared the pride and happiness when things went well. In a few cases, we experienced great sadness together.

So over time, people working together can build trust, sometimes to extraordinary levels.

But how does a group of people start to build trust when they are brought together as a team for the first time?

I think it starts with the little things. Here are some examples.

  • If a team is supposed to meet at a given time, people don’t turn up late.
  • People are open and honest with each other. This can take time to build, as it is in itself a manifestation of trust.
  • You ask for help
  • You do what you say you will do, and if you can’t, you will let people know why you couldn’t.
  • You treat people with kindness and respect
  • You look for opportunities to help others.

A team inception event is often useful in starting to develop routes to build trust in a new team. Discussions and exercises can establish common ground, identify shared values and allow team members to learn a little of the personal backgrounds, interests and the human elements of their colleagues.

This can all help to start creating an element of unity across the team.

Humour has a very important part to play too. When people smile and laugh together, they relax and can collaborate and communicate together more readily.

Leaders have an important role to play in helping teams to form and excel at what they do. One definition of the word team that I’ve come across is –

“A group of people or animals linked in a common purpose”

It is a leader’s responsibility to describe that common purpose so that all of the team understands it, can see the value in it, and recognise their individual role within the team to help achieve it. Without this, it is unrealistic to expect people to work together in concert to realise any shared goal.

If you want your people to see you as a leader, they need to trust you.

They need to see you exhibit the behaviours and attitudes that you expect of them. They need to see you supporting them. They need to see you step up and get involved when the team needs help. They need you to thank them when things go well.

Sometimes, people need to be able to trust those they do not know.

A passenger on an aircraft absolutely needs to trust the pilots that are controlling the aircraft. The pilots need to trust many people who have prepared the aircraft for the flight, from the engineers who service the aircraft, the refuellers who need to ensure that enough fuel of the right type and quality has been uplifted, and the other staff who ensure that things like the route and loading has been carried out correctly.

Why do people trust third parties in this way? Partly it is because they believe that those third parties understand the consequences of not doing their best, and have a responsible attitude to their work.

This definition of the word responsibility is interesting –

“A duty or obligation to satisfactorily perform or complete a task”

If you are responsible for something, in most cases, other people are relying on you to satisfactorily perform or complete a task. Not just correctly, correctly and promptly.

When people don’t understand their real responsibilities, or the responsibilities they have been provided do not match the expectations of those who rely on them, they will fail to meet the expectations of those who rely on them, and trust will erode.

Many people I see in organisations do not understand the consequences of their actions or inactions. That is not their fault. It is the responsibility of those who lead them to help them understand.

So they will let people down, often without even realising it, if there are no good lines of communication and collaboration with those who rely on them.

This often happens when a team relies on another team, especially when there is physical separation between teams. If two teams sit next to each other, there will be some ad hoc, unstructured communication, even when there has been no mandate or structure explained by the teams’ leaders.

If they are 100m away, that ad hoc communication probably won’t happen. If they are 100km away, it definitely won’t happen. So leaders need to help interdependent teams to collaborate in much the same way that individuals within the same team do, albeit less frequently.

To summarise, if you want to be in a great team or want to lead great teams, take time to think about what you as an individual can do to build and maintain trust within the team. Then continually look for opportunities to demonstrate your trust in people, and to get them to build their trust in you.

Posted on

Tracking agility

As a coach, I definitely don’t want to apply cookie cutter recipes to the teams I work with. But feedback loops and metrics are at the heart of agility.

Values, principles and practices need to be explained, supported and encouraged. The coach and the team need a shared vision of what good looks like.

One approach I’ve been using at my current client is to establish and maintain a tracker, which looks at 21 different elements related to delivering the right things, delivering things the right way and delivering value fast.

I use a simple scale of 0-5 for each element, with 0 meaning no evidence, through to 5, meaning this is good enough to use as an example with other teams learning to work in this way.

As I observe behaviours, and work with the teams, I make a regular assessment of each element and score the team accordingly. The team and I discuss the scores, and this is a useful framework for explaining not just what we do, but also why we do things.

We visualise the current status of each element on a Big Visible Chart (an Information Radiator) using different coloured post-it notes. Green for example, indicates a 4 or 5. Pink indicates 0, Orange is a 1 or 2 and yellow indicates a 3.

BVC of agility across teams
BVC of agility across teams

Every element has a corresponding index card with a brief explanation of what “good” looks like.

Tracker_element_description
A description of one of the 21 elements.

I create a graph for each team showing trends of the aggregates of the three groups of seven elements (Right thing, Right Way and Fast).

Tracking agility of a team over time
Tracking agility of a team over time

The teams I’ve used it with really like it, and senior stakeholders also like the big picture it provides of increasingly good practice.

Posted on

What does a coach do?

Team Standup

Expose and explain ideas and techniques for working differently

Provide tools to assist people who are trying to work differently

Support people who are trying to work differently

Help people who are having challenges working differently

Not

Ensure people work differently

Definitely not

Enforce models for working differently

Posted on

Slide of the week – Classes of service in Kanban Systems

This is from my current session on Kanban fundamentals, to explain how we prioritise different types of work, based on the relative cost of delay. We agree classes of service with our customers, make the ground rules (Policies) clear and explicit, and use them to manage the flow of work through the Kanban system. We also periodically review the classes of service with our customers as clarity emerges from the Kanban system itself.

Classes of service
Explaining how we prioritise work using a Kanban system
Posted on

If you’ll only take one piece of advice from me, this is it.

If you can only adopt one agile behaviour, adopt the retrospective. Any team or individual can do it. Gather data, generate insights, decide what to do. Be realistic. You can’t change the World in one go. But pick a couple of things you really can change immediately, and make the change right now. Then, in a couple of weeks, repeat the exercise. Keep repeating it, again and again, forever.

Don’t expect miracles or dramatic change. But if you follow this advice, over time you will become more effective than you ever imagined possible. The only way that this will fail is if you stop.

I honestly believe that’s the best advice I can can give to any person, team or company, based on what I’ve learned since I left school at the age of 16. I’ve worked for a living ever since, and I wish I’d learned this very simple lesson much earlier.

Posted on

Slide of the week…

I’m super busy working with a client at the moment, but I do want to keep providing small slices of value to this site on a frequent basis (see what I did there?) – so here’s one slide from some of my coaching materials. This is from a session I call “Workstream fundamentals” which is framework agnostic.

Screenshot 2016-02-19 12.26.48

Remember,  if Agile delivery sounds or looks complicated, with complex diagrams you couldn’t draw by hand in a few minutes, something is wrong.

Posted on

Visualisation – individual and systemic impediments

I’d just started coaching a new client organisation and the very first team I was working with were taking their initial steps in Lean/Kanban.

They were starting to visualise the work, an embryonic backlog was emerging, and they’d had their first standups.

We talked about visualising blockers and impediments on the team board, in order to ensure all the team members knew about them and could offer help to resolve them.

One impediment that was evident after just a couple of days was that there was no simple way of creating a collaboration space for sharing documents across the team.

Those documents formed an important piece of research within this team’s remit. The reason was that some team members were consultants from an outside supplier, and they didn’t have access to the corporate network. It was already causing delay, waste and duplication of effort to multiple individuals.

Yet the team didn’t consider getting that impediment up on the team board. Why? Probably because “that’s just how things are here” and because it wasn’t something the team could resolve themselves, and the impression was that it just couldn’t be solved.

“that’s just how things are here”

Maybe that was true right then for the team. Yet this impediment will create delay, waste and duplication of effort in any project or piece of work that involves external suppliers collaborating effectively with staff.

Jumping forward into the future, if the same impediment appears on many team boards, therefore appears on Programme boards, and percolates up to be visible on the portfolio board that is used by the Senior Leaders in the company, the true impact of this issue becomes transparent and impossible to ignore. Resolving it will improve flow across many areas of the business.

But until those little impediment markers start appearing on team boards, it will always be “just how things are here”.

Posted on

The aggregation of marginal gains

As you might know, I spend a lot of time travelling in the car, and I have a lifelong interest in aviation. So to pass the time, I listen to a lot of podcasts, some of them aviation related.

One podcast I subscribe to is Fast Jet Performance, created by Tim Davies. Tim is a Squadron Leader in the Royal Air Force who has been flying fast jets for almost 20 years. His podcast is fundamentally about how you can optimise your performance in and out of work, often with aviation related analogies.

Recently Tim touched on the subject of The Aggregation of Marginal Gains. I won’t copy the detail of what Tim covered (visit his site to hear the podcast), but this resonated with me in my role as a coach and mentor for teams and organisations wanting to optimise delivery of value, often using Lean/Agile approaches.

One key aspect that I help clients with is the vital importance of feedback loops.

Agile delivery is all about the early and frequent delivery of small slices of value and one of the benefits of this way of working is the ability to continually test assumptions by getting feedback on what you’ve delivered to customers so far. That mitigates the risk of you working very hard to deliver the wrong thing.

Releasing early and often also tests the entire delivery process, from concept to cash. Far better to learn where you have problems in testing, integration and operational support quickly with those small first slices, than getting unpleasant surprises near the end of a traditional project, when it may be too late to sort things out without compromising the budget and timescales.

The way that individuals and teams are working together is regularly inspected at retrospectives. At the end of each retrospective, the team identifies actions that will help them to be more effective. At the next retrospective, the team should be honest and review if the actions were carried out, and what impact there was.

These are all elements of feedback in Agile delivery.

Something I often see with clients new to this way of working is an unrealistic expectation of rapid dramatic improvements. It doesn’t work that way.

Sure, in the very early days, the adoption of collaboration, colocation, information radiators and other basic aspects of Agile delivery will often provide really significant improvements in ways of working, but it is the employment of the principles of Inspect and Adapt by means of feedback loops that embed marginal continuous improvement across the board into teams and organisations.

Marginal Continuous Improvement Across the Board – that’s the key phrase to bear in mind.

Agile organisations understand the importance of metrics, so I’ll use some to explore a hypothetical scenario.

Let’s consider a team working in a cadence of two week sprints, with a retrospective at the end of each sprint. After each retrospective, the team implements simple actions that make them just 2% more effective in the following sprint.

After three months, they’ll be 12% more effective. This is often where those unrealistic expectations that Agile delivery is a ‘Silver Bullet’ start to surface.

But if the values, principles and practices of Agile delivery continue to be applied, and those 2% improvements continue, things start to look very interesting.

After six months, the team is nearly 30% more effective, and after a year, they are over 60% more effective.

What would your organisation look like if it was 60% more effective one year from now?

In summary, short feedback loops and small, positive improvements are at the heart of optimising delivery of value. Just don’t expect too much too soon, and KEEP GOING.

Col.

Posted on

Prioritising the portfolio – value modelling

Note: I first published this post on Linkedin in July 2015. – Col.

I’ve often seen organisations start the transformation to become agile and to focus on a model of accelerated delivery of value. Starting small, a pilot team learns this new way of working and (in a limited way) the organisation sees the benefits of accelerated delivery.

The urge then is to scale, with multiple teams all aiming to replicate the early successes. This can be challenging. At a portfolio level a backlog of ideas for products and services will exist and potentially will grow.

No organisation has unlimited capacity – all have limits to the amount of work in progress. Therefore, it’s important to prioritise this portfolio backlog of potential products and services, just like we do for features and capabilities in a team backlog.

Let’s recap on some fundamentals that organisations need to be mindful of if they are focusing on accelerated delivery:

  • Don’t do things that add no value
  • Focus on finishing the highest value things first
  • Make decisions based on metrics
  • Accept that metrics improve over time – start with what you have
  • Use feedback loops and make them short

So, the high-level portfolio prioritisation needs of an organisation might be expressed like this:

  • The highest value things are prioritised for completion
  • Resources are directed to the place where they will deliver the most value for the company
  • We can measure the relative value of work being delivered across teams
  • Senior leaders can make informed decisions on when and where to redeploy people and money to focus on the highest value waiting to be delivered

How can an organisation meet those needs? We can create simple models to:

  • Forecast the potential cost/value ratio of delivering a change
  • Compare the relative value of things not yet started
  • Compare the actual return on investment against the forecast
  • Make more informed decisions on what to start next, what to finish first and what to stop now

Types of Work

Fundamentally, work can have value in three ways:

  1. Work that mitigates risk to the company
  2. Work that delivers cash value to the company
  3. Work that enables delivery of type 1 or 2 work

We can create models for each type of work that help us estimate in advance:

  • How much it will cost to complete the work
  • How much value there is in the work
  • When the value will be delivered to the company

At a simple level, the different types of value models have different profiles.

Risk Value Products and Services

A Risk Value Product is one where the majority of the value delivered by that product is by mitigating risk. Example risks might be legal non-compliance, health and safety of staff or reputational damage to the company.

The profile for a Risk Value product or service might look like this

Sample Profile for a Risk Value Product or Service

 Enabler Value Products and Services

Enabler Value Products deliver most of their value by allowing other Products and Services already in the Portfolio to be delivered. An example might be to select a 4G network provider across the enterprise, enabling a range of mobile products for staff to be developed, that in themselves deliver cash value or mitigate risk.

The profile for an Enabler Value product or service might look like this

 Sample Profile for an Enabler Value Product or Service

Cash Value Products and Services

Cash Value Products and Services deliver most of their value in direct financial terms, such as cost savings or increased revenue. I’ll go into a little more detail on Cash Value Products and Services.

We need to consider how long we will count the value realised before we say, “This isn’t a new thing any more, it’s just how we do business” otherwise we’d be measuring the cash value of a new product or service indefinitely, which would be unrealistic. So we might say, “Two (or some other period, depending on the product) years after the delivery starts, we won’t measure the value realised any more”. This is a very important factor in assessing the ROI on a piece of work.

Now let’s compare two profiles for the delivery of the same Cash Value Product. One Profile will reflect a traditional, “Waterfall” approach and the other will reflect an incremental, iterative agile delivery approach.

Approach 1 uses a traditional delivery model:

  • Small team on 1 year delivery timescale
  • Phases of design, development and test
  • Big bang release near the end
  • Value delivered snapshot after 2 years from work starting

The Profile looks like this.

Sample Profile for Approach 1 – Waterfall

Now let’s consider the delivery of the same Product using an agile, iterative, incremental approach. This is Approach 2.

  • Small team on 1 year timescale
  • Cross-functional team
  • Small incremental releases every month
  • Value delivered snapshot after 2 years from work starting

The Profile for Approach 2 looks like this

 Sample Profile for Approach 2 – Agile

If we do a comparison of the key metrics for the two different approaches, we see some important differences.

Approach 1 – Traditional

  • Cost of team = £316k
  • 1st value delivered = M11
  • Breakeven = M16
  • Net value realised 2 years after work started = £424k
  • ROI after 2 years = 133%

Approach 2 – Agile

  • Cost of team =£316k
  • 1st Value delivered = M1
  • Breakeven = M10
  • Net value realised 2 years after work started = £722k
  • ROI after 2 years = 227%

However, it’s important to note that the improved ROI in Approach 2 is only realised if value is delivered early and often.

Metrics needed for models

To develop these models, we need to estimate some key metrics about the work and the product or service being considered:

  • The size and composition of the team needed to deliver it
  • The duration we estimate it will take to deliver it with that team
  • The frequency and incremental value of each release
  • The time when we will no longer measure the value of the product

Preliminary work needs to be done before that estimation can take place

The use of Vision Boards and Product Roadmaps will provide important pointers to the overall business value model and prioritisation of features and capabilities.Roman Pichler’s excellent work in this area will provide advice and guidance (as well as tools) to help define the overall proposition for a product or service. This initial definition will give you enough to start assessing the estimation metrics I’ve described above and begin creating a profile.

 

Comparing profiles

Once a profile has been created for a proposed product or service, it can be compared with others waiting in the portfolio backlog.

Senior leaders can then rationally assess the relative value of work not yet started, and fundamentally decide one of three things for each profile:

  1. Don’t do it – the value proposition isn’t strong enough
  2. Do next – it’s the most valuable thing in the portfolio backlog
  3. Do later – when it becomes the most valuable thing in the portfolio backlog

Comparing Profiles to aid prioritisation of the portfolio – Product A delivers better ROI than Product B

Tracking profiles

Once work gets underway, the initial baseline profile (that informed the investment decision and the prioritisation of starting the work) can be compared to the actual value profile that emerges as things progress. This allows senior leaders to make measured decisions on whether to continue the work on a Product or Service or to terminate it (because it is not delivering the value expected or because enough value has already been realised).

A Product not meeting expectations of value – Fewer releases and higher delivery costs than forecast

Apples and oranges – comparing Risk, Enabler and Cash Value profiles for prioritisation

A portfolio will inevitably comprise of a mix of the three different types of products. Comparing one Cash Value profile against another is relatively straightforward, as described above. But how can you assess Risk profiles against one another, Enabler profiles against one another, and a mix of all three?

Comparing Risk Value products

You could use a simple matrix with a scoring system to rank the most valuable Risk Products against one another. A sample is below.

 A simple scoring matrix of categories of risk mitigated by different products

You may also be able to use existing risk assessment techniques to quantify a financial value of mitigating a risk – a simplistic example could be

“There is a 20% risk of us incurring £500,000 of fines within one year if we do nothing”.

Reducing that risk to 5% within one year might be worth say, £75,000. If the cost of the product to mitigate that risk is £100,000, you may decide to live with the risk or you may not. But you have applied some structured thinking to assessing the value of delivering the product, and you can compare the relative value to other items in the portfolio.

Comparing Enabler Products

Enabler products might be quantified by applying a percentage of the value released by the Risk and/or Cash Value products that are blocked until the enabler is in place.

If an Enabler product will cost £100,000 to deliver, unblocking one Cash Value Product in the portfolio with a projected Net Cash Value of £90,000 over its measured value period, you probably won’t do it.

But if the Enabler Product unblocks that £90,000 Net Cash Value Product AND a Risk Product that will have a net mitigation value of £30,000, it starts to make sense to deliver the enabler.

Again, the metrics won’t be perfect, but it might well be better than what you have in place right now, and it gives you an evolving toolset to compare the different types of Products and Services in the portfolio. 

It needs to work for your circumstances

There is no simple once size fits all approach to this. Your organisation will have to determine the best approach to apply. Then try it, review it, and adapt it periodically to get it better.

When to review your portfolio profiles

How often you should review new profiles looking to enter the portfolio backlog and benchmark “in progress” Product work on actual value realised will vary from organisation to organisation.

I’d suggest perhaps every one to three months. More than one review a month will create too much reporting overhead.

Waiting more than three months between reviews risks waste, because of a lack of feedback, and a product that potentially delivers enormous value could languish in the shadows for too long.

Summary

Having read this far, I commend your perseverance. I have covered quite a range of topics. If you only take away one piece of information from this article, I suggest it should be the following points:

  • Organisations can’t do everything at once
  • The portfolio must be prioritised on value
  • Metrics should drive prioritisation
  • Metrics should check if reality meets expectations
  • If a Product is failing to meet expectations, consider stopping the work and redeploying people and money on to high value work not yet finished

If you lead an organisation, you have a portfolio backlog. It just may not look like one yet. In amongst the dozens of ideas and concepts, there are quite possibly one or two that will deliver more value than all of the others combined. This approach for assessing and prioritising the portfolio backlog will help you identify those gems, and weed out the lame ducks.

End note

The foundations to this idea are not new. I’ve drawn upon many concepts such as the Cost of Delay, Real Options and Black Swan Theory amongst others. I don’t claim it to be perfect either – far from it.

But if it has delivered value to you in thinking about how to prioritise and track the delivery of products and services based on value, and it has stimulated you to talk to colleagues about how you might go about it at a portfolio level, I’m happy.

Thanks

I’d like to thank the colleagues I’ve bounced these ideas off over the last few months, in particular Kenny Grant of GrantWorks Blue, a trusted friend and excellent coach, and Alan Simmonds of Preterlex, a terrific man with enormous experience and a very gifted mind.