Root Cause Analysis: what it is and why you need it

cracked floor
cracked floor

Root Cause Analysis: what it is and why you need it

Imagine, if you will, that you have a garden – with a beautiful old brick wall that circles it.

One day, you discover a crack running between the old brickwork, which otherwise seems solid and immovable. It wasn’t there before, but it doesn’t look too bad. The wall’s in great shape otherwise – so you decide to patch it up.

You drill and chisel out the old mortar, and replace it with new mortar. Good as new.

Fast forward a couple of weeks, and the crack’s back. It’s even bigger this time. Even so, you decide to press on with another round of patching, assuming your lack of skill as a bricklayer was to blame.

Once again, all is well.

Until a few weeks later, when the crack has practically become a gaping chasm. The wall is, without any doubt, leaning and buckling. It’s on the brink of collapse.

And then you see why; there’s a tree growing on the other side of the wall.

The roots have slowly been working their way under the wall, moving the earth, disrupting the foundations, causing the cracking, the stressing – and to save the wall, you’ll have to deal with the tree.

That is – quite literally, in this case – the root cause in this case.

This is just a super basic example to demonstrate the idea – it can be far more difficult in complex systems – like the human body. Finding the root cause of a problem is exactly what doctors do when a patient is unwell; just on a different scale of complexity and importance.

Treating the symptoms of their illness with medication is what a chemist does.

But, just like the constant patching and eventual buckling of our proverbial garden wall, the chemist’s medicines are just mortar, patching up the brickwork.

At some point, we’ll need the doctor’s investigation of the root cause – the underlying issue causing the symptoms – so that we can deal with the problem once and for all. But in a system as complex as the human body, there can be multiple root causes to a problem.

With Root Cause Analysis (RCA) in an Agile context, we’ll need to become more like the doctor, and less like the chemist; prescribing the medication to get us through, while we search for the root cause – before our patient ends up like the garden wall.

What is Agile Root Cause Analysis (or RCA)?

Root Cause Analysis (RCA) is the process of discovering the true cause of a problem, in order to identify effective, lasting solutions.

In Agile teams, this is an important aspect of maintaining autonomy and accountability, being able to self-diagnose issues within the team, and create effective solutions. It prevents the same and similar issues being repeated in the future.

It’s also important for analysing and repeating success; discovering what caused something to work well can be as simple as working backwards, but often, this misses the root cause of the success – because we focus too heavily on the result at each stage.

Why do you need to conduct Root Cause Analysis?

If your team encounters the same issues over and over, the most likely reason is that problems are being patched and not dealt with at the root.

Agile Root Cause Analysis can guide them towards the source of the problem.

It’s much more effective to prevent and solve underlying issues than it is to constantly be putting out fires.

In the same breath, it’s better to spend a little more time solving the right problem than it is to chase speed alone – and solve the wrong problems quickly.

So with that in mind, let’s take a look at the fundamental goals of any RCA:

  1. To discover the root cause of a problem or event
  2. To fully understand how to fix, mitigate or learn from the root cause
  3. Apply what we learn to prevent future issues and repeat successes

Point 3 is important. Imagine if, in our garden wall example, we learned that the tree roots were the true cause of the problem, but we rebuilt the wall without addressing the tree.

We’d feel productive – we’ve built a whole new wall. We did some good, hard work.

But the new wall just will fall foul of the growing roots again. And the one we build after that. And the one after that…

If we don’t address the root cause, we’ll likely have the same exact problem over and over. And to prevent future issues, we can use our learnings to check for other trees growing nearby, or make a roadmap to deal with similar issues in the future.

RCA sounds great, doesn’t it? So, how do you do it?

Well – it’s simple in principle, complex in practice…

How to conduct RCA in Agile teams

First, establish the following as your guiding principles:

  • Seek to correct the root cause, not just the symptoms – but DO relieve symptoms short-term
  • There can be – and there often is – more than one root cause
  • The blame game is futile. Focus on the HOW and WHY, not WHO did WHAT
  • Look for reliable cause and effect evidence
  • Get enough information to formulate a solution
  • Consider how the same root cause can be prevented in the future

Now you’ve got a guiding North Star, you can seek methods to conduct your analysis.

The 5 whys approach

“The 5 whys” is a classic RCA methodology.

For every answer to a question, follow it up with a deeper one.

