The Blog

How to get screwed by a development agency (and how to avoid it)

If you've worked in a technology or engineering team over the past few decades, you'll have been round this cycle more than once. The outsourcing of software development and the potential pitfalls that follow are commonplace amongst businesses that operate in the digital space. Have you ever wondered what happens on the inside or looked for strategies to make these engagements more successful?

Then read on....

Build internally or outsource? It's one of the most common debates across the technology community. More often than not the conversation usually descends into a simple decision about the bottom line. Cost. An offshore team promises to deliver the same thing you can deliver yourself with an internal team at a significantly reduced cost. Also the stakeholders and decision makers in this endeavour are usually deeply frustrated with the speed of development and the external agency promises it can deliver faster and with better capability and scalability. The CFO likes it as it's very easy for them to trim costs in the event of a business under performance. All across the market, businesses have offshore development teams working hard on delivering on requirements and shipping products. Sometimes it works, sometimes it's a catastrophe. What makes one engagement or project good and one an absolute car crash? First of all, there are some fundamentals to understand.

What is a development agency?

This may seem entirely obvious, however a development agency is effectively a group of people sitting around, trying to get the maximum value from a bunch of other people in terms of time booked on a project. In the world of development agencies, people are a resource and it's the job of those that lead the agency to get maximum utilisation or return on those resources they pay for/employ.

It's common for an agency to have a core group of 'staffers', accompanied by a close knit group of regular contractors/flexible team members. In addition, you often find a cohort of nearshore/offshore developers. It's incredibly common and largely expected for an agency that wins a pitch to not have the full team to deliver it. They will then scale by employing perm or contract supplementary staff to deliver on the engagement depending on the length of the contract.

The real advantage to using an agency is that (if you choose correctly) they have a very deep and diverse set of cross-sector experience that they can bring to bear for your business. This 'gold' tends to sit in the more senior members of the team who are often split across multiple accounts.

How are they set up?

