Small software development teams in small companies usually embrace agile practices associated with Scrum, XP, Lean and Kanban more readily than large teams at large companies. That makes sense given the added complications of trying to be agile in a big company accustomed to following a corporate process.
Small teams quickly adapt to shorter sprints, more frequent production deployments, and less big design up front (BDUF). They simply feel more confident in making decisions on the fly and self-correcting as they go.
Large, global teams tend to introduce waterfall characteristics into their agile development efforts. They try to align their corporate practices with agile techniques to achieve the best of both worlds.
Seems logical and reasonable, right?
Yes it does … but no it isn’t. What I’m about to tell you might seem counter-intuitive and difficult to accept but give me a chance to explain.
Large teams should aim for short sprints — 1-2 weeks at most. They should implement continuous integration and deployment practices — not simply deploying at the end of sprints. They should spend less time designing and more time experimenting — forget BDUF entirely.
Like I said, it sounds counter-intuitive but it’s the best way to deal with multiple, diverse, development teams. Rather than get into a philosophical debate, I’ll discuss an example showing why these ideas will work.
A Call Center Example
Let’s say we have a large software development group working on a call center application. To keep this simple, assume the software has three major components:
- Customer Management
- Help Ticket Management
- Call-Center-Agent Workflow Management
Assume we have three development teams and each team is working on one of these system components. Also assume that the teams are geographically dispersed across the United States, Russia and India.
The challenges faced in such a situation are fairly obvious. The three development teams have to be kept in sync. The challenges of dealing with multiple languages, time zones, and cultures will converge into a heavy burden for the teams, regardless of the underlying software development approach.
More Controls Might Make Matters Worse
Many companies react to this kind of situation with more process, more documentation, and more sign-offs. Does this additional administrative overhead really help? In waterfall development, there is simply no way to know the answer until all the code is submitted to SQA for final verification and validation. If problems and discrepancies are discovered, it will likely be too late to address them and stay on schedule.
In a conventional agile approach like Scrum, the teams will likely use 4-week sprints. It will take at least 4 weeks for miscommunications to surface. Once they do, the teams will already be into the next sprint and the issues will go into the backlog to be addressed in a future sprint. It could take 4-8 weeks for an issue to be resolved. That’s not very agile, is it?
The solution is to keep sprints very short — 1-2 weeks. This forces the teams to sync and stabilize often. There’s no time to break the code, re-work it, and repair it. Keeping the build stable becomes a major goal. (Even better, consider abandoning sprints entirely and moving to Kanban.)
Adopt continuous integration and deployment practices. There’s no need to wait until the end of a sprint to release new code into the target build. Get that new code out there as soon as it meets the definition of done. If something breaks, drop everything and fix it. Now! Every team will know exactly where it stands at all times.
Finally, avoid the urge to spend excessive amounts of time researching, planning and reviewing. Instead, write some test code. Try something. Create a working model or a skeletal system. Evolve that test code rapidly and use it to guide future sprints.
Plans and designs are notoriously difficult to manage across global teams. For that reason, keep the plan simple. Keep the software design flexible. And most important, keep the build stable and keep the teams in sync.