Like watching a yoga expert balance on their head, being agile might look simple to the untrained eye. However, if you try to achieve that move gracefully for the first time, without the necessary preparation, you are sure to fall flat on your face.
There are certainly a few IT professionals that have suffered this fate after assuming that following an Agile philosophy would be easy. Far from it. In order to do Agile, you need to be Agile, which can only be achieved by a change in mind set and cultural approach that spans the entire organisation – not just those tasked with working in this way.
> See also: Agile at a distance: how distributed teams can consquer agile
Like many in his position, 'Bob' and his team have been tasked by their CIO to take an Agile approach towards their next IT development project. But how will he fare and is it as easy as he thinks to 'go Agile'?
A typical scenario
When it comes to deploying the principles of an Agile philosophy, there can be several stumbling blocks to overcome in order to get it right. The first question that Bob (and the Board) needs to answer is not 'how to do it' but 'why'? Just because it’s an overused term doesn’t mean you too need to jump on the bandwagon.
Taking a Waterfall approach to development, where progress is seen as flowing steadily downwards through the different phases, can still be a viable option in some cases, and businesses shouldn’t be too quick to throw away the investment already made in people, processes and resources in this area.
Improving quality of delivery and reducing time to market are typically the main reasons behind adopting Agile, but unless this is realised and communicated to the whole team, then getting buy-in to a change in approach will be difficult. It needs to become a business-wide philosophy and not just an ad-hoc approach. This is where Bob will encounter his next problem …
Agile is not properly supported within the organisation
We typically see two approaches when it comes to adopting agile. Firstly, bottom up or agile by stealth – driven by the developers and the 'doers' who see it as a better way of doing things, but don’t get the support required from the business to take the approach forward.
In this scenario, Agile principles are applied in pockets and, as a result, they can’t scale and so max out at a low level. Integration and connection with other departments is hard, so the approach can become isolated and cannot be adopted company-wide.
Secondly, (as experienced by Bob) Agile can be driven from the top and supported by the C-levels who decide they want to 'be Agile'. Whilst this sounds great, in practice many can then leave the doers to get on with it without providing any input or direction. And so the approach never really gets off the ground since there is little reasoning or support behind it.
Neither approach works in isolation and unless there is a meeting of minds and good collaboration between the C-levels and development teams, Bob will struggle to deliver the project in the way he and his managers envisage – he will fall at the first attempt. The next hurdle can be…
Having the right team in place
Despite Bob being a highly experienced software developer, applying Agile principles is something new to him. He understands the reasoning behind it, but does he have the right skills to deliver what is required? Simply rebranding the development team and putting them in a new environment won’t work: there needs to be a good fit and an understanding of how Agile can add value and can be used across all areas of the business.
This won’t be right for everyone and there might be resistance to change, which is why buy-in and support from all levels is so important.
Processes will need to change
This will require a change in mind set from the team. The Waterfall approach that Bob is used to, which often provides all or nothing, is worlds apart from an Agile little and often approach.
Instead of a phased approach with big up-front design, development, coding, testing then roll out to market, Agile delivers highest value, highest priority features first meaning teams can quickly and easily test market demand and need. By taking this inspect and adapt approach, changes can be made along the way to ensure that the project delivers the right things, to the right people, at the right time.
> See also: How agile development can run in parallel to traditional IT management
As a result, Bob will need to undergo an about turn in his thinking of the principles used in the waterfall approach to those processes that now need to be adopted. He will find that the command and control approach that he is used to will become much less appropriate in the trusting and empowering environment that he now has to cultivate.
By understanding and getting over these key stumbling blocks, Bob will give himself and the business the best chance for success.
Learning from Bob’s experience
Adopting Agile is more than just a change of processes. It requires a cultural re-think and new development philosophy. Its success relies upon a tight relationship with the business and taking a lean approach to development to identify and drive-out waste and inefficiencies.
By not considering or addressing the typical issues described here, problems will ensue. Agile is a thought-process, which has to be embraced by the whole business. By working with a specialist to help provide the coaching, framework and tools to deliver an Agile change programme that meets quality and efficiency expectations, businesses can reap the benefits more quickly and more easily.
Ultimately doing Agile requires the whole company to be Agile. That certainly would have helped Bob from the start. Had he known this from the start, perhaps the process wouldn’t have been quite so prolonged and painful.
Sourced from Jerry Stubbs, associate director, head of agile services, SQS
