Posted on


I’ve been doing a lot of thinking about leadership recently. I sometimes come across teams, especially “management” teams, who are not really teams at all. They just happen to be on the same line of an org chart with a common boss.

Unsurprisingly, they do not make any effort to effectively communicate, let alone collaborate, and the results are not pretty. Their own teams in turn do not communicate or collaborate effectively, leading to a fractured, dysfunctional organisation.

It results in an indefinable, but unhappy atmosphere, with people feeling disconnected, focusing on tiny tactical wins, and being demotivated by a lack of significant progress. It is often accompanied by a focus on demonstrating busyness over effectiveness.

Where do you start to turn around this unhappy ship? At the top.

A common definition of a team is “a group of people with a common purpose”. It is the leader’s absolute responsibility to define and explain that common purpose to their management team. It is possibly the most important aspect of leadership.

Achieving collective goals directly related to that common purpose should be the measure of each team member’s success, and the leader must tell people that this is one of the critical factors upon which they will be assessed.

Without it, people will pursue personal agendas, hoard information, focus on creating and protecting their empires and will prioritise all of those things over delivering value through their own teams.

If you have been promoted to any level where you have a team of your own, you must accept that you must be a leader. Any leader has a position of great responsibility. There is no abdication of that responsibility.

As soon as you have a team, your primary focus must be to become and remain the best leader you can possibly be to your team.

I don’t care if your job title says “Manager” or “Head of” or “CXX” – if you have a team, you are now a leader. Act like one.

  • You primary job is to get your team to be successful
  • Create a team, and help them to become an excellent team
  • Establish a clear and common purpose
  • Measure individuals by how they collaborate with their teammates, and measure the team’s progress and success
  • If they in turn have their own teams, you must measure their ability to lead as part of their fitness for the role, and measure how they encourage their teams to collaborate with other teams
  • You must explain to your people how you will measure their performance, and collaboration skills have to be an integral part of that assessment

If you can’t do this, you are not the right person in the role. A very strong statement, I know, but true. You will just feel stressed and unhappy, and life is too short for that. Finally, you owe it to those people who need an effective leader in order to fulfill their own potential. If you can’t be that effective leader, step aside. Leadership is not for everyone.

Postscript: I work with lots of leaders in helping them to develop the skills and attributes I’ve outlined above. This short post just starts to explore what is a very deep and fascinating subject.  If you want to arrange some time with me, in the strictest confidence, to discuss your personal situation, please contact me.

col @

Posted on


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.

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


Ensure people work differently

Definitely not

Enforce models for working differently

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

Agile product development for Startups (Part two) – Getting the initial Product Backlog

Note: This post and its companion were first published back in July 2014 after I was approached to provide a primer for startups.  I think the content still holds true today, and as this site is changing direction for 2016, I thought it worth reposting here. – Col.

In the first part of this article, I provided some high level steps to get you from an idea to a user-centred Product Vision supported by personas.

In this final part, I’ll touch on one of the tools you can use to build on those artefacts and get an initial version of the Product Backlog.

Now, irrespective of how you are going to deliver this product or service, you will need two vital foundation elements to make sure you build the right thing, and build the thing in the right way.

The first is a business value model. What are the goals you are trying to achieve from this product or service? You should have a pretty good idea of these from the work you did in defining the Product Vision.

The second element is a list of the critical success factors that will determine if you have met those goals. In short, how are you going to measure if you are delivering the value you want, and how are you going to ensure that you are not wasting time and money over-engineering this to a point beyond what is actually needed. Agile organisations and teams are focused on delivering “just good enough, for now”, and no more.

A simplistic example might be to have a goal for the next car you are going to buy of “carrying my immediate family”. Initially, that might be just you and your partner. You only need two seats. But over time, your family may well grow, and you’ll need more seats. But you don’t need them right now.

The element of time, and the order in which the product or service may evolve over time is missing from the Product Vision. So we move to use the next Product definition tool in our toolbox – The Product Roadmap.

Again, I’ll refer you to the excellent resources made available by Roman Pichler. His Go Product Roadmap is an excellent tool, although of course other roadmap formats are available. The Go Product Roadmap was published late in 2013 by Roman, and I have recommended it to clients ever since.

I won’t go into the details of how to work with the roadmap, as Roman does an excellent job of that.

So I’ll skip forward in time to a point when you have completed your roadmap. I suggest you read through the presentation and explanatory material on Roman’s site before going further.

Now with your roadmap completed, you have versions of your product or service identified, each with a target completion date, goals, a high level list of features and the metrics you will use to track if you have met the goal for that version. It will look something like this

Product Roadmap Example

Now if you look at the features, goals and metrics across the different versions of the roadmap, and rotate them by 90 degrees, you might end up with something like this.

product backlog example

Let’s review what we expect to see in a Product Backlog, at a very basic level.

1.A Prioritised list of features.
2. Each feature should have an associated business value that aligns with
the overall business value model.
3.Each feature should have measurable success factors associated with it to
ensure we deliver to the right levels of quality – “Just good enough for
now, and no more”.

