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.
I came across a post proposing that Washington State agencies adopt agile ideas to track projects:
Our message: stop trying to track project progress by analyzing task level detail (estimated vs. actuals) and instead adopt agile, track velocity, and use empirical measure to predict completion dates.
This sounds like a great idea, and my past history doing a lot of professional service contracts for California state government agencies would suggest that California has the same very broken RFP process.
Essentially the process goes something like this:
- Agency sends out an RFP proposal for some IT system.
- As a consulting shop you either prepare to respond if you knew something about it beforehand. Otherwise as a blind RFP you assume your chances of landing the work are minimal. If your pipeline is pretty dry and you have some people on the bench you’re more likely to respond despite the low odds.
The RFP is generally pretty sketchy on the requirements, but it does make clear that you must include a detailed Gantt chart with lots of tasks, deliverables, and dates.
Sometimes as an added bonus the RFP explains that you must use RUP or the IEEE Software Development process or at least follow all aspects of the PMI’s PMBOK.
And of course it’s always a fixed price bid, so you do the following:
- Throw together an initial plan and cost it out. This often comes to more than a million dollars since there are plenty of unknowns in the RFP.
Then decide what the agency actually plans on spending which is usually say $200,000.
Somehow work down to just under that number.
- Then hope that you’ll be able to negotiate the scope of the requirements once you land the job.
Assuming you actually land the job, at some point you end up working long unbillable hours for free to deliver something that meets their baseline requirements.
- They’re very impressed you actually delivered something, but they don’t have any budget authority to hire outside consultants again for another two years. It’s a horribly broken system which allows for a lot of expensive, time consuming failures that are bad for the state agency and bad for the vendor. Unfortunately given the pace of change and the unfortunate push for the lowest bidder in government IT projects I don’t see it changing soon.
The perfect world would allow a vendor to get hired in based on experience and quality of staff. Then try out the vendor for a Sprint or two at low risk and low cost. If it doesn’t work out fine, let the vendor go and find a new one. If it does then sign up for a longer contract or even just continue to evaluate every Sprint.
Victor Szalvay has pretty much the same suggestion:
We were asked how this would fit into today’s Washington state RFP mechanism which requires detailed up-front task plans. I asked the audience at large if this task-based approach currently yields successful results. Judging my the silence and the shaking of heads, I’d say the Washington state government is ready for real change. I suggested they hire vendors that make short-term iterative commitments, pay those vendors based on delivery of the short-term commitments and fire those that do not.
If I ever return back to the the state or local government sector I’d want to work for a CIO who was willing to try this. Given that the Agile movement seems to be catching on overall maybe we’ll see Scrum in government before too long, but there are a lot of institutional issues to overcome.
I spent some time evaluating tools like Rally, ScrumWorks, and XPlanner about 6 months ago. After investing some time with XPlanner and some configuration hell, I dropped it after a few weeks on a Sprint because the workflow was more of a headache then just using corkboards, index cards, and Excel.
In another little bonus from the Certified ScrumMaster course I bumped into Victor Szalvay, one of the founders of Danube Technologies the creators of ScrumWorks. He quickly informed me that they had dropped the licensing on ScrumWorks and now offered it for free. Definately back on my list to check it out, especially now that I’ve got a better idea of what we need in a tracking tool.
After two days of ScrumMaster training with Ken Schwaber I’m now a certified ScrumMaster. The granting process also involves a secret handshake and greeting, which I’m not able to divulge here. The whole ‘certification’ is sort of an inside joke since Scrum is a very lightweight set of project management practices. I did learn though that out of 3000+ certified ScrumMasters that one ScrumMaster has been officially stripped of their certification for completely failing to protect their team, so it is possible to really blow it and get decertified.
I have 30+ pages of scribbled notes now to review. I met lots of really motivated people which is really a nice environment to go through in a training class. Most classes have a certain percentage of people who just really don’t want to be there, and their presence just brings down the whole class. I’d recommend the experience or at least Ken’s version wholeheartedly as worth the investment.
The first day of ScrumMaster Training with Ken Schwaber has been a blast. I’ve got about 10 pages of good notes on Scrum approaches and new things to try already. The class is fairly interactive, but the exercises have been pretty relevant. One involved moving people out into a hallway and just having everyone line up in a continuum from zero to ten on questions of how much you love your job and what your experience with Scrum is. I fell in the 8-9 range which put me alone with a consultant who does Agile development and a Microsoft XBox developer who codes games all day. The low person at zero has been doing Sarbanes-Oxley work for two solid years. The continuum approach really worked better than asking the same questions of the class because you could visually see where people mapped to and you could ask the people around you questions to determine if you were really at the right place in the line. It reinforced Scrum’s obsession with team interaction and feedback.
There are a ton of Microsofties in the class, about 20 in all and based on the ones I’ve gotten a chance to talk to Scrum at Microsoft is still largely a bottom up affair where individual teams at Microsoft have started to adopt it. Management at Microsoft hasn’t really blessed the approach despite it’s recent inclusion in Visual Studio. I asked a few Microsofties about how they handled coordinating multiple Scrum teams with the Scrum of Scrums approach and they explained they weren’t aware of anyone at Microsoft trying it yet since it hasn’t seeped that deep into any of the groups they were aware of.