How can your organization scale Agile principles to multiple teams and stakeholders while ensuring broader business objectives stay tightly aligned with downstream deliverables? Here are seven steps for scaling Agile software development to the enterprise. We’ll dive deeper into each of these steps in the following pages.
Of all of the steps for scaling agile, the first is the most challenging and, arguably, the most important. To effectively get everyone on board with your intended changes, your organization needs to secure buy-in from Executives, Managers, and other leaders. These people sponsor the change and support the implementation by setting the vision, showing the way, and removing any impediments. Then select and train a guiding coalition of Lean-Agile Change Agents to provide teams with the knowledge, training, and horsepower needed to implement specific process changes within the teams.
The three leading Lean-Agile frameworks that look to solve the problems associated with agility at scale are Scaled Agile Framework (SAFe), Large-Scale Scrum (LeSS), and Disciplined Agile 2.0 (DA 2.0), although many others exist. It’s important to remember that every company has different needs and characteristics that will influence their decision on which framework is right for them. If one framework is missing an element that would be beneficial to your process, feel free to draw from multiple frameworks to create a custom approach that is contextual to your organization.
Cross-functional teams are a set of people (and sufficient tools) that have all the skills and authority needed to define, build, test, and deploy a complete increment of work without passing it to others that are not part of the team. They can self-organize to figure out the best way to complete that work, and typically include a Product Owner, a Scrum Master, Back-end/Front-end/Mobile developers, UX/UI specialists, QA engineers, and Business Analysts. Organizing teams cross-functionally resolves issues of conflicting priorities, improve communication and quality, ensure consistent focus on the customer experience, iterate quickly, improve alignment and use of resources, and can lead to greater innovation.
Upstream Agile activities remove barriers between business and development teams, while downstream activities remove barriers between development, testing, and operations. At one time it was acceptable for organizations to begin their transformation by focusing mainly on upstream activities and then eventually add downstream activities to their process, but this is no longer the case. Development teams should kick off their Agile transformation by adopting both upstream and downstream activities in tandem, while their operations partners prepare Agile infrastructure and automation for them to execute on.
Executed correctly, continuous testing serves as the centerpiece of the Agile downstream process and, given the increased complexity and pace of modern application delivery, is essential for controlling business risks. To add continuous testing to your Agile process, start by assigning full-time testers with full-stack development skills to your cross-functional teams, shifting all types of testing to earlier in the development lifecycle. Embed quality assurance engineers in Agile projects from the very beginning, allowing them to work closely with your development on the creation and design of your product. Also, automating the test design and execution will help to speed up manual testing and manage rising product complexity.
Nearly all Agile teams favor an incremental and continuous development strategy, meaning that each successive version of the released product is usable, and each builds upon the previous version by adding new-user visible functionality. The ability to release incrementally is a critical aspect of the continuous delivery pipeline and provides teams with the information they need to decide whether further exploration of an idea/feature is warranted if new functionality should be added, or perhaps if a different approach is warranted. To support incremental delivery, your organization needs to have a System of Record of what has already been delivered, ensure you have sufficient documentation, and integrate consistent feedback into your continuous release process.
As companies shift from small Agile projects and teams to more complex projects and potentially distributed teams, there’s a need to also shift from paper and spreadsheets to tools that provide automation, workflows, data persistence, and traceability.
Essentially, you can’t do Enterprise Agile well unless you have modern technology to support it – crystallizing processes, offloading huge quantities of manual tasks, and facilitating deep business-IT collaboration. Agile Planning and Project Management tools synchronize with downstream ALM and test management tools to enable enterprise-scale Agile by automating and orchestrating business-driven goals and measures into the DevOps lifecycle.
Regardless of where your organization stands on the spectrum of Agile maturity, scaling to Enterprise Agile will take time. Organizations that we speak to about their Agile transformations have one major similarity: their transition can be measured in years, not weeks or months. Once you accept this, you can use the steps for scaling Agile above to build a roadmap for teams, departments, business units, and the organization, to shift to Enterprise Agile.