It might take 3 “wait but why?” questions to get to the root, or it might take tens of them.

One of the most common and enduring examples comes from the infamous Toyota Production System – the grandfather of Agile methodologies. The problem? My car won’t start. Let’s apply the 5 whys approach:

  1. Why? – The battery is dead
  2. Why? – The alternator isn’t working
  3. Why? – The alternator belt is broken
  4. Why? – It was well beyond its service life and not replaced
  5. Why? – The car hasn’t been serviced regularly

BINGO. Lack of servicing is the root cause; not the dead battery, or the broken alternator belt.

We’ve learned that, by sticking to a service schedule, we can avoid this – or similar issues with wear and tear – leaving us without a car again.

The 5 whys isn’t perfect – but it helps us to avoid assumptions. By drilling down into progressively deeper questions, answers become clearer. Ideally, by the time we answer the last why, we’ll have our root cause; but in complex systems, this can get tricky.

And it’s entirely possible to have more than one roost cause, remember?

While there are other methods of conducting RCA, this one’s a good start to get to grips with.

And if you need something deeper, maybe it’s time to look outside your organisation.

Hire Agile experts

ClearHub specialises in finding the best Agile contractors in the world; vetted, skills-checked and ready to change the way your company solves problems.

Want to know more? Get in touch with the ClearHub team today – call +44 (0) 2381 157811 or send your message to

Share this post

Share on facebook
Share on google
Share on twitter
Share on linkedin
Share on pinterest
Share on print
Share on email

5 Steps to Becoming an Agile Organisation

staff meeting
staff meeting

5 Steps to Becoming an Agile Organisation

Moving towards Agile has become something of a trend in business today. It’s an attractive model; lean, but incredibly effective. No wonder more businesses want to adopt Agile.

But for software companies, IT companies and development teams, it’s kind of been the only way to work. And many have learned, sometimes the hard way, that it’s not so much a transformation as it is a transition.

It takes time. It takes dedication. It takes foresight, insight, introspection and retrospection.

Transitioning into Agile will change core business processes, capabilities and the very guiding principles of a company. And that can’t happen overnight, or in one move; it’ll take an iterative and incremental approach – and you’ll often be learning the ropes as you go.

Read more – How to create an Agile team

But even though it takes time and resources, it will pay off. The first step to becoming an Agile organisation is to decide it’s the right move, and to set the wheels in motion – and the best way to do that is by establishing your mission objectives.

Step one: the mission

Before you do anything, you need a purpose.

Think of everyday tasks: you eat to nourish yourself, sleep to re-energise, and exercise to feel your best. You climb a staircase to get to the next floor. You call a cab to go somewhere.

So why do you need to “do Agile”?

The danger with starting a project so vast and so broad is losing sight – getting caught in the minutiae and chasing your tail – without ever achieving anything but the creation of more work.

So, with that, step one is to define your goal, the purpose of adopting Agile.

Read more: How to set SMART goals

And, when you find your purpose, don’t forget to share it with the most important asset you have – your people.

You need to make absolutely clear why you’re doing this, and effectively communicate it with the entire organisation. You need to guide them through, and listen to their feedback. If everyone’s on board, with a mission they can all get behind, success will come far more easily.

Common goals lead to a sense of community, purpose and buy-in – which in turn leads to common values and principles. These are the core areas of your company that you must, over time, change, in order to be able to say “mission accomplished”.

Step two: assess what you have

Now you know what you want to achieve, it’s time to take stock. How close or far are you from realising your mission? What will you have to change to achieve it?

You will, of course, still have to do business during the transition to Agile. It can be tough to make that seamless, and some companies start with fringe departments or R&D teams; areas of the business with longer-term goals, or delayed yet significant value.

Segment these out. Identify your core value streams; the processes and people that achieve your regular business goals. Plan for their continued operation, while setting in motion a plan for Agility.

Then, decide which teams and processes to transition over first. The company structure won’t necessarily have to change – but resource allocation might.

Step three: out with the old (mindset)

We live in the 21st century – the age of the semiconductor, the pocket-sized supercomputer and the Internet of Things. We can control any aspect of our lives remotely and digitally with a tap and a swipe.

So, why do we do business, company structure and management in the same way we did more than a hundred years ago?

Managing employees and their time, setting rigid tasks – and yet pushing for innovation and competition.

Modern business leaders know that every member of a team is different. Each has a specific expertise, making them leaders in their own roles. Seniority and leadership qualities should no longer be defined by how big someone’s team is, but by how effective they are in their specified role; their experience and knowledge, and thought leadership.

Read more – The future of work

It’s time to get into the Agile mindset; allow your team members autonomy, self-regulation and authority in their specialism. Create a fair and effective system of governance and accountability.

Let everyone become a leader in their own field. Trust their knowledge and experience, and make them accountable for their successes. And of course, their failures. Because there will be failures; but that’s actually a good thing.

Step four: incremental, iterative progress

As humans, we have to fail in order to progress.

But failure is almost always demonised, when in fact, it’s the best teacher we have. Imagine parents watching their baby take their first steps. The child fails, and so the parents decide never to let them try walking again.

It’s an absurd notion, but that’s basically how most adults treat failure. We fail once, and we never really try again.

To use the baby steps analogy again, approach the agile transition with – well, baby steps. Plan the transition to Agile in short bursts, and allow time for the change to take effect so you can evaluate properly.

But be careful of overthinking and overplanning; insisting on perfection can stop organisational change in its tracks. Instead, take an iterative, incremental approach. Change little and often. Assess failures, and think of ways to improve the next round of changes.

An Agile Coach can help with this – someone with experience in transitioning to the Agile methodology. It can be difficult to see progress when all reports show failures, and it can be easy to lose heart. An Agile Coach can not only build that confidence back up, but help roadmap the entire journey.

Even from those first, tiny baby steps.

Step five: always be learning

Old habits die hard.

When you’re on the path to Agility, it can become easy to slip back. This means constant vigilance is needed to promote and sustain the transition.

And it’s never finished.

You’ll always be learning. And that’s an excellent cultural trait to have in a business.

For Agile to work, learning must become more valuable than products; outcomes more valuable than output. Those become byproducts of innovation on the bleeding edge.

That can be a hard concept to imagine; essentially allowing for playful inventiveness and discovery instead of focusing on shipping your product alone.

It’s a mindset and culture you’ll have to adopt, as a company, over time. And the payoffs, while far in the future, will be revolutionary.

Staying on the path of organisational development, process improvement, and Agile transformation requires guidance. And at ClearHub, we’re connected to the people who’ve made it happen at countless organisations around the world.

Let’s bring them in.

Adopt Agile in your business – with Agile experts in your team

ClearHub specialises in finding the best Agile Coaches and freelance Agile Project Managers in the world; vetted, skills-checked and ready to move your company into the future.

Want to know more? Get in touch with the ClearHub team today – call +44 (0) 2381 157811 or send your message to

Share this post

Share on facebook
Share on google
Share on twitter
Share on linkedin
Share on pinterest
Share on print
Share on email

The 4 most important DevOps metrics and how to use them


The 4 most important DevOps metrics and how to use them

When you’re working towards SMART goals, you’ve got to be able to measure the impact your efforts are having.

In fact, that’s what the M in SMART goals stands for.

In Agile teams and DevOps, measuring performance is critical to quantifying the impact of your team’s work. And, without measuring how things are today, it will be impossible to know whether all our hard work will actually make any difference in the future.

The same principles apply to fledgling startup teams and elite, high performance teams. Software teams need metrics to understand where they are now, how much has changed since project start, and how much more work needs to be done to reach the goal.

But what metrics do you need to actively monitor?

Well, the challenge isn’t typically figuring out what metrics to apply, but how to apply them.

Analytics within modern DevOps tools, like the Atlassian stack, collect reams of data – more than most teams will ever need to know. Getting it isn’t the problem; using it is where teams tend to struggle.

Let’s take a look at the 4 most popular DevOps metrics and how to use them meaningfully.

1. Lead time

In DevOps, the most critical metric is often speed.

How quickly is value delivered to the customer? How quickly can we patch, update, iterate, and improve?

Lead time or cycle time is the metric in question, here. Many companies fall at this critical hurdle, because while lead time is captured and analysed, it’s often not done accurately enough. This can be because:

  • The team doesn’t fully understand the value stream
  • An inaccurate value stream has been applied that ends before customer delivery

Lead time is probably the most important measure of a team’s ability to deliver when it comes to customer satisfaction. Make sure everyone on the project knows this, and what the end of the cycle is – so that it can be accurately tracked and logged.

