Can you be an agile technology team in a non agile company?

So you want to be agile, but you’ve been in business for years and work waterfall.

It’s simple right? Just call your development teams squads, and use JIRA, don’t forget to buy a load of post-it note. Well done, now your Agile!

Of cause it’s not as simple as that, becoming Agile needs a fundamental change in the philosophy of the company, it can’t be something that is driven by IT – if the rest of the business isn’t bought into the process it’s not going to work.

Here are some of the steps needed to get your organisation to become Agile, as well as some of the cases you can use to convince the other areas of the company to make the switch with you.


Let’s start with the most difficult.

Your business running well and is profitable, it does this in two ways
1) charging an annual licencing fee to users
2) charging users for change requests.

The annual licencing fee is probably covering the cost of ‘keeping the lights on’ whilst the change requests are what brings in the profit.

Now the users are businesses too, and to approve a change request they want to know how much it will cost, what they will get and how long it will take before they agree to pay for anything – all of this goes against Agile ways of working.

Commercial is used to this method and sees no reason to change, after all it’s worked up to now and if it’s not broken don’t fix it, right?

The problem with this is not only that it isn’t Agile, but that it leads to bad software design. If I’m the user and I have a change, often I’m not prepared to pay for the solution to be built right – much cheaper to get a sticking plaster put over what we already have.

Commercials see this as just a side affect of doing business, after all we are still making a profit right? The sticking plaster doesn’t take as long to build so we can do more change requests – which is good right? We give the users more of what they want

Again, wrong. A sticking plaster might help you in the short term, but it makes maintenance and future development more difficult – it’s a very short term way of viewing your product and if you are not careful in 10-20 years time you’ll find that doing anything new to your product take 10 times longer than it should due to the mess of interdependencies that you’ve built.

So what do you do?

The first step is to convince your commercial team the switch from two income streams to just one. You need to convince them to simply have a single annual maintenance fee and to stop charging for change requests.
But the customers won’t go along with this right? Wrong.

Yes you’ll have to increase the annual maintenance cost, but from now on users will get changes for free – this makes it much easier for them to get budget sign off in their own company, as well as no longer having to make do with gaps in the software because they cannot justify the cost of the change request. This has a second positive effect, since you no longer have to worry about getting sign off for change requests you can do those changes that will make your product better, but nobody would ever pay for. Finally a third benefit of this is the ability to make a better choice for the product. Under the change request model if the user requests ‘the ability to download a document that customers can sign’ then this is what you will build as this is what they are paying for – whilst if this is just suggested then you can make the better choice to provide them with e-signatures instead.

This simple change means you never have to sticking plaster your changes, you can always concentrate on building the right product from the start.

Customer Relations

So, you’ve convinced commercials to get on board, now we have customer relations.

They have another problem for you – customers submit a change request and have a time deadline for completion, what do you do?

Well this needs a careful change in the language and the way you handle your customers. First, it’s important to change the wording from ‘change requests’ to something like ‘customer suggestions’

This is important, a change request is something a customer expects to get done, but a suggestion is just that – and it’s you as the product builders who will decide if you action the suggestion or not.

Now customers won’t like this at the start, they want something built to their timetable – but they can no longer throw cash at you to build it for them. Obviously you don’t want to alienate your users, if you ignore their suggestions too often then they will look elsewhere, fail to meet some of their deadlines and they might also go elsewhere. However once they start to see that you are building better software, that functions well and that you are building the best product, and not what the customer with the largest cheque book whats them most soon come around – and this will lead to happier customers.

And those customers who arn’t happy with it? Well you have to ask yourselves if you want a customer how is going to drag your product down and stop it being the best in field.

Again this is about taking a long term view. Building their change request makes them happy for 5 minutes – until their next request anyway, but building a good relationship with your partner’s (another good change of wording) is much better in the long term.

Project Management

Project management can be one of the most difficult areas to convince. Unlike the other areas Project Management can feel like the changes you are going to make will put them out of work. With users no longer having change requests with budgets and deadlines that need to be monitored then what is the need for project management?

It’s a difficult question, and sadly in many cases it will be the case that project management becomes the victim of Agile ways of working, but that doesn’t have to be the case.

With your new ways of working your going to have teams working on changes that improve your product – no more watching deadlines. This doesn’t mean that deadlines don’t exist however, legislation is often changing – a customer might have a deadline so important that missing it would cost you a client – you might be looking to break into a new market and need to meet an internal deadline to avoid missing out to competitors.

Maybe the end goal is a series of products that spans work across multiple business areas – whilst Product owners will look after their own product, it is a project Manager whos role it is to keep an eye on the end goal.

What ever the reason it’s Project Management who need to see this through – they need to feed these requirements to the product owner and it is them who need to keep checking that the work is on schedule. Over time these new ways of working make their job much easier – by building the product right and focusing on what is best for the product then when these requirements come in you’ll be in a much better place to compete them on time.

I think I’ve hit you enough for one day – but hopefully you have found this interesting and can use this to make your switch to Agile a success.

Leave a Reply

Your email address will not be published. Required fields are marked *