Let’s face it, technology systems are getting bigger and bigger. Big data systems have moved beyond the lab and entrenched themselves in today’s market place as viable value drivers. These systems and their supporting ecosystems are extremely complex. They are more like aircraft carriers than small gun boats! To build large, complex systems we (the software industry) need to refactor our product development practices.
We often see the following pattern when large (50+ people) programs kick off. Their energy and enthusiasm to use cutting edge technologies drives them towards more modern development practices. That is Agile practices. Unfortunately, they usually try to apply low complexity Agile frameworks and practices to their high complexity environment.
What does that mean? Our experience is they try to apply Scrum and a select few XP engineering practices to manage and deliver their system. Inevitably, this breaks down for a variety of reasons and they revert back to BUFD, Waterfall methods. #FAIL
Their approach to organizing and managing delivery at scale was flawed from the start. We need tools and practices that map to high complexity environments in order to realize value at scale. While Scrum is part of the solution, it is not the whole solution. Its our opinion that the Scaled Agile Framework (SAFe) is currently the best and most mature tip revision of our industry’s current thinking to deliver at scale.
Here are some SAFe practices we must rebaseline when scaling agility:
- Product Owners don’t have complete autonomy anymore. They must work from the program backlog that is managed by Product Management. This is necessary to bring value alignment across the whole system.
- System designers don’t have complete autonomy either. They must work within the constraints of the enterprise architecture. Otherwise significant refactors will cause poor economics.
- Note – Agile Architecture is significantly different than traditional ivory tower, BUFD architecture.
- Continuous Integration must occur at the system level. Since these systems realize value at the system level, system level CI practices are necessary.
- Local team demo does not equal system demo. Demos must scale to the system level on the same cadence as the teams so that our system stakeholders can provide valuable system level feedback necessary for maximum agility.
- Quality can’t be built in later. Software quality breaks down exponentially as systems scale. Just one system component with substandard quality can bring the whole system to its knees. To maximize the economics(agility) of system development, we can’t wait for a refactoring sprint. Quality must be built in as we develop across every team!
