Share this
by Ray Cooke on 16 February 2015
What is 'Agile' and why should you care?
I’ve been a Software Development Manager in one form or another for many years and I definitely wouldn’t consider myself an early adopter when it comes to 'Agile' techniques. With hindsight, this isn’t necessarily a bad thing. Frankly, my teams were delivering software whether I was using a visual board or not and whether I had a Scrum Master on the team or not; not necessarily as efficiently as they could, but we were still getting work done.
I first came across 'Agile' when I was searching for ways to resolve some problems I was having with project delivery through my team. Considering how much effort we were putting in to our work, and we were flat out and putting in plenty of overtime, we didn’t seem to be making a lot of headway. To compound the problem, I was getting complaints from stakeholders about excessively large estimates, late delivery and production defects. Fundamentally, failure demand was killing us. So my first look at agile techniques was through the lens of improving quality and getting the defect count down.
Like anything new it takes a while to work out why it’s useful, where it fits in with what’s in place already and to iron out the kinks. Agile techniques have now had that time – we’ve tried lots of experiments and learnt lots of lessons and so there’s a much wider and clearer body of work we can use and apply, and, most importantly for me, not just in green-field companies and projects.
Is there any evidence?
According to Gartner, project level agile software development has been through much of the hype cycle. You may remember or have experienced a few years ago the over-stated hype about agile from early adopters, with a shortage of tangible value shown, followed by general disillusionment when the initial reality didn’t live up to the hype. Now it's had some time to develop, Agile is out of the trough of disillusionment and is climbing the slope of enlightenment, where it is becoming widely adopted as a mainstream approach to developing software.
Agile software development on the Gartner hype cycle
As it becomes mainstream, agile is no longer isolated to one or two projects within organisations. The 2013 State of Agile Survey, conducted by VersionOne (the most current available version), shows that agile is being used on more and more projects within organisations in the US and Europe (43% of responses indicated that agile is used on 10 or more projects, up 13% from the previous year).
Why Scrum?
I’ve often found that picking and choosing what works best for the situation I’m in at the time works better than wholesale adoption of a methodology, especially in an existing company. That being said, in adopting new methodologies it is key to ensure that everyone has a common understanding of what you’re trying to achieve and how and when to apply it. It’s very helpful therefore to start from a common base, and one that has wide-spread adoption and buy-in such as Scrum means that your team may well already have some familiarity with the principles and there is plenty of material and training available both freely and from experienced practitioners on the market to help pick it up.
Scrum and its variants continue to be the most commonly used approaches to agile software development. In the 2013 State of Agile Survey, 75% of the respondents indicated that their organisations use Scrum, Scrum with XP or Scrumban. Even at Equinox IT, while we don’t follow pure Scrum, we have adopted many Scrum practices in our approach, which most closely aligns with Scrumban (a mixture of Scrum and Kanban).
Learning Scrum
Again referring to the 2013 State of Agile Survey, the results found that those organisations that have successfully scaled agile beyond a single team said that the biggest success factors were executive sponsorship followed closely by training.
We at Equinox IT agree that training is important to really learning the principles, practices and shared language of Scrum. It’s like learning the road code for driving – without it you can’t get on the road but then once you’re on the road, the learning and the progress really starts. Oh, and obviously not knowing the basic rule set on the road before joining all the other drivers doesn’t make for accident free journeys!
As with learning to drive though, training is clearly not the full story. Understanding the road code doesn’t make you a good driver. You just have the knowledge, the fundamental knowledge, to start playing the game, and playing the game is where the real world ‘how do I make this work in practice’ learning will begin to happen. Doing so with a continuous improvement mindset will ensure you and your organisation get better and better over time, to the point where this becomes an important competency that delivers success.