You have created a very high level Product Backlog!

Going through the steps in part one and two of this article will give you a simple framework to get you to this initial Product Backlog. It can be considered the Launchpad for the project.

Be aware though, that there will be a lot more work that will be done on reviewing and refining the backlog throughout the life of your project to make this brilliant idea into a successful product or service.

I wish you all the luck in the world.

Posted on

Agile product development for Startups – Part one – First steps

Note: This post and its companion were first published back in July 2014 after I was approached to provide a primer for startups.  I think the content still holds true today, and as this site is changing direction for 2016, I thought it worth reposting here. – Col.

So you think you have a brilliant idea that will become a hugely successful product or service. Congratulations!

But how do you turn that idea into a well considered, structured game plan for how you will turn your concept into reality?

Traditionally, you’d do a bunch of stuff around market research, business plans, big project plans and a whole heap of things before you get anywhere near building the thing. But you’re an Agile startup right?

In these short posts, I’ll be referring to the great work of Roman Pichler. I consider Roman to be at the top of the tree when it comes to Agile Product Management specialists. His site has loads of detailed background and resources on the areas I will just skim over.

So how do you quickly get from a concept to an initial Product Backlog you can start working with? Here’s a high level of the first steps you probably want to take.

Step 1 – Understand your users. You should create personas for the different types of user your concept is aimed at. A persona is a fictitious person who represents as closely as possible a typical type of user of your product or service. Personas are important because they remind you that you are developing a product for people, not generic user types like “Author”, “Editor”, “Administrator”, “System User” etc. In most cases, you’ll have multiple personas to represent the different types of people your product is for. Make your personas visible in your team space to remind you everyday whom you are designing for. You don’t have to define loads of detail up front. Your personas will evolve as you learn more about them through user testing and other forms of feedback. Here’s a short definition from the Agile Alliance.

Step 2 – Develop the Product Vision. In short, you need to define who are your users, what of their needs are you going to address, a super high level view of the capabilities your product or service will provide to meet those user needs, and finally, what’s in it for you? You should also define a one sentence “vision statement” to encompass the whole concept. A vision statement for YouTube might be “A free online video hosting, sharing and streaming service funded by advertising”.

The Product Vision is important because it provides scope boundaries. We know that things move in and out of backlogs as we gather insights and inspiration.

We may define a Product Vision for a new car, and as we learn more about our users and our needs, an initial view that they want four seats may change. They may want six seats, because in our target market, people often travel with the whole family. But it’s still a car.

However, if our Product Owner explains that we need to provide 50 more seats, spread over two decks, that’s not a car any more. It’s a bus, and that doesn’t fit within the overall Product Vision.

That’s not a bad thing. It doesn’t mean we say “No, we’re building a car, so we won’t do that”. If our users really need a bus, we should reset the product vision and the steps that follow it. What we have discovered is that the car is not the right product to build.

The Product Vision is also very important to align understanding and expectations early from stakeholders. If you are going out to angel investors or other routes to seed funding, the PV and other artefacts will be absolutely vital to get your concept across concisely and professionally.

Roman Pichler’s Product Vision board is a fantastic resource that I have introduced to many teams. I wholeheartedly recommend it. Here’s a link to Roman’s site.

Once you have your Personas and Product Vision established, you have a solid foundation to work from. The PV is vitally important, but it lacks a critical dimension – time. In my next post, I’ll explain how you build on the Product Vision to move towards creating that Initial Product Backlog.

Posted on

The Scorpion jet – Agile/Lean in military aviation

Scorpion for wp

Great product development starts from an understanding of the customer and a problem statement that describes the as is world in which that customer lives.

For Textron, their primary customer is the US Government, and the problem statement was that budgets are incredibly tight compared with the days of the Cold War and that the current generation of military combat aircraft are complex, expensive to buy and operate and designed for a war that no longer reflects the major threat to the defence of the USA.

So they took a radically different approach that illustrates some great practice in Lean/Agile thinking.  The end result was getting an aircraft from first concept to first flight in only 20 months (in comparison, the very complex and advanced F-22 Raptor took nine years), that costs a fraction of traditional combat aircraft (F-22, $150M each, Scorpion, $20M) and has an operating cost of less than 20% of those traditional jets (F-22, c. $20,000 per hour flown – Scorpion, c. $3,000 per hour).

What made those results possible included the following key principles.

  1. Focus on the minimum viable product.
  2. Wherever possible, reuse existing components, particularly those that take a long time and cost a lot to get off the drawing board, such as engines.
  3. Build a cross-functional team that are co-located and eliminate redundant processes, documentation and administration.
  4. Let the team self-organise and self manage.

To be clear, the Scorpion is not as capable as the F-22.  But, many of the missions that a more complex jet would have to fly at $15-20,000 per hour can be carried out perfectly well by the Scorpion, allowing the expensive aircraft to be used only when their advanced features are really needed, extending their operational lives and saving money.

Already, the team is attracting a lot of interest, and it’s likely that the Scorpion will be a major export success to friendly governments outside of the USA.

Here’s a webinar I delivered on the subject early in 2015.