One highly touted benefit of Scrum and iterative development techniques is the speed with which teams can re-focus. I have seen teams successfully transition to a dramatically different projects over 2 workdays at an iteration boundary. Using the natural heartbeat of iteration boundaries allows teams to move between radically different projects and codebases with lower disruption costs.
The Entropic Nature of Addiction
These truly nimble product development teams are incredibly powerful tools for their organizations. Think about it from an executive or product manager’s standpoint; Having development teams who can capitalize on immediate revenue opportunities is intoxicating. IT organizations have been screaming “No” to rapid change for decades. Now replies are more commonly, “Sure, we’ll do anything you want in the next sprint as long as your backlog is ready.” Product owners get a whiff of that and addiction sets in.
Things go well and smoothly for awhile and the new addicts keep it together for a few iterations. The teams are focused on a particular product and the business folks pump out stories related to it, shifting high priority features around as appropriate. The product gets good quickly because everyone is using iterations properly.
Then it happens. Someone from sales convinces a product owner to re-purpose the development team for just one iteration because Client A will pay $X for a one-off utility. Seems harmless enough. We’re only sliding the timeline for the product release by one iteration and the team is pointedly capable of this kind of re-focusing. Right?
The next thing you know, the team has Sprint backlog items or stories from 6 different codebases defined in a single iteration. They are no longer focused on one responsibility as a team and now they aren’t even able to demonstrate all their work at sprint review because it’s “just maintenance work” and no one’s really interested. The team fragments and apathy sets in. Team members realize that their work is only marginally valuable because there is little focus on an actual strategy.
Really?
Yes, really.
The development team has executed on their strategic goal of becoming truly agile. They are now an incredibly powerful asset for the organization. The business development and executive staff can get heady with this kind of weapon in their arsenal.
And history teaches that power requires responsibility to avoid disaster. It is very easy to wield the tool of nimble development teams to disastrous effect.
If your company has a history of failing to execute on a declared strategy, beware. Although bringing Agile into your organization will make your product development teams powerful and effective, make sure you can trust the creators of your backlog. If you can’t trust them to execute on a declared strategy, you will soon have bigger problems on your hand than getting that 40 year old VB-trained grizzled developer to start using unit tests.