It’s also important to measure trends in lead time. See where delays commonly occur, and implement optimised processes to improve project flow.

2. Deployment frequency

If lead time measures how fast a team can deliver, then deployment frequency measures how often.

This is also a direct measure of your team’s ability to respond rapidly to changing conditions; like resolving critical bugs or security issues.

This is a key metric for high-performing Agile and DevOps teams. At Amazon, their teams are able to deploy hundreds of software builds per day. While that level is unattainable for most development teams, they can still achieve a high level of operation and output without needing that kind of deployment frequency – it all depends on the expectations of users, customers and the platform itself.

However, rapid response to critical issues is a necessity. Prolonged downtime can mean customers are forced to adopt competitors – and once they’re gone, they’re not likely to come back any time soon.

Low deployment frequency can also cause users to leave, or stop new users coming on board: look at the state of slow play in the transition to Apple silicon, for example, where many professional users are either jumping ship for optimised platforms or holding back on software upgrades until native versions are released.

In some cases – like Dropbox – users are actively battling for native support to be prioritised.

Think about your user base and monitor the tech that’s using your software or web app (in fact, make this a bonus metric), so you can prioritise output where the data says it matters most. Don’t just give the squeaky wheel the grease, monitor the whole landscape.

3. Change failure rate

High deployment frequency looks great on paper – but if the quality isn’t up to standard, then what’s the point?

No matter how frequent, if the majority of deployments are unsuccessful, you’ll have unhappy users. The success to failure rate for software deployments can be extremely revealing – so track it diligently. This metric can offer critical insights into your team’s performance. Work towards a downward trend in failure rates – and if the reverse is true right now, see what’s consistently causing issues.

Communicate clearly with your team. Don’t be quick to blame; often, everyone is doing the best with what they have. Instead, offer support and find solutions to any problems they’re facing, to improve failure rate.

4. Average time to restore

No matter how elite, experienced or epic your team is – they’ll eventually fail at something. Deployment failures are inevitable, but they can be mitigated with robust rollback and contingency strategies in place.

Some deployments may benefit from automated rollback processes that shorten the time required to restore a service to customers. The ability to quickly rollback an update and minimise the impact to customers will give your team the confidence to deploy more frequently – because there’s less at stake if it goes wrong. Elite teams do this already; they make bold moves, and rollback to a previous iteration if it doesn’t work. But when it does – it’s hugely beneficial to their end result.

Good DevOps needs to be measured where it counts

Good DevOps needs meaningful metrics, to give insight into what is going on within the end-to-end flow.

You don’t need to monitor everything at once – and even this list of the 4 most important DevOps metrics isn’t absolutely vital for every organisation – start with one or two of the most impactful to your business and workflow, and grow from there.

A little is better than none at all.

The aim isn’t to become a perfect machine, where innovation stalls and creativity plateaus. The aim is to inspire continuous improvement, and to empower your team to reach the elite status of development faster.

And if you need the right talent to guide you – talk to ClearHub.

Hire the best DevOps consultants

ClearHub specialises in finding the best DevOps consultants in the world; vetted, skills-checked and ready to get results.

Want to know more? Get in touch with the ClearHub team today – call +44 (0) 2381 157811 or send your message to

Share this post

Share on facebook
Share on google
Share on twitter
Share on linkedin
Share on pinterest
Share on print
Share on email

How to create an agile team

working team memebrs
working team memebrs

How to create an agile team

At a glance, working under agile methodologies seems like a trend. Everyone’s doing it at angel-backed startups and at the hottest new software development studios. Bigger, established companies are still using the tried and tested traditional approach, with a rigid hierarchy – and they don’t seem to be struggling much.

But over time, trends give way to norms; and when agile teams consistently outperform the traditional bureaucratic approach, the old ways of working look dated (at best). In high-risk, all or nothing ventures, agile makes sense – an elite team, doing everything they can to achieve the goal in front of them. So why can’t a relatively low-stakes, established enterprise use agile?

Well, they can. At least partially at first. Agile methodologies don’t have to be adopted company-wide, or even team-wide – and there’s no right or wrong way to experiment with approaching agile. Creating an agile team takes experience; and the acceptance that failure is not only an option, but that it should be embraced. Maybe that’s the reason so many hold back; agile seems experimental and risky. But the bigger risk is standing still and doing nothing, because eventually, your business – no matter how big – will lose the edge.

