“Agile works really well with a team of experts.”
— Ken Schwaber (ScrumMaster Training)
“I’ve read up on this Agile stuff and it was designed for a team of experts. So we shouldn’t start sprinting until we’ve figured out Websphere. We can just use our usual process until then.” (Our usual process is a waterfall.)
— Sysadmin at my company
Common advice with managing experts is to relax and just get out of their way. Therefore Scrum and any Agile methodology naturally accentuate this strategy. They’re designed to cut the process down to a minimal level and let the team self-organize. Then the real world steps in.
Try putting together an expert team. Sure you may have a few experts on a team, but unless it’s a really high profile project, you can’t pull all the best experts at your company and staff them on the same project.
So you sub-optimize. You get maybe a really good PM/ScrumMaster and a really experienced tech lead. You have a few less senior people on the team who are going to need some help with learning curves. Maybe you have almost all senior developers on a project, but you ask them to work with a completely new toolset/language/framework where they’re not experts.
Sub-optimal Scrum is still a lot better than the typical waterfall. At least the nasty learning curve or other difficulties are taken on as a team and built into estimates and adjusted as you go. And if you want to put a whole team of novices on something then you’re bound to fail no matter what you do.
The second quote from one of our sysadmins should probably be better explained. Their experience was with a ‘Scrum’ project that was pretty much Scrum in name only. The standups regularly went 30+ minutes, there were effectively two ScrumMasters and two product owners. You can get in way over your head on a project using pretty much any methodology.
Technorati Tags: