Why Scale Agile?
Originally agile was used primarily in small IT shops, where there was no need for large teams because the scope of the work did not require anything more than what the small shop could handle. But then as agile proliferated, it made its way into enterprise development centers. It was in this environment of large scale development that simple, small team development tended to break down. The result was that a mantra of “agile is only good for small co-located teams” began circulating at larger organizations. That stereotype seems to have made its way everywhere. Companies that have little to no exposure to agile, seem to already “know” that Agile is only for small development and come to the incorrect conclusion that it is. Scaled agile is for large organizations and recognizes the need for large teams.
Another important reason for scaling Lean-Agile teams is to reduce the waste that comes from setting up teams for every project. An important byproduct of keeping the teams in place over time, and using them for different development efforts, is that they perform better. Very often projects come to an end before the team matures from the forming to the norming stage. Quite often teams do not even get from the storming to norming stage in the team life cycle. Teams that mature to the norming and performing stages tend to stay at companies longer. This is due to higher job satisfaction. Contrary to what some managers think, most team members want to deliver great work. Keeping teams together so that they mature to the performing stage accomplishes this along with the double benefit to the company of getting great work from satisfied team members.
What Problems Are You Facing?
If your problems include:
- Slow release of useable product to users and customers
- Low quality
- Low productivity
- High costs
- Slow reaction time to incorporate changes
- Poor employee morale and high turnover
- Low customer satisfaction
- Inability to complete complex projects
then you probably need some type of a scaled Agile framework. Many of your competitors have had these same problems and have solved them by taking the scaled agile route.
Scaled Agile Options to Consider
- Bring in an Agile consultant experienced in scaling.
- Decide on a framework option best for your organization. Several exist, but probably the best one is customizable to your company and can be improved incrementally on a continuous basis. Consider the following:
Scrum of Scrums
The most popular of the many attempts at scaling is using the Scrum of Scrums. To a point this method of scaling is effective. The problem with Scrum of Scrums is that it becomes unwieldy quickly for larger developments. There are many other scaling models but many have not gained popularity because of being cumbersome, or not comprehensive resulting in organizations having to solve too many omissions.
Nexus
Nexus is an Agile framework that is used in a scaled project where there are approximately 3 to 9 Scrum development teams and a common product backlog. The Nexus framework is in addition to and overlays the existing scaled Agile framework. Its core is a Nexus integration team. The integration team consists of a product owner, ScrumMaster, and one or more integration team members.The purpose of the Nexus team is to coordinate the work of all the multiple Scrum teams to be sure their value-added product output all ties together and is in harmony and not conflict. The need for a Nexus team ( or for that matter any integration team) becomes very important when there are a large number of teams all working together simultaneously on the same project. If the teams are not colocated, it becomes even more necessary.
LeSS (Large Scale Scrum)
In LeSS there are multiple teams all working together in one common sprint, with the common goal of producing one PSPI (Potentially Shippable Product Increment). There is one product owner and a single product backlog. In LeSS attention is focused on producing the entire product. Usually there are only cross-functional teams and no specialist teams. LeSS can be thought of as an expanded version of a single Scrum team subject to many of the same rules and principles.
DAD (Disciplined Agile Delivery)
This Agile framework is distinguished by having a risk-value delivery life cycle. This means it takes an organization’s goal and and starts building and testing the most risky part first. The goal is to find out as soon as possible before a lot a time and money is spent whether or not the goal is feasible. If the work passes, the next small portion is built and tested, and if that passes, the life cycle continues. If the life cycle makes it to the end, it is a proven idea and becomes productized. DAD is very much enterprise aware, and is scalable.
SAFe (Scaled Agile Framework)
Using guidance from books written by Dr. Donald Reinertsen and others, Dean Leffingwell developed his Scaled Agile Framework (SAFe) while working at John Deere Company. It was at Deere that Dean had the opportunity to test his ideas as he implemented them over a period of years with large scale teams.
People frequently say that SAFe is complicated, but they really don’t understand the model that well. Considering the volume of work that can be completed by a scaled team of say 75 members, SAFe is compact and efficient. In addition, not every part of the framework needs to be used for it to work. But organizationally, for larger development, the ROI that can be achieved by using the complete framework makes it worth implementing in its entirety.
SAFe Agile framework is a proven, codified, and publicly-facing knowledge base that is used to successfully scale Lean-Agile development in larger software enterprises with fifty to thousands of members. - Decide on an education and training program - An Agile consulting firm should be able to provide specific training geared for the product owner, ScrumMaster, and development team. Engineering tools must be set-up for the development team that includes TDD (Test Driven Development), automated testing, CI (Continuous integration), and automated deployment. The purpose of Agile engineering is to automate all repetitive tasks to save development team time, and to improve code quality by way of using automated testing to retest everything for which a test already exists.
Adaptive Agile Scaling
Agilest offers guidance in its book “Adaptive Agile Scaling” for SAFe implementation. The authors describe how to use flexible scaling for teams ranging in size from 3 to 125 and larger. The use of teams that are of minimum viable size is stressed as a way to keep overhead costs to a minimum. No exact way to scale up or down is given because each company is unique. But what is discussed in the book is what worked and didn’t work over a period of years in the trial and error process of implementing scaling.