To create an agile team at any scale, you’ll need some key ingredients. Biggest among them are:

  1. Communication, collaboration and trust
  2. The right blend of skills
  3. Patience

1. Communication, collaboration and trust

You’ve got to trust them. They’ve got to trust you back.

This is entirely non-negotiable.

Company culture, open communication and freedom to speak; this is how you foster a trusting environment. You’ve got to listen to the needs of your team, and have systems in place to do so, where everyone feels they can be honest.

Agile relies on open and free communication. Without it, or if members of the team don’t feel safe to air concerns, projects collapse. When communication is free and transparent, true collaboration can begin.

Tools like Atlassian Confluence, integrated with project management tools, can keep steady communications and open collaboration within an agile team – with full transparency and visibility to any authorised persons in the rest of the company.

Leadership can track progress, while the team works uninterrupted. And, as long as the trust is there, communication will continue to flow.

Trust between teams and leadership is the bedrock of a great place to work, and a KPI for success. Trust is what gives agile teams the freedom to deliver the best work. With no restraints and the ability to apply their expertise, they can capitalise on incredible opportunities and create novel solutions.

While it’s hard to measure, creating a KPI for trust is not impossible. Using engagement surveys or continuous listening, teams can communicate their needs and feel listened to – cementing trust in their company.

2. The right skills for agile teams

What’s better – a team of specialists, or a team of generalists? A mix? How about specialists led by a visionary, or generalists led by a technical wizard?

This is the million dollar question, because the right skills aren’t actually as important as the person who wields them. Back to point one, the right people for an agile team have to trust each other first and foremost – and the right members might already be working together, just in a more siloed capacity.

To create an agile team, break down and reorganise your staff assignments. Analyse the working styles and personalities of candidates – their core strengths and weaknesses, how they complement each other –  with the end goal of creating a balanced team. The idea is to have a small, autonomous group of people who can self-start, but making sure the right personalities are there is fundamental to success.

Having duplicate or absent skill sets doesn’t equate to a bad outcome; skills can be learned quickly by the right people, and hiring agile contractors will fill any short-term gaps in skills. A lack of trust and a group of personalities that don’t work well together absolutely will lead to a bad outcome.

The right skills aren’t always technical. Sometimes, the most valuable skills are the ones that many take for granted.

3. Patience

Some people worry that agile teams lack rules and structure. On the surface, giving a team total autonomy seems like a recipe for chaos – but the truth is that agile teams are fundamentally process-oriented; each member has a purpose in the team, with a key set of strengths.

The anarchic appearance of agile is most likely attributed to this seldom-spoken fact: agile teams fail. Daily. Hourly, even. We’re not talking monumental business-killing failures, here – what we mean to say is that, when you’re pushing boundaries and doing the undoable, you’ll hit a lot of dead ends.

This is what makes agile teams objectively and overwhelmingly better at creativity than traditional teams.

The opportunity – the encouragement, in fact – to fail. Risk needs to be assessed and monitored as a part of the process, but without it there will be literally no reward to speak of. Only out of the ashes of 100 micro-failures will the glowing phoenix of triumph emerge.

This takes time and patience from leadership, who could be forgiven for thinking agile is a waste of time when the end goal seems so far out of reach. But not only does every failure provide a learning opportunity, it leads to the creation of novel solutions.

Nobody walked perfectly the first time they tried as a baby. Agile teams won’t hit the target first time round, either. But just as babies learn to walk within months of their first attempts, agile teams will learn how to solve the challenges your business faces – even if they seem a bit wobbly at first!

Boost your agile teams with highly skilled contractors

Give your highest performing teams the additional knowledge and skills they need. ClearHub helps you find the best Atlassian experts, and to hire agile contractors that align with your values and goals. Want to know more? Get in touch with the ClearHub team today – call +44 (0) 2381 157811 or send your message to

Are you really agile? How to measure your business agility

Are you really agile? How to measure your business agility

Are you doing agile – without even knowing it? 

You probably are if you’re reading this. Most companies today are actually on the agile business roadmap, somewhere. But what’s the destination?

If you’ve read our post on setting SMART goals, you’ll know that it takes a goal to make a plan, and that measurement is a huge part of the journey to success. Becoming an agile organisation is no different, and measuring your progress towards your final destination is a key factor.

