Once associated only with small application development projects and co-located teams of 8-10 members, the Agile methodology is now being adopted--and adapted--for large-scale enterprise development. The guiding principles of agile are to keep code simple, test often, and deliver working pieces of an application as soon as they're ready. How can companies take this approach and translate it to larger, enterprise-wide projects that need to scale across a wide variety of locations, lines of business, platforms and technologies? This article offers some simple and effective techniques to help scale agile methodology across project teams and entire enterprises.
Start with a MVP
Before beginning your scaling agile journey, it helps to know where you want to end up. Agile is all about short, flexible development cycles that respond quickly to customer demand. Since you are, in effect, building a continuous, two-way software pipeline between you and your customers, you should have the idea of continuous delivery in mind from the start. Continuous Delivery is a software development strategy that optimizes your delivery process to get high-quality software into the hands of your customers as quickly as possible. The notion of releasing a prototype, or minimum viable product (MVP), is crucial for getting early feedback. Once the MVP is released, you're then able to get feedback by tracking usage patterns, which is a way to test a product hypothesis with minimal resources right away. Every release going forward can then be measured for how well it converts into the user behaviors you want the release to achieve. The concept of a baseline MVP product that contains just enough features to solve a specific business problem will also reduce wasted engineering hours and a tendency for feature creep or 'gold plating' among large, distributed software teams.
Create a Single Product Backlog
n agile product backlog is a set of tasks that must be finished before code can be released. Scaling agile successfully requires that, instead of each agile team having its own backlog, product managers or owners need to maintain a single project-wide backlog for all teams, so high-priority tasks always receive immediate attention. This way, any contributor (who can be individuals, teams, departments, or even outsourcing firms) can pull tasks at any time from the top of the backlog onto their to-do list. A common backlog ensures that the highest-priority tasks are addressed first. If an urgent bug fix or a key customer feature request is placed at the top of the backlog it will receive immediate attention, instead of waiting for the next software iteration.
Building a Collaborative Culture
In addition to having a group backlog, it's important to increase collaboration across organizational boundaries on large-scale agile projects, especially among analysts, developers and QA testers. A successful scaled agile project is made up of energized, self-organized teams that operate with a minimum amount of supervision. One small way to encourage this kind of teamwork is via "Three Amigos" meetings, which involve a product owner (or a business analyst), a developer and a QA tester who get together (either face-to-face or on-line) to review the requirements, tests and dependencies of a feature request on the backlog. This often means that the product owner or an analyst, as a representative of the business, will take the lead and ask a programmer and a tester to look more closely at a feature. In other cases, a programmer or tester may be the person initiating the meeting and setting the agenda. The advantage of Three Amigos meetings is they provide orthogonal views on the feature under discussion: the business representative will explain the business need; the programmer, the implementation details; and the tester offers opinions on what might go wrong. Three Amigos meetings on scaled agile projects don't have to be limited to three people. In some cases, a tester might want advice from a security expert or a programmer may seek recommendations from a database or infrastructure person. The goal of a Three Amigos meeting should be to encourage at least three different viewpoints, as well as some kind of consensus about whether a feature is ready for further development. Utilizing real-time agile test management tools can help aid the collaboration between project teams.
Many organizations on an agile scaling journey also take the larger step of adopting a set of principles to guide their continuous delivery efforts, which can be helpful in outlining what type of collaboration they are trying to achieve. In Implementing Lean Software Development, Mary and Tom Poppendieck show how the seven principles of lean manufacturing can be applied to optimize the entire software development process. These principles are:
- Eliminate Waste: Lean manufacturing as practiced by companies like Toyota regards any activity that does not directly add value to the finished product as waste. Among the biggest sources of waste in software development are coding more features than required, task switching (assigning people to multiple projects), as well as delays caused by excessive documentation or management activities that prevent work from moving through a development organization in a just-in-time manner.
- Build Quality In: Agile practices that build quality into your process include test driven development (TDD) and development practices such as pair programming, continuous integration, and user experience design that helps the customer attain a feeling of perceived integrity.
- Create Knowledge - also known as Amplify Learning: This is where Lean Development differs from Lean Manufacturing. The Poppendiecks compare development to a chef creating a recipe, while production is more like following the recipe in order to make the dish. "Recipes are designed by experienced chefs who have developed an instinct for what works and the capability to adapt available ingredients to suit the occasion." According to the Poppendiecks, development is a similar learning process involving trial and error. There is an expectation that mistakes will be made but developers will learn from them and make adjustments. Strategies that promote amplified learning such as iterative development help teams discover what stakeholders want and act on that knowledge.
- Decide as late as possible: Keep your options open as long as practical, but no longer. Delaying decisions is valuable because better decisions can be made when more facts are available. In an evolving software market, keeping design options open is more valuable than committing early. The most effective way to support your business such an environment is through a flexible, agile architecture that can tolerate change and by scheduling irreversible decisions to the last possible moment..
- Deliver as fast as possible: Rapid development has many advantages since it speeds up the discovery cycle--design, implement, feedback, improve--that is critical for learning. The shorter this cycle is, the more that can be learned. Speed motivates teams to stay focused on continuously adding value by delivering shippable solutions on a regular basis and assures that customers get what they need more promptly.
- Respect people: Because decisions are made late and execution is fast, the use of a central authority to orchestrate the activities of workers is counter-productive. Lean development calls for getting the details right, and empowering the people who actually do the work since they're the ones who best understand the details. You need a management and governance strategy that focuses on motivating and enabling IT teams, rather than controlling them
- See the whole: To effectively solve problems, you need to be able to look at the bigger picture, otherwise you're at risk of falling into the trap of optimizing parts at the expense of the whole. It's important to understand the high-level business processes that individual projects support--processes that often work across multiple teams, technologies and lines of business. Measurements shouldn't be done at a level that promotes sub-optimization, but by how well your entire team delivers overall business value.
These lean development principles are valuable for scaling agile projects in several ways, including helping you identify waste and then eliminate it. In addition to providing a philosophical foundation for your scaling agile project, the rules themselves are simple enough that they can be used as flexible guidelines to allow people on the ground the freedom to make their own decisions when dealing with contentious issues. As the Poppendiecks caution in their book, however, implementing lean development requires a change in culture and organizational habits that some companies simply can’t achieve, but those that have understood and adopted the essence of lean thinking have realized significant, sustainable performance improvements.
Large-scale Agile Frameworks
When scaling agile, it's important to use an approach that makes the most sense for your entire IT organization. This may very well involve taking advantage of an appropriate large-scale agile frameworks and/or body of knowledge. There are three major frameworks for scaling agile software development for large enterprises that have the most traction nowadays among agile enthusiasts: the Scaled Agile Framework (SAFe), the Disciplined Agile Delivery (DAD), and Large Scale Scrum (LeSS). There are also a few other agile scaling approaches such as Scrum of Scrums (SoS) that rely on informal or "roll you own" training, which may be worth considering if your organization has unique requirements that none of these three approaches address. (See Richard Dolman and Steve Spearman's comparative matrix that looks at several different agile scaling approaches.) All three of the main scaling approaches offer multi-level training and certification, which make them attractive to enterprises wanting to expand a small agile group into an enterprise-wide practices and need formal guidance. Take heed, however: some of these approaches call for a radical rethinking of a company's hierarchical organization, which may make it a hard sell in larger, traditional organizations with many layers and specializations.
The Scrum Process-All three scaled agile frameworks build upon techniques used in scrum and other lean and agile team-oriented frameworks.
Image Source: Lakeworks
Because all three scaled agile frameworks build upon techniques used by team-oriented agile frameworks, it's important to have a basic grounding in the ideas, concepts and terminology of scrum testing and other lean and agile frameworks. The SAFe framework defines group processes at the Team, Program, and Portfolio level. SAFe Teams typically consist of 5-9 people who work in two-week scrums using XP (Extreme Programming) methods, pulling work from the Program backlog. The length of each team's scrum is synchronized with 5-10 other SAFe teams at the Program level (the next level up), as part of an "Agile Release Train" that includes the development teams and other stakeholders. The highest level of the SAFe framework, the Portfolio level, defines ways that executives and agile leaders can use lean processes like value streams to identify and prioritize features, which can then be broken down at the Program level and scheduled on Agile Release Trains.
This SAFe “Big Picture” graphic shows the three levels of SAFe (Portfolio, Program, Team) as well as the many roles, ceremonies and artifacts involved in SAFe.
Image Source: Scaled Agile Framework
Disciplined Agile Delivery, developed by Scott Ambler and Mark Lines, is similar to SAFe in that it is built on existing lean and agile techniques. The DAD framework is designed to work across three project phases: Inception, Construction, and Transition. DAD's strength is in providing more guidance in the areas of architecture and design, which occur at the inception phase earlier in a project's lifecycle. It's also strong at deployment (in the transition phase) since it has explicit DevOps practices and strategies built into the framework.
Large-scale Scrum (LeSS) , created by Craig Larman and Bas Vodde, has two frameworks: Framework-1, designed for smaller companies (up to 10 Scrum teams, with 7 members each), and Framework-2, also referred to as LeSS Huge, designed for up to a few thousand people on one product. LeSS expands on the basic team Scrum framework by organizing several feature teams under a single Product Owner (PO). Framework-2 adds the notion of an Area PO (APO) to handle scaling in larger organizations. Compared to SAFe and DAD, LeSS is a more flexible and non-proscriptive agile scaling framework, which may not make it the best choice for enterprises and large-scale development projects that need more structure.
Training Courses and Certifications
For organizations that have decided to adopt a specific agile scaling framework, there are plenty of training courses and certifications to help you get up to speed on a particular framework. The Scaled Agile Academy has a half-dozen certifications that provide the knowledge and tools to be effective at the Team, Program and/or Portfolio levels of the Scaled Agile Framework. These range from two-day courses for managers and executives (SAFe Agilist), to courses for developers and testers (SAFe Practitioner), to an in-depth SAFe Program Consultant Trainer program. The Disciplined Agile Consortium, which oversees the DAD framework, promotes five different certifications that range from a beginner stage, represented by Disciplined Agilist and Certified Disciplined Agilist certifications, to a 'master' stage, represented by the Certified Disciplined Agile Coach certification. There are several ways to learn more about LeSS, including courses for Certified LeSS Practitioner and Certified LeSS for Executives.
Most of the agile scaling framework courses listed here expect students to have basic Scrum knowledge, which can be achieved by taking a Certified ScrumMaster or a Professional ScrumMaster course, or by hands-on experience practicing Scrum. The more experience your organization has with Scrum and other lean and agile methodologies, the shorter your journey to scalable agile should be.
Related Articles: