7.6: Scaled Agile Frameworks - Video Tutorials & Practice Problems

<v ->Let's discuss Scaled Agile Frameworks.</v> Agile at scale is seen as the organizational approach to agility. It allows to maximize benefits of Agile delivery and avoid challenges, similar to the ones that were experienced by the transformers. Scaled Agile implementation change the whole company culture to support the value of Agile Manifesto. Focus on people, on business outcomes, on being comfortable with iterative planning and iterative delivery. It also focused on business and technology working together to delight their customers, on prioritizing the value delivered over reports, about the work being done, those red charts. It focused on including team-level collaboration between cross-functional teams and many other principles, and this can be done in many different ways, and these ways have been summarized in several well-known Agile scaling framework. So let's review those frameworks one by one and then compare them based on the type of the organization that they're most suitable for. There are multiple Agile scaling frameworks. The most popular include Scaled Agile Framework or SAFe, Large-Scale Scrum or LeSS, Disciplined Agile Delivery, DAD, the Spotify Scaling Model, Nexus, and Scrum@Scale. So let's briefly describe each of those frameworks and compare them to each other. Let's start with the Scaled Agile Framework, or SAFe, because it is by far the most popular Agile scaling framework. SAFe is the world leading framework for scaling Agile across the enterprise. It's used by hundreds of world's largest companies. It overall sustains and drives faster time to market, dramatic increase in productivity and quality, and improvement in employee engagement. The way SAFe is designed, it has a concept of a scaled Agile release train. Agile release train, or ART, integrate sprints within multiple teams within the organization and delivers them to the customer in a structured way. SAFe also talks about other teams such as product, marketing, sales being part of our delivery to the customer. The authors of SAFe, Dean Leffingwell and Drew Jemilo, released SAFe in 2011. Their goal was to meet the changing needs of large organizations, and since conditions changed rapidly in those organization, frameworks such as SAFe emerged since then to help businesses improve solution delivery for their enterprises. The key settings for SAFe include American Express, FedEx, Chevron, MetLife, Lockheed Martin, PepsiCo, Cisco, Capital One and many other companies. Now let's talk about Large-Scale Scrum or LeSS. The creator of LeSS is Craig Larman. According to him, Large-Scale Scrum is a new and improved Scrum, and it's not Scrum at the bottom of each team. Instead, it is about figuring out how to apply the principles, purpose, elements and elegance of Scrum solution in a large-scale context as simply as possible. Compared to SAFe, LeSS is very simple, it's very fast. If you have Scrum for one team, you have Scrum or Scrums for multiple teams. If you have one product owner for one team, then you have product owners for multiple products. Like Scrum and other truly Agile frameworks, LeSS is barely sufficient methodology, especially for high-impact reasons. It was invented in 2005, and since then, it is focusing on clients who applied their frameworks for scaling Scrum, Lean, and Agile development. The key studies include JP Morgan Chase, Ericsson, BMW Group, Bank of America Merrill Lynch, Nokia, John Deere, Alcatel, and many other large companies. Now, let's talk about the Disciplined Agile Delivery, or DAD. That enables team to make simplified process decisions about incremental and iterative delivery. It builds on many practices invented in Agile, Lean, XP, and other software delivery methodologies. Also, it looks at the people first learning-oriented environment to make scaling easy and efficient at the organizational level. It was invented in 2012 based on the book "Disciplined Agile Delivery: A Practitioner's Guide to Agile Software Delivery in the Enterprise," which was written by Scott Ambler and Mark Lines. DAD is a mean of moving beyond Scrum. It doesn't work for huge organizations, but it works well for medium-sized companies. Since 2012, DAD has been redefined as a toolkit. So it can be combined with any other scaling framework. This toolkit consists of Lean, Scrum, Kanban, LeSS and SAFe. All of those elements include techniques of modeling test-driven development and other practices to make Scrum and Agile successful at the company level. Let's take a look how Spotify scales its agility. It is a unique model, but it takes all the Agile considerations into account really, really well. So the heart of the model is a squad. These are people on a squad. One of them could be a UX designer, a few of them could be dedicated testers. The others could be developers and so forth. All together, they create a squad. This is squad 1. A group of squads working on one product is called a tribe. Together, they produce one specific product. For example, media player. This is a tribe. There are multiple tribes. So this is a media player tribe. This is the personalization that saves all the playlists and allows to exchange them, similar structure. Here is tribe 2. It has also squads. The number of squads could be different. Let us say it is a larger tribe, so it has six squads and so forth. Those teams are cross-functional. We show that here, there are developers, testers, user experience designers, user researchers, whoever is needed to deliver functionality end to end, but then on a specific team, there could be people of similar competency. On this team, there is another user experience designer and here is another user experience designer. So all together, they create a chapter. A chapter has usually its leader. The head of UX design for Spotify for this specific tribe could be within or could be outside of this chapter. This person is working with other designers on defining techniques, competences, role expectations, tools, and everything else to establish consistent and continuously improving UX practices across the whole tribe, and eventually scaling at the whole company level. Similarly, for the testers, there will be lead manager for testing, and this person will be responsible for developing professional skills, practices, tools, everything else that makes those team members successful. Now, throughout the whole company, people may be interested in different topics. See, this developer is interested in Agile. They want to understand what's the difference between Scrum and Kanban, what is Scrumban? What are other methodologists that are interested in Agile? This person is interested in Agile, this person, and a few people here in different roles as well. So all together, they create a guild. Guild is not confined to a specific tribe. These are people who either want to move into Agile coaching role or this Scrum Mastering role or they just want to learn more about it. There is another guild. Those people are interested in DevOps or continuous deployment, test-driven delivery and similar techniques. Those people create DevOps guild. So this way, two things are accomplished. First, as you can see, you can scale this model anyway you want, you can create multiple tribes. Each of them will be responsible for its own product or product feature. At the same time, it empowers team members. Anything they're interested in, let us say this user experience designer wants to grow into quality manager. So this person becomes part of the guild to learn more about quality management and joins others who may be in this role already or maybe they're similarly interested and creates a guild. A guild may have a conference. It may meet on a regular basis. They may share experience and so forth. This is empowering model and also extremely flexible, and the final thing I want to mention here, that for each of those specific squads, they pick which model they want to follow. It could be that this person does Scrum, and this person does Kanban and this person wants to experiment a little bit so they do Scrumban. It is up to them. No one tells them which specific methodology they have to choose. Here is the Agile scaling model at Spotify. Now, let's talk about Scrum@Scale. Scrum@Scale is a relatively new framework that was developed by Scrum Alliance, and it's a natural extension of the Scrum framework. Its goal is to empower organizations to achieve business agility and deliver value to their customers. Within this framework, Scrum teams operate consistently within "The Scrum Guide" and also it focuses on tenets and principles of "The Scrum Guide," as well as Agile Manifesto, and the products there could be hardware, software, integrated systems, processes, services, and so forth. Scrum@Scale enables transformation at the divisional or department level and scales it to a company. They call it actually a scale-free architecture. Now, let us talk about the last, but not the least framework, which is called Nexus. The Nexus model was developed by Scrum Alliance and it actually is becoming increasingly popular. It's a very simple framework. It implements Scrum@Scale across multiple teams. Usually, it's applied to three to nine teams that are working in a common development environment on one product. So it focuses on incremental iteration and combined increment every sprint with minimal dependencies. Nexus promotes value. It's a scaled framework that does not say too much about stakeholders or the product that they have to deliver. It focuses on cross-functional teams, which they consider the prerequisite of Nexus. They are looking at Scrum experience and Scrum environment in promoting transparency, continuous integration, and relentless improvement.