Let’s show you how to measure business agility, and how to find out where you are right now on the agility scale based on the traits of other agile companies. To put it simply if:

  • You have a mission
  • You focus on outcomes, not output
  • You invest in next-gen tools
  • You lead by example
  • Your team is ready to fail
  • You hire people who believe in your mission

Then you’re definitely on the agile roadmap – even if only a couple of these are true. Let’s look closer at each point.

You have a mission

Your mission is what you do that gives customers value. In fact, as an agile business, you should only exist for, and because of, your customers.

Once you become customer-centric, everything you do is guided by what your user needs; not by vanity metrics. Missions sound wishy-washy and airy, but they are quite the opposite. They are the simplest embodiment – the purest distillation – of your business. If you cannot explain why your business exists in a sentence, then think hard about the value you provide, at the very core of your customers’ decision to use you.

Creating a mission statement gives you and everyone else in your company a singular vision and focus – and that focus should always be your customer.

You focus on outcomes, not output

Agile teams are measured on outcomes, not output. Or input, for that matter.

Working task-to-task is myopic – but most companies let their teams work this way. There’s no overall goal, or growth mindset; it’s simple churning and grinding. It’s not very motivating or engaging, and the only beneficiaries in this scenario are leadership and stakeholders (not customers, and certainly not teams).

That short-sightedness leads to attrition, stagnation, miserable working practices, massive staff turnover rates, stunted growth, bad reputations… the list goes on. 

It shouldn’t matter who works on what – as long as they’re right for it. It shouldn’t matter if a task takes an hour or a week – as long as the business goal is achieved.

The ticking of boxes only matters if the last box gets ticked. Otherwise, what’s the point?

Success should be measured on the value delivered – not the hours it took, or the number of clicks it got, or the volume of work produced. Value, at the heart, is what people come to your business for. Focus on that, not the tasks along the way.

You invest in next-gen tools

Your company is a proud Beta-tester, and early adopter, always diving into new product features – and as a result, is always ahead of the game. Cloud-based app solutions, for example, like Jira Cloud and Confluence Cloud, are making your business more efficient and more collaborative.

Your team can work from anywhere, and you’ve already established that working remotely keeps everyone happy and engaged. You’re embracing the future of work, and the results are already paying off.

You can be assured that this is an agile approach. Agile companies are first in line for new ways of working and new technology to help them do it. If this sounds like you, then welcome to the agile club.

You lead by example

Agile is a mindset that runs from the CEO to the contractors you hire. At least – that’s the ideal.

The reality is that this might be the last bastion of traditional teams. Leadership is usually reluctant to adopt agile – fearful, even. In most cases, agile methodologies come from the bottom of the company and filter upwards, usually hitting roadblocks along the way.

If you’re a leader reading this, then please – give it a try. Because you’ve got nothing to lose and everything to gain: happier teams, better engagement, better results – it’s all there with agile methodologies.

If you need proof that agile isn’t a new-age fad, look at the VW Golf GTI. No, really – that after hours project was spearheaded by an agile team. They single handedly created the hot hatch, and cornered a market because of it.

The moral here is: trust your team to deliver the goods, give them the time and the tools – and they’ll surpass your expectations. You might not make cars, but passing on agile could be stopping you from having your own Golf GTI moment. 

Your team is ready to fail

Failure is NOT A BAD WORD. It’s essential, it’s vital – it’s how we learn. If you’re not failing, you’re not doing anything new.

We’ve heard this all hundreds of times by now, but it’s so true. It’s not “bravery”, it’s business. If you want to be the market leader, the innovator that all others look to, then you have to be ready to look a bit silly, too – and not care about it.

You have to be ready to see a project through to failure if you ever hope to see it succeed.

You hire people who believe in your mission

ClearHub is a specialist in sourcing agile contractors, to join any team. We work to find the best fit, with the right skills to complement your team.

We’ll find the agile contractors who believe in your mission – the ones who want to work with you to make your vision a reality. In turn, they’ll give your highest performing teams the additional knowledge and skills they need.

Talk to ClearHub to hire agile contractors that align with your values and goals. Get in touch with the ClearHub team today byby cainglling +44 (0) 2381 157811 or send your message to

5 Predictions For the Future of Agile and Teams

5 Predictions For the Future of Agile and Teams

