There are three distinct “use cases” for employing Agile techniques. They are based on different business challenges. They should be addressed by different Agile processes. If you don’t know which one you are, you are probably doing it wrong.
The three use cases are:
- Long release cycles of 3, 6, or 12 months
- Online apps (Web, SaaS, enterprise cloud, big data, centrally deployed)
- Developers servicing multiple clients or projects
Earlier this year Assembla formed the “Scalable Agile Design Group,” a collection of senior managers of development groups at 12 companies with extensive Agile experience. We created the group to learn more about the common issues facing Agile companies.
We were surprised to find that there is no one common set of issues. We found three distinct types of Agile companies. Each has a different set of pain points and priorities. Each focuses on different processes and tools to address those priorities. They were almost talking different languages.
The conclusion: knowing your use case will tell you what parts of Agile to emphasize and what parts to ignore.
Major Release Developers
“Major Release Developers” are development organizations that work on long-term projects, typically with release dates three or more months apart. Often they are building classic “enterprise” applications. Teams are usually assigned to one project for months, or even years.
These organizations can reap gains by using classic Agile techniques like sprints, scrum masters and product owners who provide customer input on a daily basis. They make extensive use of Agile training and Agile coaches to inculcate Agile principles and improve coherence within teams. Essentially they are focused on maximizing team efficiency across long-term projects that do not deal with frequently changing requirements, bug fixes, etc.
Most Agile textbooks are written for this use case.
So doesn’t this reflect almost all Agile development groups? No, not at all.
Cloud Application Developers
“Cloud Application Developers” maintain web- and cloud-based applications, and release new functionality frequently. They include organizations supporting web sites and web-based applications within an enterprise, SaaS companies, and major “cloud” services providers like SalesForce or Google.
These companies are driven to:
- Release new functionality frequently, sometimes several times each day.
- Reduce cycle times, to react quickly to customer and marketplace feedback.
- Automate processes to reduce the burden of frequent releases.
Scrum is actually a bad model for these companies. It prevents them from releasing any more frequently than the end of each sprint (typically every 2-6 weeks). They can’t easily handle tasks introduced in the middle of sprints, no matter how high the priority. And they create a lot of overhead with planning meetings, scrum-of-scrum meetings and retrospectives.
Instead, these companies gain the most by emphasizing:
- Kanban and lean techniques.
- Continuous integration, including automated builds and automated tests, and continuous delivery.
- Collaboration tools for distributed teams, to take advantage of the global market for development talent.
“Multi-Project Developers” is the third use case. These groups work on many concurrent projects and move teams among them. Many are service providers and custom development shops, but they also include IT groups that service multiple business units inside an enterprise.
Because these organizations are constantly moving teams around and reconfiguring them, Scrum doesn’t buy them much.
Their challenges revolve around resource management. They need to pay close attention to capacity planning and resource allocation across projects (especially for people with scarce skills). They benefit from frequent, low-friction communication with client organizations. They also need to onboard new developers easily.
The tools to address these challenges include ticketing and planning systems, collaboration tools, and tools that allow customers to provide rapid feedback and track the progress of their projects.
Some Have Two
We found several Scalable Agile Design Group members that had more than one use case within their company.
For example, part of the organization might be working on an enterprise accounting application (the Major Release Developer use case), while another part is working on web sites or data warehousing projects that need to make changes on a daily basis (the Cloud Application Developer use case).
These companies found, sometimes to their surprise, that Scrum teams would take root in the first area, while Lean techniques thrived in the second.
What Does This Mean to Me?
If your group fits the Major Release Developer use case then you are probably in good shape staying with the classic Agile textbooks.
But if you are a Cloud Application Developer or a Multi-Project Developer wondering why Scrum hasn’t brought you very far, then you should look at some of our blog posts about Going Beyond Scrum, Continuous Delivery, and Scalable Agile.