Typically, an agency will have a set of project specific 'deliverers' at the coal face and are entirely working on your project full time. The more senior members will be split across multiple accounts, as will your account manager/account director/client partner. Larger agencies will have the standard organisational roles and hierarchy, smaller agencies probably less so (although this isn't always detrimental)

What are their objectives?

If you're a business and working with an agency, it's of paramount importance that you remember that the agency's single purpose is to get you to book more business. It's their entire purpose for being. For every social, drinks, lunch or selection box of cupcakes - the person delivering them is financially remunerated on your willingness to re-book or expand your spend with them. Yes, it's absolutely in their interest to provide you value, deliver on time and do all the things you request as a client. However, it's entirely with the aim of retaining your business and getting you to expand your spend.

Laying it out in black and white may seem callous. After all, when you've been working with a partner agency for a prolonged period of time, those people become friends and colleagues. It's very easy to lose track of the mechanics of the relationship. The fact still remains that an agency's purpose is (and always will be) to grow the account revenue. (that means get more money from you) Everything they do is to aid that purpose.

Why is this a problem?

It's an unfortunate revelation for some that there is a juxtaposition between your business's aims and the aims of the suppliers that serve it.

Two of the more prevalent areas are software development and digital transformation.

With the former, software development. Good software is written in a way that ensures anybody can easily add to, change or expand upon it. This way of developing is well known, well-practised and ensures that you're developing in a way that can (in the future) be easily maintained by the supplier that commissioned it. I've never, in all my engagements and travels, seen an agency that's self-started and developed in this way. Why? Because it takes longer, costs more money, creates less profit, requires more expertise, and removes the dependency on the agency (and thus the revenue line) to maintain. It simply doesn't support the agency's primary goal, so most tend to not do it.

Digital transformation and Agile implementation are another area where many of the agencies who work within this space will deliberately avoid addressing the core problems that would enable the client to make real progress in favour of extending the engagement as long as possible. Thereby taking small, ineffectual bites and never making the lasting change required. Lasting change doesn't lead to future revenue. I had a conversation with a 'big three' account director the other day who was tasked to do exactly this.

Unfairly harsh

There will be those reading this article, maybe even those working in an agency themselves that will view the above paragraphs as unfair. In some ways, I can appreciate how it paints a pretty bleak and jaded picture. There are good, moral agencies out there who want their clients to succeed and have morality and pride in their work. They do exist, however they are few and far between. I've been involved in some groups who have genuinely sought to grow their client base by helping their clients be successful and grow. Hoping that the success of the client and the loyalty of the agency to that client will lead to an expanding revenue from the account. Occasionally that happens. More-often the now successful client is advised to hire a large and well proven agency with scale that outstrips the original agency. It's a cutthroat industry and nobody gets fired for hiring one of the 'big three'.

How to use a 3rd Party Software Development Supplier safely and with low levels of risk.

About 10 years ago, a small group of colleagues and I started what was called the 'Partner Management Team' within the technology/engineering department at News UK. The purpose of this new team was to ensure that the many software development partners we had working with us at the time were monitored, governed and followed agreed processes to give scalability to the business. Our aim was to deliver software through 3rd party vendors in a low risk, high transparency and high quality fashion.

It was a great success, over 18 months we worked with the existing suppliers to build processes, governance and standards that ensured what was being produced provided high levels of value and met the needs of the business. We rolled this framework out to vet, engage and onboard additional suppliers and helped those partners deliver quality and value as well. The fundamental principles are easy to understand:

- Build transparency and trust at a code level between client and vendor - Develop against agreed engineering/coding standards. - All code is written in a way that makes it portable cross supplier and internal teams.

Unless expressly agreed by the business, never develop anything through a 3rd party we don't have the ability to review, govern and develop on ourselves.

The framework had plenty more detail, however the important takeaway was that the partner agencies were sufficiently steered and motivated to deliver on our quality requirements. Because we operated outside of procurement, any existing relationships and influence was null and void. Our methods for governance were friendly and empathetic, but ultimately clearly outlined the businesses requirements and expectations for which payment was contingent.

Many interesting things came out of this process. Primarily the expectation setting and trust building between our business and our suppliers shined a stark light on the processes of some incumbent suppliers and their practices. It clearly showed the lack of data and review being undertaken by procurement and the absence of business focused diligence in partner selection in favour of those partners who had doubled down on relationship building and demonstrating a false fast pace over demonstration of quality. Some suppliers, having their wares 'laid bare' made decisive and wholesale changes across the account and committed to resolve historically substandard deliveries. Some suppliers were of such low maturity that those in-charge couldn't comprehend their shortcomings.

How do you lower the risk and what are the 'gotchas'

Quality, Quality, Quality, Quality

If you're going to use a third-party development resource in your business, you need to ask yourself a simple question. Do I have the budget, existing capacity, or resource to ensure that the output from the supplier meets our business needs?

Using 3rd party development can be hugely advantageous, however things go wrong when a business expects an agency to work unobserved in a way that's counter to its mandate to grow revenue.

I would argue that a business cannot engage a 3rd Party Delivery resource without the in-house skill set to review, understand, visualise, and govern the output of said partner. It's a common fallacy that a 3rd party development resource can replace an internal team entirely. It cannot. Businesses must maintain appropriate resources to ensure quality, maintain currency in the technology and remove the risk of agency lock-in and dependency.

Beware of the bait and switch

It's common practice, especially within the large agencies, to pitch and win engagements/accounts with senior and experienced individuals on the team, only for those people to be replaced by an inexperienced person with a very well written playbook/resources. In smaller agencies, the senior experience is spread thin and across multiple accounts. Ensuring you're clear on who's bringing focused experience to your project is paramount.

How do you manage the risk?

As I've spoken to many times before in my articles. If you own or manage a digital product today, it is crucial to the business that the code merged into your product is of good quality. It doesn't need to be gold plated and we use the mantra 'Good Enough is Best'. Those who have partnered with us in the past will know this all too well. As a digital leader or c-suite member in a digital business, it's your job to ensure that the code you cut is of a quality that allows the business to adapt to changing user requirements and market conditions with low effort and overhead.

Working with a 3rd party development house is an option for all organisations and one that often seems to make sense when interrogated through the business plan. The reality is that whoever is developing the product that drives your revenue, you need to ensure you're able to guarantee quality, avoid supplier lock-in and deliver outcomes that meet your business and technical needs. In the same way you wouldn't send your children to a school that's not reviewed and that you can't monitor, you should take the same approach with your technology.

Key takeaways:

Never develop anything with a partner supplier you don't have the ability to inspect, ensure quality and govern.

Ensure you clearly agree engineering quality and standards with your suppliers and have the processes and governance in place to impartially ensure you're getting the outcome that's right for your business.

Ensure you have the ability to monitor and audit the output from your suppliers.

Be acutely aware of potential supplier lock-in or dependency. Constantly monitor where you have a single point of knowledge or reliance that's not a member of your business.

Finally, there are significant advantages of working with 3rd party agencies. Whether that be for UX and Design, Software Development or Transformation and Maturation of your processes and people. The unfortunate truth is that just like you, these organisations are businesses. Businesses with their own objectives, agendas and sought outcomes that may or may not align with your own. That (on the most part) is absolutely fine. The proviso being you have the ability to use those organisations effectively and collaboratively for your own needs and put the processes and governance in place to protect yourself and your teams from activities and situations where they don´t. At scale, a well-managed 3rd party development/supplier cohort can provide speedy, effective and experienced support to a business. However, at low levels of scale or on a 1 to 1 basis, the cost of governing an external supplier effectively is often more expensive than maintaining internal resources.

Don't be complacent, there is still a HUGE staffing crisis in UK technology.

If you work in UK technology, you'll probably agree that 2023 has been one of the more challenging years. It's been especially tough for those in the contracting and interim profession where demand has dropped to zero and roles have been thin on the ground. The slow market has also affected people who recruit for technologists, where briefs have been few and far between.

The geopolitical situation that fuelled this current state of the market has been discussed to death. However, the resulting market dynamic has left many technologists out of employment and in extremely precarious situations. On the flip side, many tech business owners and leadership teams are feeling confident in their position and pleased with the turn of events that's lead to the 'new normal' of an employer (rather than candidate) lead market.

In recent weeks I've had numerous conversations with business leaders and agencies across the market who are making 'big plans' for 2024. Strategies are being built, budgets are being signed off and excitement is in the air. The great bounce back is upon us and we're all going to fill our teams with the oversupply of exceptionally 'on point' UK talent that's sitting on the bench waiting for us to be pulled into the folds of our beer and pizza fueled digital businesses.

So about that...

I want you to cast your minds back to 2018. It was a different, arguably much simpler time. In another market, a pre-Covid, pre-Ukraine airline industry had a long standing and painful shortage of pilots. Not only were there not enough pilots, but they couldn't train pilots fast enough to offset the ones who were retiring and leaving the industry. Competition was fierce and salaries/packages were competitive.

In a story we know all too well, in 2019 the world essentially stopped spinning and demand for international air travel fell off a cliff. The huge demand for commercial pilots disappeared. In a few short weeks an industry where talent was in high demand, had an oversupply of pilots and a large pool of unemployed. At the airlines, the strategy for airline pilot resourcing was simple, identify the available pilots in the market so when the time comes, we can reach into that pool and put aircraft back in the air and start making money.

Each airline's pool of available pilots was large and gave a high level of confidence of their ability to scale when the time came. There was only one problem. The pool of talent wasn't unique to each airline and everybody was pulling from the same pool of available talent. Roll forward to 2022 and airlines reached into their pool of talent only to find hundreds of other hands reaching in as well. Before you knew it, the pool was dry and in a whiplash unlike many we've known in recent time - the pilot shortage was back and this time it was so severe that it's lead to well publicised chaos.

It's important to understand that the demand for air travel didn't really go anywhere, the market conditions just suppressed it.

Moving back to digital technology and I shouldn't need to further spell out the parallels. We have historically had a skills shortage in UK technology with competition for top talent being fierce. Market conditions have created an atmosphere of significant caution over the last 12 months which has changed the resourcing dynamics in the favor of employers. However, it's important to realise that while there are fractionally more available candidates in the market, it's the slowdown of opportunity that's created the false impression that there is a glut of available talent - not a sudden influx of high quality candidates.

Let me say that one more time for emphasis.

'It's the slowdown of opportunity that's created the false impression that there is a glut of available talent - not a sudden influx of high quality candidates.'

Like it or not, we live in a capitalist economy that's dependent on growth. Private, funded or listed companies must show growth and progress as a primary measure of success. Technology businesses especially, require skilled and experienced team members to achieve those goals. The pressure from investors, board members and shareholders for 2024 to be a 'return to form' is building rapidly and one of the biggest barriers to business success is going to be the availability of quality and experienced talent to help deliver it.

Since the summer we've slowly but surely started to see an uptick in hiring for more junior roles. More recently, I've been hearing from recruiters that they are again facing challenges sourcing quality UX and Software engineering candidates.

2024 is setting it's self up for an almighty calamity, with a market perception that leaves business leaders confident of their ability to scale and the reality being in stark contrast. With experience yet again being in short supply, advantage goes to the first movers.

How to be a great failure

As I sit here writing this article, I look back across the decades of my career and can easily pick out the events that fundamentally changed me and forced growth. I'm fairly confident in stating that all the success I've had in my career has been as a result of me screwing up in one way or another and being forced to learn. Failure gives us fantastic opportunity to grow as it shows us clearly what doesn't work and forces us to reflect inwardly on what we need to do differently.

Building a successful career requires tremendous fortitude and bravery. Ambition and drive result in you often putting yourself in situations where you're not always entirely equipped. Conscious of the risk of failure. As you climb the career ladder, roles become less available and competition is rife. Those who succeed are individuals who are able to best recover and learn the lessons from setbacks and failure.

When interviewing people for roles, especially senior positions. I'm far more interested in understanding where things didn't go right for the candidate than those that did. What lessons did they learn and what did they carry forward. A senior executives ability to self reflect and recognise their own missteps and failures are a great indicator of real talent.

Given that most successful people are a culmination of their response to failures, why don't we talk more about failure in the workplace? Why do we have corporate cultures where getting things wrong is frowned upon? We are all to eager to celebrate the successes but discouraged from discussing the failures, even though we understand that this is often where the real value and learning comes from?

Firstly, it's critical for organisations to embed the understanding within their cultures that there is a vast difference between failure and under performance. The former (failure) being an unsuccessful endeavor with an opportunity for personal and group learning. The latter (under performance) being a consistent pattern of low quality output and an inability to learn from mistakes and failure. Within many organisations, the two things are so closely intertwined that any mention of a failing immediately insinuates under performance. This couldn't be further from the truth and breeds a culture of obfuscation.

There are some genuinely game changing business benefits to embracing and normalising failure within your organisation. Here are my top three:

Visibility Like it or not, every organisation has things go wrong and nobody wants to be the one to blame. Nobody ever sets out to fail, however unfortunately it happens to us all. Most organisations have a traditional 'blame' culture. If something goes wrong, somebody needs to be responsible and that person needs to be suitably chastised or punished.

The problem with this approach is simple, it's human nature to not want to look stupid or get into trouble. People (and groups of people) will go to often extreme lengths and expend considerable organisational resources to prevent themselves from getting into trouble and looking stupid. Many of these people succeed, leaving organisational time bombs lurking in the ether to rear their ugly heads when you least need (or expect) it.

By encouraging and enabling success but removing the stigma from failure, you not only gain early visibility of the potential hidden time bombs (and can plan to address them) but you gain significant organisational efficiencies by removing the significant time spent trying to hide or shift the blame.

Group Learning In any size or organisation, it's common for people to be working in similar areas and on similar tasks. It's equally common for failures and errors to be repeated again and again, by different people, sapping organisational efficiency. In more traditional 'blame based' business cultures this behavior is common-place.

When a safe space is created to share stories and experiences when things haven't gone quite right, that learning can be shared across the team/business and the chance of multiple instances of the same failure reduce substantially.

Accountability One of the quickest routes to cultural excellence within an organisation is making your teams accountable for the work they've done to the wider business. It's one of the reasons why a good internal communications strategy is essential in any organisation. An open culture that removes the stigma from failure allows individuals and departments to own and be accountable for,the successes, the failures and the learning.

As with all organisational and cultural change, the process of implementing this is a challenging road. A leadership team who's historically been given a sanitised view of the world is going to find it uncomfortable when faced with the reality of just how much gets buried on a day to day basis. I encourage you to take some comfort in the fact that these things were happening anyway - you've just created a space where they can become visible. As a business leader, you can only help make things better when you can see the challenges in the cold light of day.

It's not okay for leadership teams to abdicate ALL responsibility for technology to the CTO.

These days, almost all businesses are in some way digital. Whether your primary offering is a software product or whether your business relies heavily on technology provided by vendors for management and logistics. There is a good argument that in this day and age, all businesses are by necessity, digital. With technology playing such a huge part in the success or failure of organisations, why is it that the technology literacy of those who lead these businesses remains so low?

Over the years of working in this space, I've seen a repeated and consistent trend of CEO's that are strategically, operationally and commercially focused - yet lack a solid understanding of how the products their businesses sell actually get made, nor the processes involved in making them. Requirements and strategies are communicated downwards into the technology teams and progress is communicated upwards. Understanding of what happens in that 'black box' of technology is often deliberately obfuscated by the CTO or if communicated, diluted down to such a level where no useful information or context can be gleaned.

Within some organisations, the unfortunate result of this situation is that the technology department's interaction with the business becomes nothing more than an update on delivery and a chastising if they are late. The detail and responsibility, deemed too complex or risky to attempt to share with the leadership team, becomes the sole purview of the CTO. These CTO's are largely ungoverned, with their metric for success or failure based on whether they do (or do not) make the deadline for the next piece of functionality or product release.

There may be some reading this who's immediate thoughts are essentially 'so what Chris?' If the product is getting delivered and we're able to hit the revenue targets why should I care what's going on within the technology team? I've got enough on my plate without having to worry about somebody else's remit or department. I can entirely see the point of view.

The unfortunate reality is that as a leadership team, whether you be the CEO, CFO or another leadership role, your decisions and direction directly impact what happens to the product your technology team build. This is incredibly easy to see when it comes to features or requests for cosmetic changes. What isn't obvious is how your decisions impact what goes on under the hood of the product that generates you revenue.

Software engineers behave in a similar way to any other person constructing or creating when you put them under pressure. The delivery time may shorten but the trade-off is almost always that the quality of what they produce goes down significantly. Again I hear you ask, why should you care about the code that makes up our products? If it works when it ships, who cares? Again, I see your point of view.

The thing is, building software is not like building a house. It's more like building a constantly expanding and forever changing hotel. Every time you add another bit of functionality or try to make a change, your software engineers are having to figure out what was done previously, how it was done, how they interface with or change it. After all that's done, they then need do ensure that what they've done hasn't broken something else.

When this is done correctly and to a high standard, adding to - changing or building on top of your technology and product is a fairly simple process. When done badly, it often takes significantly more time to figure out how to make the change then ensuring it doesn't break anything else - than it does making the change in the first place. You see, the quality of your code and technology stack is a direct indicator of overall business health and your businesses ability to rapidly generate a return from the money you choose to invest in development (ROI) The poorer the quality of your technology estate, the longer it's going to take to get that product, feature or fix to your customers. Ultimately, it hampers your ability to respond and deliver on the rapidly changing needs and demands of your customers. The quality of your technology is directly linked to how effectively your business can generate revenue.

Mature digital leadership teams are actively invested in not just the product features, but in the overall product health and the ability to add to or change it with low business overhead. These teams have reporting on code quality and overall product health along with objectives and measures baked into their strategies to ensure that their software products are responsive to change and deliver business agility. The condition of the technology becomes the joint responsibility of the entire leadership team.

Although it's uncommon to see, exemplar leadership groups have the ability to deeply incorporate technology and engineering strategy into their wider business strategy delivering truly staggering levels of business agility and response speeds. While less skilled teams unconsciously drive technology teams to cut corners and reduce quality - the mature teams make active and informed decisions to temporarily reduce the quality of a set of development to allow the business to respond quickly. They have the ability to 'go fast now' with the discipline to ensure they make time to go back and make good.

In a modern, high performing digital business, the team leverages a ONE TEAM mindset. It's essential that that these leadership teams have a clear strategic focus on ensuring that the software developed, supports business agility. There should be visibility to ensure that the output of development is neither over or under engineered. Low overhead development should be a key principle and tracked metric.

So you sit on the board and you want some AI?

If you're a C-Level director in a business of scale, the proliferation of AI and how you can leverage it in your organisation will have come across the boardroom table more than once of late. Most at the table will have a passing knowledge of products like ChatGPT, what it does and maybe even have a working understanding of how it does it. The 'NEED' to show that your business is keeping pace with the times and implementing this technology is a strong one.

Many suppliers will darken your door (or screen) and try to convince you that embracing this technology is a 'software problem'. They'll want to develop models for you or have you buy AI powered upgrades to their existing technology. These things may or may not add value to your business, but in the long term - they won't help you. In it's most simplistic form, AI is software that consumes data and (ideally) gives you back something contextual of value. For this technology to provide value to your business and it's customers, it needs to consume and reference your businesses data. Herein lies the problem. Most organisations do not have a technical architecture that enables their data to be easily accessed and utilized. Furthermore, few organisations have the governance, processes and ways of working required to ensure the data provenance required to feed the waves of upcoming regulation and legislation in this space.

For the vast majority of existing businesses looking to take advantage of the power of artificial intelligence, the battle will not be fought over who has the best models. It'll be fought on the battlefield of data and organisational culture.

In the last 20 years, we've seen huge shifts in user behavior and consumption habits. From print to online, desktop to mobile, the rise of applications and the proliferation of social media. Those who have succeeded in navigating these constantly shifting waters all have one thing in common. They were able to identify and mobilize their organisations to adapt in a timely manner.

Digital technology moves at a staggering pace and the speed in which the AI space is progressing is no different. The truth however, is that whatever new AI model or 'next big thing', comes around the corner. Making it valuable to your business will require you to leverage and add to your businesses data in an efficient and scalable fashion. For most businesses, this will be 30% technical architecture and 70% people, process and business transformation. It will require challenging the status quo, breaking down business silos, comfortable areas of control and a WHOLE LOT of collaboration. Business data is like gold, it's incredibly valuable, often difficult to find and people regularly fight to control it.

Organisational change on this scale cannot happen from within a business unit or department. It needs to be owned by the entire business, lead, owned and prioritised from the boardroom.

Any organisational change is painful and businesses have two choices. Either go through the pain now and be in a good position to embrace the technology your users and customers will expect as a baseline. Or change later and be destined to play catch up to your competitors who are able to out perform you by leveraging better products, features and customer interactions.

We need to talk about Agile...

Let me tell you a story...

Meet Jake Bignell, he's the CEO of Legacy Corp and runs a software as a service business. They've been around for a while, have a technical estate full of legacy software products and about 800 global employees. They're a publicly traded business. The company has ridden the turmoil of the financial crisis relatively unscathed and over the last five years, they've seen significant encroachment from start-up challengers in their sector.

The business is frustrated. It just can't seem to get things done anywhere near as quickly as they'd like. Features that take their competitors weeks to produce, seems to take their own technology team a year. Something has to change.

Enter Agile. The silver bullet. The digital transformation that will save the business and get features into production every two weeks. It's going to be great!

They socialise Agile around the business. The CTO and heads of department within technology give presentations on 'Scrum', speak at town halls and team members go on week-long courses to gain fancy new titles like 'Product Owner' and 'Scrum Master'. They hire an 'Agile Coach' who's got a raft of certificates and a large daily price tag.

All in all, the Technology team are feeling pretty good about themselves. The business feel's great too because it's got a story to tell to customers and investors. Much back-slapping ensues.

Six months later, Jake wakes up in a cold sweat during the night and realises that they've spent a heap of money, resource and gone through lots of pain only to have slowed development down even further. They've implemented this new delivery model? They've got all the right people? Why aren't they getting features to market faster?

Sound like a familiar story? It's happening all over the market right now - people waking up in the middle of the night, in a cold sweat and going through 'Agile Comedown'. It's the realisation that, you know what? It's just not that easy folks.

So what happened?

Agile is not a magical cure for outstanding technical debt or legacy monolithic infrastructure.

For those reading who don't come from a technical background, let me explain. Every time you release a new software feature, whether that be web, application or something proprietary, you've got to test it. Many of the large-scale older developments in the industry (with many exceptions) were built using Prince 2 style waterfall delivery. This meant that you built and built (and then) tested at the end of what is often a very long project.

These pieces of software tended to be very large, monolithic style 'applications'. This means that if you want to add or change something you need to test the entire application to ensure that what you've changed doesn't break anything, rather than just test the bit you've built works.

It's like replacing a window in your house. You want to replace the window and ensure the window works, right? Ensure there are no drafts between the window and the wall? You don't want to test the ENTIRE house to make sure that fitting the window in your back bedroom hasn't stopped your upstairs landing light from working.

That's what technologists have to do with a lot of legacy products and software. However, in many cases instead of it being Jimmy's ground floor apartment in Soho, it's a 90 floor uptown skyscraper.

So what really happened?

The team moved to Agile ways of working and everything that they built from that point onwards was of better quality, better engineered and benefitted from all of the well-established benefits that Agile brings to a business - however, it didn't solve the businesses core requirement of speeding up delivery.

Legacy software is often very difficult to change confidently (changing the ground floor bedroom window of apartment 1, causes the 89th floor, apartment 8925 hallway light to flicker when you open the fridge door) which means that the speed of development is by its very nature, slow and fraught with risk.

One of the core principles of Agile is to release every sprint (minimum) and to build, test and deploy during your sprint without any spill over into another. However if the legacy estate is so time-consuming and expensive to test, this breaks the process before you've even begun. This is because it drastically reduces the amount of work a team can do in any given sprint before you need to stop and regression test the changes.

Deploying Agile principles and modern development techniques with legacy systems in place requires your team to have significant Agile experience and maturity. In an immature or even moderately capable Agile organisation, this is likely to create more problems and not even be a partial remedy. How these processes fit in with your existing technology and software needs to be evaluated before your business commits to the move to Agile.