As a consultant, I have had the privilege of working with a large number of organisations; from world-class software development powerhouses, to startups just getting their feet wet. 

No matter the size, the technology, or the market, they all have at least one common interest: to gain a competitive advantage.

They might not always word it the same way from company to company, but it’s what they want. They want to build a better product than their competitor or to improve the efficiency of their own operations. Big or small, new or established – the organisations I’ve worked with demand quality and consistency from their development teams.

The best development teams in the world are capable of shipping high-quality software on a consistent, reliable basis, for an extended period of time – with maximum flexibility. How?

Because these organisations create a working environment based on the principles of leadership, teamwork and trust

The benefits of adopting these principles form deep roots within a company. Trust in their team means better engagement, motivation, satisfaction and higher productivity – but also leads to effective planning, and lower maintenance costs, because teams are self-managing and enforcing good standards. This approach always focuses on self-improvement in the name of efficiency (or sanity).

Using the best agile teams in the world as a benchmark, I’ve made five predictions on the future of agile and teams.

1 – Agile pods will dominate

The best teams in the world are cross-functional and autonomous. I predict that the majority of agile teams will be working in pod structures: self-organising, autonomous teams who are equipped with all of the talent and skills required to deliver a product.

This trend is emerging because multiple competing perspectives tend to push a team towards the best overall solution.

These teams are entrepreneurial in spirit, professional in attitude.

Agile Connection explains agile pods like this:

“Agile pods are small, custom agile teams, ranging from four to eight members, responsible for a single task, requirement, or part of the backlog. This organisational system is a step toward realising the maximum potential of agile teams by involving members of different expertise and specialisation, giving complete ownership and freedom, and expecting the best quality output.”

The benefits of small, autonomous teams are many – but they end with a product of impeccable quality, produced for a lower cost over the long term.

2 – Team maturity will grow – and so will agencies

I predict that more elite software developers will move into agency work.

Agencies want them, because they’ll be able to sell their clients a “solution team” – one that’s established and capable of delivering a high-quality product for a lower price than their client could build in-house.

Mature teams grow into productive and predictable “mini companies” – if empowered with the right blend of leadership, skill, autonomy, and drive. This is achieved with team member consistency and reduced attrition, positive side-effects of an equitable, trusted and engaged team.

3 – Integrated tools

Integrated tools – like those in the Atlassian stack – offer teams unprecedented visibility into their work and their products. The world’s best teams leverage the integrations between products, and use them to maximise efficiency.

4 – Agile teams will move into sectors beyond development

I predict that The principles of agile will spread far beyond engineering and development, into all areas of a business. Adopting the agile mindset in other departments will cut down on projects that should have been cancelled before they even started.

It’s hard to be an agile team working in an organisation that’s not agile. It’ll take some companies time to adjust. But some are taking the principles and applying them to in-house resources.

For example, agile has already begun to spread to marketing teams; the Clearvision marketing team practices agile marketing – giving the department autonomy and decision-making control over which projects to devote their efforts to. This way of thinking will eventually spread to other areas of the business; let the best team for the job decide how to meet the goal.

Product management is another emerging hotspot – using the Lean Startup methodology, which is an inherently agile way to develop a product.

5 – Data-driven agile

Integrated tools and mature processes will eventually collide with big data.

Now-niche methodologies like Team Software Process (TSP) and Personal Software Process (PSP) will get a second wind, as they offer us a promise for insight into our work.

Nobody likes the fact that agile comes with little objective evidence – but we’re willing to trade that for increased flexibility and throughput.

I believe that soon, we’ll close the gap left by this trade-off; and we can have our data and our flexible way of working. Integrated tools, mature teams, and a desire to improve will push teams toward analytics and data-driven insights.

With big data, performance can be measured – but it takes machine learning to process all that data, and AI to give it context. When somebody figures out how to marry big data analytics with the notoriously-difficult-to-measure agile methods, AI and data will become a core part of our decision-making. Moreover, we’ll have data-led proof that agile teams are (and always have been) the future of work.

Hire agile developers and contractors

Companies who foster agile teams will gain a competitive advantage: better products, made faster – for less. ClearHub helps the world’s best companies hire agile contractors that will transform the way they deliver projects.

Want to know more? Get in touch with the ClearHub team today – call +44 (0) 2381 157811 or send your message to