Agile: Stuck in the IT Ghetto? 

I’ve rarely had a problem with getting business engagement in my deliveries, in fact it’s usually the opposite – too many different voices!  So if other very good Agilists had a problem is there something else going on?

Having started looking, I saw more and more of it, some patterns formed and I have come to the conclusion that in general Agile is stuck in the IT Ghetto and is finding it difficult to break out.

This has come about because in some ways Agile is a victim of its own success – it’s completely won the argument in the software engineering community. All modern development environments are based around eXtreme Programming concepts and all decent Computer Science courses assume XP. It’s also now rare for a software vendor to develop any other way, most commercial websites are pushing into “higher order” engineering techniques such as Continuous Deployment.

The problem is that I have heard many senior business people say that “Agile as IT’s thing” and are happy to “let them get on with it” provided they stick with established governance and by implication culture. This sets the organisation up for friction and the Agilists for frustration.

This is even the case in some high profile Agile references: Sky advertising for Prince 2 project managers a couple of months ago shocked me until I asked some pertinent questions.

So what can the Agilist do? Here are my ideas:

1. Constantly re-enforce the benefits of Agile in hard business terms; better return on investment, reduced project risk, improved transparency, better testing etc.
2. Use language with the business that they understand. Business people understand what timeboxes are; sprints need explaining.  Scrums are done by sweaty people (usually men) in gladiatorial combat; stand-ups do what they say on the tin.  If there was a need for a different language (to demonstrate a break with the past) its time has past.
3. Fix the obvious holes in management / governance.  In the real world there are business sponsors who expect their money to be spent with control and reporting.  Accept it and propose Agile governance techniques from e.g. DSDM that minimize the overhead and align with Agile values.
4. Split the Product Owner role into day-to-day person and strategic / senior person.  In most organisations it is unrealistic to expect someone that has the time to work with a development team to have experience and responsibility to provide strategic direction and decision making.  An additional more senior person can also help protect the team from interference.  One pattern I have seen is that rigidly enforcing a single PO can have the undesireable effect of limiting business engagement.
5. Have the courage of your principles: stop working on projects without business engagement.  Try to find a good excuse e.g. a tricky prioritisation call, but turn the project status red.