One idea I relearned at my recent ScrumMaster training course in Seattle was the idea that Scrum itself is a large catalyst for organizational change. Scrum is a simple set of practices that focus around process improvement using rapid cycles of inspection and adaptation. Ken’s non-scientific estimate was that only 25% of organizations would be able successfully to implement Scrum.
The tough part is Scrum brings a ton of dysfunctional corporate behavior to the surface. When you have 30 days to deliver working software you can’t let impediments like a 30+ day purchase order cycle for new servers get in your way. A lot of impediments around in corporate settings revolve around turf battles. Say the facilities folks won’t allow a team to take over a collocated space like a conference room. At some point as ScrumMaster you have to just move yourself in without permission or raise the issue up the chain until the CEO weighs in on how important it is to maintain a rigid cubicle culture.
Another example is that corporate IT won’t allow any installs of any software by developers so even using a tool like Eclipse or Tomcat requires weeks of lead time to be installed. Someone has to explain to the CEO that the developers are among the highest paid line employees at the company because of their development skills and letting the helpdesk hamstring them because of licensing or security concerns is a tremendous waste of money.
So this week I’ll start challenging the conventional wisdom again with some battles that I’ve conceded in the past.