How can corporations best fight atrophy?

I was listening to a podcast a while back* by Ried Hoffman (who started LinkedIn and Paypal) and something he said got me thinking about corporate atrophy**.

Ried mentioned how easy it was for Paypal to out maneuver the larger banking bodies during the startup phase. They were busy testing the legal definition of a bank with their online offering and the banks were squirming and nearly powerless to respond. In fact some of the banks online counter offerings took in excess of 12 months to deliver... as Ried correctly points out, thats an eon in internet time!

Just how did the banks get to this lethargic state?

And how can they (or any large corporate body for that matter) hope to compete in this rapidly changing business environment.

More to the point, How can corporations best fight this atrophy?

*For Rieds Podcast: http://edcorner.stanford.edu/authorMaterialInfo.html?mid=1650 
** Definition of atrophy: http://www.thefreedictionary.com/atrophy

I posted this question in LinkedIn and got quite a few interesting suggestions back:

Mergers & Acquisitions
>>Let others take the big risks and buy them up when they look promising.

Various forms of Internal Entrepreneurialism
>> Google have an interesting internal policy where they allow thier employees to use 20% of their worktime to work on anything they want. They have enjoyed an enormous amount of success from the projects resourced this way.

9 Top Tips for starting an Agile Project

1. Set-up a planning session with the project sponsor... get them to share the vision... identify  the Success Criteria (I.e. the conditions under which the vision will be considered realised)
2. Use Rob Thomsett's project success sliders to define the degree of flexibility in the different dimensions.
3. Derive SMART Objectives (Specific, Measurable, Achievable, Realistic and Timely)
4. Create a Product Breakdown Structure
5. Turn this into a Product Flow Chart and use this to communicate the project roadmap to both the team and the sponsor.
6. Use Mike Cohn's planning poker to estimate the relative weighting for each of the main products on the roadmap.
7. Establish a burndown chart to track 'speed over ground'.
8. Propose that your project sponsor gives the status reports on the project.
9. Re-plan the project regularly.  Keep checking that the project goal is still the same (i.e. progressive elaboration)

7 SCRUM insights from Jeff Sutherland and Jens Ostergardt

Jeff Sutherland, the inventor of SCRUM and Jens Ostergardt, the 1st SCRUMMASTER, were keynote speakers at the APN in Auckland last night.

Here are a couple of salient points I took from the talk:

• Jeff was a fighter pilot in Vietnam (Sydney 1967) and flew over 100 missions! This along with Jeff's subsequent experience in medical sciences seems to form the backdrop to the pre-scrum thinking. Jeff said he came up with a process that is in a constant state of response to impediments.
• Jeff appears to be a scientist at heart with an evidence based way of getting his point accross. One of the stats he mentioned was that an average 63% of features change on development projects... I'm still digging for the reference for this... will post it shortly.
• When coaching senior management teams Jeff seemd to emphasize the need to "surface impediments". He cited a great example of a Danish company that was level 5 on CMMI with excellent control over processes. This was used as the test bed for determining the productivity differences between SCRUM & Waterfall... needless to say SCRUM kicked ass ;-)
• Read the MIT iRobot story. I loved this story as it really brought home the need to establish the learning process with simple rules... The world is the database... simple rules give rise to sophisticated behaviours!!!
• Jens gave some valued advice for new ScrumMasters:

1. Don't get fired,
2. Resist the urge to 'help' the team
3. Don't use a SCRUM tool at first! (Help the team find it's feet (low tech) before introducing tools.)

• Jeff seems to enjoy applying Root cause analysis for SCRUM issues... Let the data reveal the causes. He gave one of his Polish companies as an example. The company in question had been advised to implement integration testing... this was ignored and later identified as a root cause of the ensuing spate of iteration failures.
• Lack of integration testing was identified as a major impediment to getting to DONE!

Hope you enjoyed this installment... If you attended the event too please feel free to add your own take on the talk!

This event was arranged by Edwin Dando from Clarus Consulting in Christchurch. A real win for the New Zealand Agile community I'd say!!