This agile methodology focuses on being adaptive to change and creating software iteratively. It has been widely and traditions practiced by teams of small sizes. For example, Scrum is one of the many frameworks emerging from agile. This agile methodology focuses on being adaptive to change and creating software iteratively. It has been widely and traditions practiced by teams of small sizes.
Although adopting agile at the individual team level is relatively easy and the benefits are obvious. The real challenge is extending it across multiple teams in a larger organization. In other words, implementing agile at scale. This article gathers the leading agile methods for small teams; and as well as those extended agile frameworks which targeted for managing multiple agile teams.
Agile is a mindset and it’s a set of values and principles. Agile is a way of thinking and acting. Agile is all about short cycles, iterative and incremental delivery, failing fast, getting feedback, delivering business value to customers early and about people, collaboration and interaction. Agile is a mindset that is all about transparency, inspection, and adaptation. Agile, however, doesn’t consist of any roles, events or artifacts. It’s a mindset. For example, Scrum is one of the widely used frameworks under the Agile umbrella, which may help you in becoming more Agile, there are however many more frameworks within the Agile movement, like Kanban, XP, Crystal and many more as shown in the Figure below:
Are your teams already enjoying the benefits of an agile framework for small teams such as Scrum, XP or Use Case 2.0? Then, you’re probably wondering how to take it to the next level. Today, especially the larger organizations want to move toward more agile methods, too.
Scrum is a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value. It is used for managing software projects and product or application development. Its focus is on an adaptive product development strategy where a cross-functional team works as a unit to reach a common goal within 2-4 weeks (Sprint). It consists of a collection of values, artifacts, roles, ceremonies, rules, and best practices.
Lean originated with the Toyota Production System, or TPS, which revolutionized the manufacture of physical goods in the 1950s, ‘60s, and beyond. Lean maintains its hold in manufacturing but has also found new applications in knowledge work, helping businesses in all industries eliminate waste, improve processes, and boost innovation. Software development is a natural application of Lean methodology because, much like manufacturing, it generally follows a defined process, has some defined conditions of acceptance, and results in the delivery of tangible value. The key concepts that guide all practice of Lean methodology, which we call the Pillars of Lean. They are:
Kanban is a highly visual workflow management method that is popular among Lean teams. In fact, 83% of teams practicing Lean use Kanban to visualize and actively manage the creation of products with an emphasis on continual delivery, while not overburdening the development team. Like Scrum, Kanban is a process designed to help teams work together more effectively.
Kanban is based on 3 basic principles:
Kanban promotes continuous collaboration and encourages active, ongoing learning and improvement by defining the best possible team workflow.
DSDM is a framework that is made up of eight principles, a lifecycle and products, roles and responsibilities and several best practice techniques. These underpin and support a philosophy of delivering strategically aligned business benefits as early as possible to give an organization the best possible return on investment (ROI).
DSDM is a methodology that prioritizes schedule and quality over functionality, which fixes cost, quality and time at the start and uses the MoSCoW method of prioritization, which breaks a project down into four different types of requirements:
There are eight principles underpinning DSDM Atern[13]. These principles direct the team in the attitude they must take and the mindset they must adopt to deliver consistently.
Extreme Programming (XP), originally described by Kent Beck, has emerged as one of the most popular and controversial Agile methodologies. XP is a disciplined approach to delivering high-quality software quickly and continuously. It is intended to improve software quality and responsiveness in the face of changing customer requirements. It promotes high customer involvement, rapid feedback loops, continuous testing, continuous planning, and close teamwork to deliver working software at very frequent intervals, typically every 1-3 weeks.
The methodology takes its name from the idea that the beneficial elements of traditional software engineering practices are taken to “extreme” levels. As an example, code reviews are considered a beneficial practice. Taken to the extreme, code can be reviewed continuously through the practice of pair programming.
The original XP method is based on four simple values – simplicity, communication, feedback, and courage.
It also has twelve supporting practices:
Feature-Driven Development (FDD) was introduced in 1997 by Jeff De Luca when he was working in a software development project for a large Singapore bank. It is an iterative and incremental software development process and is an agile method for developing software. FDD blends a number of industry-recognized best practices into a cohesive whole. These practices are driven from a client-valued functionality (feature) perspective. Its main purpose is to deliver tangible, working software repeatedly in a timely manner. The advantage of using FDD is that it is scalable even to large teams due to the concept of ‘just enough design initially’ (JEDI). It is a great solution to maintain control over agile, incremental and inherently complex projects because of its feature-centric process. It consists of five basic activities:
Every project will have its own unique model, which will result in a feature list. The last three activities are short iterative processes, with a feature not taking longer than two weeks to build. If it will take more than two weeks, then it will have to be broken down into smaller features.
Crystal methods are a family of methodologies (the Crystal family) that were developed by Alistair Cockburn in the mid-1990s. The methods come from years of study and interviews of teams by Cockburn. Cockburn’s research showed that the teams he interviewed did not follow the formal methodologies yet they still delivered successful projects. The Crystal family is Cockburn’s way of cataloging what they did that made the projects successful. Crystal methods are focused on:
For aligning and managing multiple teams for large or complex projects, you need an agile scaling model. There are a number of scaling agile frameworks that look to solve the problems associated with agility at scale. While there are others, such as Large-Scaled Scrum, Nexus and Scrum at Scale, the other leading enterprise frameworks include Scaled Agile Framework (SAFe) and Disciplined Agile (DA). Quite often our clients ask us, how the frameworks differ or which one works best. Here’s a brief comparison of these agile frameworks from a small team and as well as Scaled Agile frameworks for large organizations as we mentioned above
Ken Schwaber and Scrum.org developed Nexus, and it is just simply a framework that implements scrum at scale across multiple teams to deliver a single integrated product. Teams work in a common development environment and are focused on producing a combined increment every sprint with minimal dependencies.
It can be applied to 3-9 scrum teams. Each team consists of 3 to 9 developers. Therefore, it is not recommended to be scaled to more than 9 teams and thus, not more than eighty practitioners. Nexus is a framework that you build upon Scrum but doesn’t change that foundation of Scrum. The Nexus framework adds a new role, the Nexus Integration Team, and events: a Nexus Daily Scrum, a Nexus Sprint Planning, Nexus Sprint Backlog, and Nexus Sprint Retrospective and Refinement in the Nexus framework.
Note That:
LeSS Framework (Large-Scale Scrum Framework)
LeSS is a framework for scaling agile development to multiple teams. LeSS comes from Craig Larman and Bas Vodde and is based on their work in the financial and telecommunication industries. The framework scales up with minimal additional process compared to single-team Scrum. i.e. use as little process as possible to get multiple Scrum teams to work well. Thus, LeSS is a good starting point when you already have Scrum in place and are just beginning to scale up with more teams, one at a time.
For Example:
There is one Product Owner with one product backlog, and several teams, each with its sprint backlog. Except for the multiple teams, all these concepts are already established in Scrum, so no news here. The multiple Development Teams working on different Product Backlog Items from the same Product Backlog. Scrum Masters serve the Scrum Teams as within Scrum.
The Product Owner role in LeSS is conceptually the same as in one-team Scrum. However, at scale, the focus changes slightly toward keeping an overview and ensuring the maximum return on investment (ROI) in the product.
It’s common in large-scale product development for different people to pull in different directions and for subgroups to focus on local sub-optimizations. Maintaining one Product Owner with one Product Backlog supports whole-product focus.
In LeSS, the one Product Owner has lots of free time to focus outward on customers and their priorities while also being able to spend some time looking inwards to the teams. She acts as a connector, bringing teams and customers/users together so the teams become more customer-focused.
In contrast with other scaled Scrum approaches, it’s possible in LeSS to effectively scale the Product Owner role with just one person because there are fewer roles and positions, and less complexity. Simply put, you “get more with LeSS”.
Scrum Masters are responsible for a well-working LeSS adoption.
In LeSS there is no ‘manager’ role, but managers may exist and they can have a useful role. Their focus is on the value-delivering capability of the product development system rather than the specific scope of a product.
There is one product-level Sprint, not a different Sprint for each Team. Each Team starts and ends the Sprint at the same time. Each Sprint results in an integrated whole product. LeSS is pure Scrum (time-boxed iterations, sprint planning, daily stand-up, sprint review, and retrospective), with a modification. As per Scrum, Sprint Planning is split into two parts and retrospective meeting to be conducted in two levels
The first part is a joint meeting attended by representatives from all of the teams to agree “What” Product Backlog Items (PBIs) will be built in the coming Sprint. The second part of Sprint Planning is then used by each team to produce the Sprint Backlog and agree “How” the PBI’s will be built.
The end of the sprint also needs to be synchronized. This is accomplished by having one common Sprint Review for all the teams. The Retrospective is divided into two parts, similar to the sprint planning. First, each team holds its team Retrospective, then representatives from each team hold a joint Retrospective together that enables them to identify and address issues that cannot be solved at the individual team level.
The Scaled Agile Framework (abbreviated as SAFe), Created by Dean Leffingwell, is an interactive software framework that enables you to apply Lean-Agile and Scrum practices at large enterprises. SAFe is described as an interactive knowledge base for implementing agile practices at an enterprise scale and it provides a lot of guidance and covers a broad scope including financing and enterprise architecture. SAFe is constantly being improved, and its latest version is 4.5: Full Configuration consists of four levels:
Team: the fundamentals of Scrum are used at the Team layer. Cross-functional teams that work in sprints facilitated by a Scrum Master.
Program: the gathering of multiple Agile Teams (ART’s) to deliver a collection of several Product Increments (PI’s) in about five sprints.
Large Solution: we only speak of Large Solutions when a product needs to be developed by more than 150 people. This means that additional people are added to the teams to ensure quality.
Portfolio: mainly relates to leaders within the organization. This mainly concerns employees who work with portfolio management and are responsible for the strategic plans and budgets. They are designated to determine the budgets per ART.
The cohesive integration of the Portfolio Management group within the Scaled Agile Framework brings the ability to understand, and manage, cost to market. SAFe enables Lean budgeting practices for organizations to fund products. The typical financing model of funding fragmented projects will be a thing of the past.
In short, the Scaled Agile Framework differentiates between Team, Large Solution, Program, and Portfolio levels. At the Team level, SAFe® is not that different from simple Scrum extended with a few XP practices. The Program level aligns the teams to form an Agile Release Train, while the Portfolio level aligns the ART with the strategic goals of higher management.
DA is subdivided into Disciplined Agile Delivery (DAD), Disciplined DevOps, Disciplined Agile IT (DAIT), and Disciplined Agile Enterprise.
As you can see in Figure above, DAD is one aspect, and arguably the core of DA is DAD, where IT solution delivery is defined end-to-end: from initial modeling and planning, setting up the team and securing financing to continuous architecture, continuous testing, continuous development, and monitoring during the entire lifecycle.
Building on this, Disciplined DevOps and Agile IT (DAIT) focus on the coordination of a company’s IT as a whole – shaping the development cycle, operations, support, data management, and other areas to become as effective and uncomplicated as possible.
The Disciplined Agile Enterprise results from all the prior segments – a company that can anticipate market changes and adjusts its strategy accordingly. In other words, an agile company.
In general, Disciplined Agile (DA) is a hybrid toolkit that builds upon the solid foundation of other methods and software process frameworks. DAD adopts practices and strategies from existing sources and provides advice for when and how to apply them together. In one sense methods such as Scrum, Extreme Programming (XP), Kanban, and Agile Modeling (AM) provide the process bricks and DAD the mortar to fit the bricks together effectively.
The hybrid nature of this framework pulls the best elements from several proven methodologies that allow teams to follow the agile method while also tailoring it to their unique needs. However, it is not an ideal framework for organizations new to agile, because it does not provide strict enough guidance on how to follow that philosophy. An organization newly transitioning to the agile approach, Disciplined Agile might make that learning curve too steep and costly.
Agile tooling remains controversy, as the Agile frameworks explicitly favor a focus on “Individuals and interactions over processes and tools”. However, most agile teams agree that adequate tooling is, in fact, crucial to its success. Tools that support the adoption and scaling of Scrum, especially to remote teams coordination can significantly impact the efficiency, productivity, and satisfaction of teams involved.
Seamlessly navigate the entire scrum process in a single, beautifully designed scrum process canvas. Perform scrum activities quickly, easily and seamlessly. Keep the whole team fully engaged. The Scrum Process Canvas makes agile projects simple and effective.
Large-Scale Scrum Canvas is a scrum tool built for every scrum team to plan, track and manage scrum projects through an intuitive visual canvas. Whether your software project involves a single team or multiple teams around the world, we keep everyone on the same page, the same canvas.
Nexus Canvas is a map of actionable Nexus work items. It helps improve project efficiency for product delivery with the Nexus framework.
