Agile adds Discipline

I have often found that corporates are prepared to spend huge amounts of money to maintain control and manage risks.  Risk is typically calculated as the product of probability of the risk materialising and Impact of the risk materialising.

Agile approaches to Software development and Remote Developers are often avoided as mechanisms because of several misconceptions about Agile that organisations view as risks:

  • Agile teams don’t plan.
  • There is no design in the Agile approach
  • Agile teams do not test.
  • Agile = no documentation.
  • Loss of management control

(Note that all of these are untrue)

The statistics on Adoption of Agile are compelling, with 83% of the organisations surveyed (Versions One’s 7th Annual State of Agile Dev Survey) saying they would definitely do Agile Projects again, and 70% saying that Agile allowed them to Deliver projects faster.

So why the resistance?  I’ll answer that subjectively first by saying I was a skeptic until I saw one Agile project work well:  Now I am a convert.

What about the remote workers?  The survey showed that Agile was also useful in managing distributed teams very effectively.   The fact is that your developers sitting in the office could just as easily skive-off while they are at their desk.  They get interrupted by noisy colleagues, adhoc meetings and the daily commute.

The origins of Agile are in OpenSource distributed teams, creating a process to allow them to work effectively together and deliver productively.  This takes discipline! The Cynic in me says that corporate software development teams do not want that amount of discipline – it’s hard work.  And it seems to have been easy for them to convince management that this Agile thing is no good.

“To say that companies or CIOs are reluctant to embrace agile is like saying they wouldn’t take aspirin for a headache….And they’re not only not taking the aspirin, they’re banging their heads against the wall and wondering why it hurts.” – Jim Johnson, Standish Group Chairman

On the distributed team issue, surely it makes sense that the very best people for a given project may not all be located in one place, or near your offices. Why limit yourself to the resources near you?  Why not get the benefit of the best the world has to offer in a given technology? We now have the mechanisms to help them work effectively together with the internal teams, but we need to follow the disciplines to get that benefit.

I would challenge any manager of an IT team that includes software development to read these survey results and remain skeptical.  🙂


Posted in Management | Tagged , , , , | 2 Comments

A brief look forward

Here are the slides I presented at the Enterprise Risk Management Africa 2013 conference.

Hopefully I’ll find the time to comment soon.



Posted in Management | Leave a comment

Our New Google Appliance Arrived!

The customary unboxing and installation post:

Posted in Technology | Tagged , | Leave a comment

Storytelling: A tool for Communicating Vision

A while back I created this story to communicate our vision to the internal infrastructure team of the organisation I was with at the time.  It is written as a fairy tale complete with magic lamps and genies.

Many people thought it was lame, but I believe they understood the principles after reading this… and here it is:
Continue reading

Posted in Management, Strategy | Tagged , | 2 Comments

Software Factories: Part 4 – Measuring Outcomes

[Software Factories Series]

One of the difficulties with implementing a software factory is measuring development-team performance. Depending on the culture of the team, and the desired outcomes for your team, the approach may be fundamentally different, but here is an approach I have implemented, that I believe is fairly unique in a corporate environment.

Continue reading

Posted in Management, Philosophy, Strategy | Tagged , | 8 Comments