Most enterprises that adopt Agile seek benefits including faster time to market, lower delivery costs, and improved product quality. These enterprises almost universally seek performance improvement of some sort. To this end, many organizations turn to Scrum. In fact, Scrum is the most frequently used Agile framework worldwide. Scrum embodies Agile ways of working and new organizational constructs, but does it consistently deliver the Agile promise of improved performance?
The popular image of Scrum shown in Figure 1 includes a loop back to the beginning. It has occurred to me that this picture might subconsciously imply that Agile teams should merely repeat what they have done before. This realization made me wonder whether the Scrum framework itself could limit an Agile team’s urge to explore and seek new beneficial ways of working. How does Scrum enable the team’s collective intelligence?
If a team is working in the same way it was three months ago, it is not learning. And a team that only repeats the same pattern has lost the promise of continuous improvement.
Obviously, team performance cannot continuously improve; every team’s performance will eventually plateau. However, I have frequently seen Scrum teams’ performance plateau after only four or five sprints! Surely the cause isn’t that all of these teams are doing something wrong or misunderstanding Scrum values or principles. The performance stagnation must be more foundational.
In coaching Scrum Masters, I have noticed some patterns that have caused me to seek a better way. I have witnessed teams performing Scrum events without exhibiting the degree of control that empiricism and Lean thinking require. I have watched teams perform their traditional activities with siloed responsibilities after walking a task board every morning. And their management wonders why they do not see performance improvements from Agile! I frequently find Scrum teams focused on “doing Scrum” instead of concentrating on how effective they are in delivering solutions.
In my examination of how teams use Scrum, I have identified three interacting elements:
The Scrum framework
The ecosystem or ways of working
Scrum’s focus on the product is clear, with specific events and artifacts, including product backlog refinement, commitment to the product, goal prioritization, the sprint goal, definitions of ready and done, the sprint review, and so on. I call this “product orientation”; the goal is to make sure the appropriate solution is built.
Equally clear is that the purposely incomplete statement in the Scrum Guide applies almost entirely to building the product right. The guide states, “How this is done is at the sole discretion of the Developers. No one else tells them how to turn Product Backlog items into Increments of value.” Yet how does a novice team make these decisions? How do they know what are sensible choices?
Indeed, what is needed is an approach that addresses both elements.
Using the Lineout Paradigm
The term “scrum” has its origins in the game of rugby football. In “The New New Product Development Game,” Hirotaka Takeuchi and Ikujiro Nonaka explained the connection: “Under the rugby approach, the product development process emerges from the constant interaction of a hand-picked, multidisciplinary team whose members work together from start to finish. Rather than moving in defined, highly structured stages, the process is born out of the team members’ interplay.” A scrum is one of rugby’s set pieces; a lineout is another.
For a rugby lineout to function correctly, both teams assemble side by side, although the attacking side behaves differently from the defending side. Both teams have practiced plans and strategies that they bring into play. When the ball is thrown between the two lines, the game recommences.
In Agile Lineout, we also have two lines: the product line and the delivery line. The product line has strategies to ensure that the appropriate high-value product is delivered. The delivery line has strategies that enable an efficient system of delivery. Between these lines are the team behaviors that enable the development game to proceed (see Figure 2).
In rugby, the team’s lineout strategies and tactics vary by the position of play on the field. They are contextual. When the team is defending and the opponents are close to the try-line, the lineout players act differently than in a midfield situation. If the team is in an attacking position, then the team weighs its options to score. Agile Lineout replicates the contextual nature of the play; the strategies used in the product line and delivery line, as well as team behavior, depend on the context.
When coaching Agile teams, the type and content of the interventions also vary by context. A novice team’s coaching, recently assembled and at the start of a new initiative, is different from a team starting its third or fourth initiative. Coaching a team with a mix of experienced Agile practitioners and novices starting a new activity is different yet again. Coaching interventions in the first three or four sprints also have a different context than the potential requirements of sprint 10.
The context may change again if a team has recently delivered an increment and has discovered support issues. The team’s context will likely pivot again when they are about to complete an increment. The focus then turns to finishing, making final quality checks, and determining requirements for packaging and releasing to production.
At the beginning of each Agile Lineout, the team assesses the context in each line and decides on the next iteration’s primary concerns. The team evaluates whether the team behavior (e.g., roles and responsibilities) and delivery line (e.g., tools and ways of working) are still aligned with the product goals or objectives (considering the latest feedback).
Agile Lineout is progressive, with the coaching interventions’ nature based on the context of the team goal, the product delivery, and the production efficiency. Agile Lineout is a progressive pipeline of consecutive activities designed to deliver a high-value product (see Figure 3). Teams using Lineout evaluate and then improve on each iteration’s performance, utilizing Lean, systems thinking, and team behavioral theory.
For clarity, there is no concept of looping back in Agile Lineout. I am not suggesting changing or adapting Scrum, but rather an alternative to Scrum. Agile Lineout is a new approach that uses progressive steps to increase predictability, quality, and delivery efficiency. Nor am I suggesting that the Agile Lineout will be a perfect fit for every situation. All models and frameworks have imperfections. I am suggesting, however, that Agile Lineout may have benefits for coaching novice teams.
In the same way that rugby’s lineout play depends on context, Agile Lineout depends on the team to adjust their activity based upon their situation. Agile Lineout can be used for software engineering, activities with a combination of software, or business change initiatives without any software involvement. Addressing the team’s needs to create high-value, high-quality products quickly — in the midst of myriad development process and teamwork decisions — will help novice Agile teams get started and then rapidly improve.