Introducing agile in a corporate environment

It's been a while now since we first started talking about agile in our organisation and we've come a long way since those first formative discussions around the number of sprints we'd require and how we'd clear this with the 'governance police' ! It's fair to say that a few things came together at that point which helped me push agile as a viable option -

1. The business were in the middle of a difficult and painful implementation process for a couple of large projects.
2. We had inadvertently employed a qualified scrum-master as one of our developers.
3. As a delivery organisation, we were considered expensive and slow.
4. An incoming CIO was a known fan of agile.

If so much as one of the above hadn't been the case, i'm not sure we'd have been in with a cat in hells chance of doing some work in an agile way. But as it happened, this created a 'sweet spot' where we were able to gather together some of the key stakeholders and gain approval for our first 'agile' delivery.

Some might say it wasn't agile at all - we already had business requirements and 75% complete high level/logical design documents, some of which would have included screen mockups. But we soldiered on - we organised a scrum team, planned a number of 2-week sprints (15 if I remember), created the product backlog and got started.

Unfortunately the project was canned after a few sprints due to funding issues, but in that short time we'd learnt an awful lot.

1. The business really enjoyed the regular demos  and were keen to attend.
2. We rattled through delivery at a fair old rate of knots.
3. We cost about the same as our existing part-offshore development.
4. Although we'd flattened the development team structure, everyone (without exception) loved working in this way.

It was a while before we got the opportunity to work in this way again but it was on a similar sized project - a single team of 6-9 people, anticipated to run for around 30 weeks. We are actually going live this weekend, so my enthusiasm may be a little premature but some interesting items of note:

• we are on time
• we are within budget
• we found and overcame some significant issues with the system which we were enhancing
• we have adapted to new requirements and discarded those which are no longer required

Ultimately we've seen the same sort of positive outputs from this project as with the previous and I see absolutely why this has happened. We have simply gone back to the basic 'get the right people together and let them get on with it' approach. And therein lies a little problem ..

If we find this approach works, what we're really saying is that all the huge governance and management structure around these teams, the layers of analysis, design and architecture which we put beforehand and the QA processes we stack aftwards are suddenly looking a bit overweight for this tiny little team in the middle who have just got on with things.

And if this team are so valuable why do we put them in a corner of the office and spend so little time listening to their complaints about the office environment, their lack of collaboration tools and the size of their monitors? Perhaps we ought to be putting these guys (and girls) first when we get some spare capex, perhaps we ought to be giving them the best desks in the office. And perhaps we should start to consider the value that us managers really add ..