In this article, part of my series explaining better ROI from software development, I’d like to look at the implementation of Agile.
I’ve written previously about Agile in these two articles:
In those articles I look at the principals behind Agile. In this article I wanted to start looking at how you turn those principals into day-to-day actions.
It isn’t uncommon in business to tie your guiding principles to day-to-day actions.
If anything, that is exactly how a successful business should be working.
A business should exist for a reason. We generally express that is a vision statement or similar.
“A vision statement is a company's road map, indicating both what the company wants to become and guiding transformational initiatives by setting a defined direction for the company's growth.” Wikipedia
From that very board high level guiding principle, you would then define a business plan to deliver that vision.
“Why you need a business plan. A business plan is a written document that describes your business. It covers objectives, strategies, sales, marketing and financial forecasts. A business plan helps you to: clarify your business idea.” GOV.UK
That business plan is then broken down into finer granularity as it filters into your organisation and departments.
At some point you will have operational procedures which define the how to perform a particular action. For example you may have an on-ramping procedure for new customers.
In isolation, that procedure makes sense within its own boundaries. However, without the context of the business plan and vision statement, it isn’t always clear what value this provides to the organisation as a whole.
Agile implementation is very similar;
You have a vision; the Agile manifesto as mentioned in my previous articles.
You have a plan similar to a business plan. You actually have a number to choose from – they define the rough shape of how Agile can be implemented.
You then operational procedures in terms of specific actionable techniques which will help to achieve that plan which helps to make you Agile.
The astute of you may now be asking the above question.
If the concrete steps help you to become Agile, should you start there? Or do you set the vision first?
Consultant answer – it depends.
There is no right or wrong way to do this. Each organisation is different and as such it is somewhat foolish to assume that a one-size fits all.
In some organisations, I would suggest they start with their development teams implementing Agile principals and processes locally. Getting used to them, and then expanding out to the winder organisation.
This is certainly the way most organisations seem to have gone – but that maybe due to the maturity of Agile. It has grown up and out of development teams. Only more recently are we seeing organisations starting from the top.
Certainly it can be easier for teams to implement if they are supported and encouraged from the top. One of the biggest problems you’ll find with Agile is when it crosses borders with more traditional project management. There is very little more soul destroying that to have any Agile benefits lost as it is translated into more traditional project management (generally poorly) as it goes up the management chain.
So if I was going to generalise on an approach;
Train everyone from top to bottom on the approach. Gain a consensus behind why this is good and that there is support for it. Then incubate it within a select number of teams and grow it out.
There is such a change to mindset here that this can (and is correct to) take time to establish itself across the organisation. Don’t be surprised if this is years rather than months.
I’m not going to pretend that Agile is the only way to get a successful software project.
We have been delivering successful software projects for years with a variety of methodologies.
And indeed it is also true that some Agile projects fail.
The general consensus though is that you have a higher chance of success with Agile. I’ll dig into that more in a future article, but for now I just want us all to be aware that Agile is not the only way.
And this is the same with the analogy I’ve been using of a vision statement. We all know that we should have a vision statement. We all know we should have business plans and supporting practices aligned to that vision. Their absence however certainly hasn’t stopped some successful businesses.
(Although you have to ask how successful they could have been … we will never know)
This article is rather short for me … but I felt a need for a bridge between the mindset/ vision of Agile and the methodologies and practices that support (or adhere).
In future articles I will look at:
And there are plenty more that can help your organisation achieve that Agility.
Each one of these can help you to achieve a level of capability and mastery within your software development. All are easy to understand, but difficult to master – but the benefits are there to be had.
Regardless of what may have been marketed to you, becoming Agile is not an easy process. The more you adopt it the more it changes the organisation. This can be an incredibly disruptive and expensive process.
I do however feel that the rewards are worth it and I will continue to explore this in future articles.