Why Agile?

I feel a little on the defensive recently, I have heard a Product Owner (ex PM) complaining that he could get it done quicker with Waterfall, and I have heard a number of people asking what was wrong with the old way and why Agile?

Short-term memories, fear of change – especially for a very large project manager community – teething troubles with the transition, and a variety of other factors are probably behind it. But long-story short I was asked if there were any metrics on the comparison between Agile and Waterfall that we could use to ‘reassure’ some of the senior stakeholders.

After a bit of research I found an interesting survey: Dr. Dobb’s Journal 2013 IT Project Success Survey. Posted at www.ambysoft.com/surveys/

173 companies were surveyed: The companies were asked how they characterised a successful project. Only 8% considered success to be On Schedule, On Budget AND to Specification. Most classed success as only one or two of these criteria.

Based on the criteria listed above and even knowing that success may be just one of those criteria, only 49% of Waterfall projects were considered successful compared with almost 2/3rds of Agile projects considered outright successes.

When considering failed projects (projects that were never finished) nearly 18% of Waterfall projects were deemed failures compared to only 6% of Agile projects.

Finally Projects that were considered challenging in that they were not deemed successes but were eventually completed.

Ultimately in my opinion “Why agile?” is the wrong question. The questions should be “How can we improve?” I believe that Agile is a philosophy rather than a Methodology. I’d go so far as to suggest that if an organization has a desire to continually improve and follows through on that, then they are ‘Agile’ regardless of the methodology they use. And a company that follows an Agile framework without a desire to improve is not.

In other words ‘Agile’ is the answer to the question not the question itself. If done right and done with the right intentions Agile can help many organizations improve and improve further. Agile is not a destination.

Impediments

As a Scrum Master there are all sorts of things that get flagged as impediments that you are expected to resolve, some trivial some simply impossible.

My favourite of late was in a planning session, a member of the team said “please take this biscuit away, I have had far too many” I stepped in seeing an impediment to remove and … ate it. Once again balance restored and my duty done!

But looking back I think the most persistent impediment is recruitment. Most of my teams over the last few years have been composed of a good proportion of contractors and/or growing teams. There always seems to be more work than we have developers. I have recruited an average of 3 people a year for the last few years, sometimes spikes of recruitment sometimes just the odd replacement. But recruitment is time consuming. For each person hired, 4 or 5 are interviewed, for each person interviewed there can be 5+ CV sifted and considered.

I estimate each new hire consumes close on a full week of effort when you factor in interview time, preparation reading CVs and chasing recruiters, and often of more than one person involved in this process.

The bigger cost may be the impact on the team, a new person is disruptive, they change the dynamic of the team. They are unknown and may or may not live up to expectations.

Retaining staff is hard, the Inland Revenue continues to make life difficult for independent contractors and they are fearful of the implication of long contracts, and a buoyant contractor market means they can move around easily. Recruitment of permanent staff is much harder and a slower process. In the Civil Service because of the austerity measures permanent employees face an assurance of no pay raise or bonuses for the foreseeable future and the offer of below average wages. I still see the occasional good candidate but pickings are slim.

Odd requests

Busy week this week so I have not had opportunity to finish my notes on the Product Owner role, but I’ll come back to that soon.

But I thought I’d do a quick post about some of the odd requests you get as a Scrum Master. A couple of the team have been asking for alternative ways of updating the task board. Post its are not sticking well enough and one or two fall off (post it branded ones) if I use the unbranded ones they all fall off overnight. Index cards and blue tac is a pain.

One of the team suggested magnetic index cards. I did some research and didn’t find anything suitable. But then I found a place where you could have postcard sized fridge magnets designed and printed. They looked just the thing, so I spent my Friday evening designing fridge magnets that resemble index cards and ordering a few packs. The printers will think I’m crazy no doubt. My wife certainly thinks I’m odd – spending my Friday evening making coloured index cards.

I’ll post again when they arrive.