More Than LeSS

Preface: Why yet another approach to scaling Scrum?

This article stems from two intentions:

• While the agile community has come up with refreshingly new approaches to scale agile methods, these models still seem to fall short in addressing the organizational complexity around large projects. Good practices are available to break down requirements from a large business vision to working code in many teams. But the product owner seems to stand pretty much alone surrounded by a complex project environment spiced with ambiguous interests. Furthermore, organizational culture and leadership still do not receive the attention that these topics deserve.
• The lessons from 13 years of working with agile projects and five years of research make me believe that there is enough practical experience with successful, large agile projects to form a reusable set of practices. The result is a holistic approach to scaling Scrum. It is based on LeSS, amending it to better face the challenges of large projects. I pay particular attention to the tensions in and around a project.

With many thanks to Ben Linders, Peter Hundermark, Siegfried Kaltenecker, and Stefan Jäger for their review and valuable comments.

The conundrum of change

How can an organization adopt a new way of running large agile projects and what role might models such as LeSS and SAFe play in this transition?

To start with, let us take the following underlying assumptions:

1. Organizational change is most of all a change of culture.
2. The result of an organizational change is per se unpredictable.

Neither thought is new. They are kind of conventional wisdom in systemic organizational development (OD) and slowly are becoming more prevalent in the agile community (Leopold 2012, part II). The quite thoroughly thought-through systemic approach sees an organization as self-organizing. The idea that we can choose a new organizational model and just switch to it is only a “control illusion” of managers, as Niklas Luhmann, the founder of the system theory upon which systemic OD is based on, frames it (Luhmann 2011, p85). In the view of systemic OD, change is something that should be stimulated and well-guided (Königswieser 2008, p147) but it cannot be created according to a plan with predefined results. To promote real change thus entails trusting people to come up with a solution that their managers cannot anticipate beforehand. This empowerment is the key to unleashing the resources an organization holds and to make a change sustainable.

This asks a lot of the decision-makers of an organization: they have to be ready to live with an uncertain outcome. This is just about the opposite of what senior management typically seeks: they strive for low-risk ways to achieve short-term goals. They are often looking for the legendary low-hanging fruit. This leads to what might be called the “conundrum of change”: small organizational changes can lessen problems, conveniently avoiding the underlying structural problems. And because the prolonged structural problems remain, the next issue will be just around the corner and will require another quick fix. The organizational pain level is kept at bay by curing the symptoms instead of running a professional change initiative to address the underlying root cause. In consequence, no substantial change is likely to occur. The organization continuously works below its potential: it is too busy reaping low-hanging fruit to be able to reach the higher levels.

Based on these assumptions, of what value might models like SAFe and LeSS hold when scaling Scrum? If the result of change is unpredictable, why bother having a model at all? In my experience, such models can be helpful beacons in the uncertainty of a change process. They can inspire new visions by showing a fundamentally new way to work. They may also provide valuable, practical principles from which to learn. When I look at how Spotify works, I feel drawn to working in such a way. (Last year’s interview with Henrik Kniberg (Charron 2013) has more on how Spotify puts their vision into action.) But to decide what to make of beacons is the prerogative of the people working in the adopting organization. Theirs is the true work: to understand their strengths and to evolve themselves by integrating the new. To eliminate the uncertainty of this change by just imposing some new model is unlikely to lead to a sustainable change. Why would an organization hesitate to jump at the next fashionable model in a year’s time?

Both SAFe and LeSS are too young to have case studies on their long-term effects on organizations. Yet there are hypotheses that can be deduced from the nature of their frameworks as to what kind of beacons they might be in a transition. SAFe, for one, appears to give an organization great freedom to adopt it to its liking. That provides flexibility, but it also creates great leeway to circumvent confrontation with unwelcome questions. SAFe can be used to put governing structures around an existing water-Scrum-fall approach (as done by some SAFe first-adopters who presented their cases at the AgileWorld in Munich in July 2014). The question of why to use water-Scrum-fall in the first place can be conveniently avoided that way. SAFe does not contradict the process of Scrum but it does not seem to stir the potential for revolution that Scrum holds either.

The name of the framework is well chosen: it is probably a safe road for managers to gaining more structure on project portfolio and program level. But it seems doubtful whether it is a path towards greater productivity, better customer orientation, shorter time to market, and so on. So it is of little surprise that the response by the agile community is not entirely enthusiastic. As Ken Schwaber puts it, “The boys from RUP (Rational Unified Process) are back. Building on the profound failure of RUP, they are now pushing the Scaled Agile Framework (e) as a simple, one-size fits all approach to the agile organization.“ (Elssamadisy, 2013)

WIBAS, a German consulting company that apparently has a rather pragmatic approach, puts it in a more differentiated manner. While they positively note that SAFe “consequently thinks through the program and portfolio level”, they judge that it “uses many ‘classic’ terms on program level - that veils the need for transformation and makes the adoption of SAFe harder for agilists.“

LeSS, by Craig Larman and Bas Vodde, on the other hand, appears to be a consequent transformation of the Scrum process from single-team level to a multi-team project (Larman 2010). It describes in great detail how to structure and break down scope and how to internally structure a large agile project. In the development of agile methodology, this seems a consequent evolutionary step, as it carries forward previous thinking (see Cohn 2010, p327). Larman and Vodde also provide practical day-to-day principles for use within that organizational structure. LeSS focuses resources on the value stream, inviting managers to become part of the work force again (Larman 2014).

However, LeSS as I perceive it takes little heed of the organization, of how to deal with continuous change, and of improvement across teams. One might say LeSS perpetuates Scrum on larger scale: it transports the organizational structures of Scrum to the scale of large multi-team projects. And, like Scrum, LeSS conveniently circumvents the complexity of projects: it hardly addresses the project environment, in particular the stakeholders and their ambiguous interests. Unfortunately, that is where most large projects fail: deliverables not meeting the expectations of customers or stakeholders. (Spielhofer, 2011)

So I believe LeSS could and should become more. The following chapters describe a holistic approach based on Larman and Vodde. In line with the initial assumptions, it is meant to be a beacon that may be used by an organization that wants to run multiple large agile projects.

What are the main challenges?

Before defining solutions for running multiple large projects, let’s take a high-level look at the main challenges such solutions need to address.

Challenge 1 - Tension between teams: Beside other aspects, a project is a living community of people. Any social system, even a well-performing project, will have some amount of inner tension. This is something we probably all have experienced. Scrum provides effective means to address such tension at the team level. There is a Scrum Master who can moderate and to some extent mediate conflicts, thus helping to build a well-performing team. In large projects, this challenge scales with the number of teams: the more teams there are, the more opportunity there is for frictions between them.

Scrum is sometimes said to continue the tribal approach to which mankind has been socialized in the course of evolution. Tribal structures can create a strong bond between the team members, which is certainly an asset in building highly performing teams. But it can be detrimental to running multiple teams if the team focus grows too strong: group thinking or tribalism may cause tension between teams.

Challenge 2 - Tension inherent to the project environment: Friction may occur among those who will ultimately judge whether the project is a success or a failure: the project stakeholders. In order to deal with such dissonance, it is important to understand the underlying reasons. Unfortunately, there is a jungle of possible causes, each needing very different treatment, such as:

• A trade-off between what is best for one unit and what is best for another. A marketing initiative may put product A into focus. The product owner responsible for the profit or loss of product owner of B might have a different opinion of what is best for the company. Traditional bonus systems encourage this way of thinking by breaking down company goals to organizational entities. This way, they foster local optimization at the expense of improving the entire organization.
• The stakeholders might simply have different perceptions of the market and different views on what is best for the company.
• Not everybody puts the well-being of the company above his or her own well-being. There might be a hidden personal agenda behind a dispute over features – a content-related decision may be only a pawn in a political game.
• Etc.

These problems are aggravated by the fact that large projects tend to affect more than one organizational unit: a loyalty program, a compliance project, or marketing initiatives, to name a few, will cut through organizational boundaries like a hot knife through butter. In consequence, the key players of these units will have stakes that are subject to change and that are not always transparent.

A project environment is ambiguity in constant motion. This seems like a strong case for avoiding large projects altogether. It vividly promotes the vision of an agile organization: reduce complexity by creating many independent product lines with independent teams. No more stakeholder alignment – instead there is one product owner responsible for profit and loss who makes the calls, and that’s it. LeSS as an organizational beacon, as I read it, points in that direction. But until we all work in truly agile organizations -and there are probably reasons why there are hardly any (Walton, 2014)- we need to deal with this complexity. And even then, if we put this vision to a reality check, we might find ourselves not wanting a setup that entirely eliminates this diversity of interests. There is a often a sensible reason why there is not just one (product owner’s) voice making the calls, but that other voices are involved in the decision-making – HR representing the long-term perspective of the staff or marketing caring about the overall impact on the brand, for instance. As an owner of the company, would you want these voices silenced? Organizations tend to meet the complexity outside with complexity within. It is not trivial to discern what of it is valuable and what is overhead.

This accumulates in what I would frame as the strategic challenges of large projects:

• Managing the tension inherent to the project.
• Managing the tension inherent to the project environment.

In a positive vision of a large agile project, this tension is energy streamlined to a force that pushes the project forward rather than blocking it.

Further, there is what I would call the main operational challenges of large projects, such as:

• Maintaining transparency in projects with many teams, accurately assessing the status of a project.
• Managing the dependencies among many teams.
• Breaking down the flow of requirements to teams.
• Keeping focus on the project goals, preventing dispersion of teams.
• Enabling cooperation between teams on multiple sites or offshore teams.

Illustration 1

Illustration 1 provides an overview of the main forces running through a project of five to 15 teams: the customers and their needs (green); the project stakeholders within the organization exerting their power (blue); and the teams with their interests and needs (orange). In conventional project setups, these interests tend to collide at the project manager, a sandwich position that has crushed many good people.

The approach introduced in the following chapter aims to address this risk inherently. It meets the natural forces of a project with its basic setup, a setup that is capable by its structure to work with this energy instead of just dealing with the symptoms.

A new beacon for Scrum projects at large scale

A positive vision is to work with the forces in and around projects to resolve conflicts rather than to stand in their way. After all, resistance is energy and can be perceived as an offer to communicate rather than something to struggle against. However, this can prove to be too much for one person; there are too many different viewpoints to consider, viewpoints that sometimes conflict with each other. The alternative is to face this complexity as a leadership team rather than alone, following the idea of post-heroic leadership and “leadership as a team sport” (Kaltenecker, 2011). This becomes more important as the size of projects grows: leadership capability must be able to scale with project size.

Illustration 2

Illustration 2 shows the three main roles that together compose the leadership team of a project:

• The product owner (green) is driven to create a great product for the customers.
• The project environment facilitator (blue) is driven to create a balance of interests among the stakeholders.
• The project facilitator (orange) is driven to create an environment in which the teams can unfold their creative and productive potential.

The role and practices of the product owner and the Scrum Masters in the teams are the same as in LeSS. Operational challenges can be met with structure, and LeSS provides plenty of structure. It describes in depth how features are broken down to teams and how to plan their implementation. It thus provides a collaboration model of how to take the value stream within an organization from a business vision to continuously integrated and tested code. The other two roles primarily come into play to address the strategic challenges. The three roles together form a leadership triangle that can channel the forces within and outside the project.

All of these roles are meant as archetypes. The idea is not to staff these roles and then rub your hands with glee. The idea is to ask oneself at the start of each large project: what kind of forces do I expect from within and from outside a project? Once this is initially gauged, one can start to address these challenges by creating a leadership team that covers these roles. Successful setups I have come across were:

Setup 1:

• A product owner.
• A project manager who sees his/her role with a strong outward focus.
• A PMO that acts more like a facilitator inside the company than a classical control office.

Setup 2:

• A product owner.
• Two agile project managers, one with inward focus and one with outward focus.

Setup 3:

• A product owner who could manage the environment well.
• A project manager, primarily focusing inward but sometimes helping the product owner to play bad cop when dealing with difficult stakeholders.

But what is the difference between such agile setups and conventional project-management teams? Prince2, one of the three large, conventional project methodologies, recommends a team of project leaders as well. The project board, according to Prince2, consists of three roles representing the customer (or executive), the users, and the supplier or specialist input.

What then is the difference between a project facilitator and a supplier representative? In my experience, it primarily lies in the stances these leaders take in everyday situations. It is the underlying values that make the difference: the way they live these values, the way these values have become a part of them. As Stacia Broderick described in her book, The Software Project Manager’s Bridge to Agility (Sliger 2008), this requires a sincere journey through the process of transforming oneself from a command-and-control manager to a facilitator. For example, whether a project facilitator will respect the self-organization of the team will make a great difference.

The same applies to working with the stakeholders. A project environment facilitator will try to create transparency in order to create trust rather than build Chinese walls around the project. As initially assumed, culture is the key factor in any transformation, including leadership culture. More on how agile leadership can work can be found in the “Agile Leadership Model” article (Spielhofer and Kaltenecker 2012).

Helpful practices in running large Scrum projects

The following is a selection of practices that may be helpful in running large Scrum projects with agile leadership teams as described before. They focus on the strategic project challenges and can be used additionally to the practices proposed by Larman and Vodde. This selection presents a sample set to illustrate the way in which the leadership team is working in this approach. It is by no means comprehensive, as this would overstretch the limits of this article.

Continuous reflection

Any assessment of a project situation is always incomplete. Furthermore, it is subject to continuous change. In consequence, the project setup, the release plan, and everything else that is governed by the project leadership team should be continuously adapted. Working in a leadership team instead of alone brings a great benefit: it is unlikely that two or three people all have the same blind spots. Furthermore, leadership teams can develop the same co-creative power that Scrum teams do. To make use of this asset, the principle of continuous reflection, or Reflektionsleberkäse in German, can help.

Practice 1: Continuous reflection or Reflektionsleberkäse

As a leadership team, make time to regularly reflect upon the project. Free yourself from operative day-to-day work and try to see the forest for the trees. Compare the different pictures of the project you have in mind. Look for challenges you are not yet sufficiently addressing.

When doing so, it might be helpful to use metaphors. A metaphor I sometimes use is to stand on the bridge of a ship on a foggy day, searching for icebergs. What are the icebergs that might be dangerous to us? Have we considered them appropriately when laying our course?

When looking for icebergs, create the same appreciative culture among yourselves as you do when working with your teams and stakeholders: listen, accept different views, and, most importantly, allow room for uncertainty. It is the icebergs that you do not yet see that you want on your radar. Uncertainty may be a great resource here, guiding you into the unknown. It might be helpful to ritualize such reflection sessions.

At one Scrum transition, a fellow manager and I used to regularly take a walk together, reflecting on things that bothered us while eating our lunch (a traditional Bavarian roll with sausage, a Leberkäse). Those sessions were hard work, but we endured them through the ritual of eating and strolling, and named them Reflektionsleberkäse.

The power of transparency

Transparency is a strong engine of change. It is easy to avoid problems if you choose not to see them. They are a lot harder to avoid if they are right in front of your nose. Once you are aware of a deficit, it is likely to become an itch you want to scratch and make disappear.

In large projects, transparency can also help to reduce mistrust arising from a lack of information or different sources of information. We tend to imagine what might be happening in IT or what might be happening in product management if we don’t have the feeling we know what’s going on. Research shows that communication becomes clearer in organizations using agile methods (Kaltenecker 2011). More on the power of transparency in agile projects can be found in the research of Christina Böhm and David Haselberger on transparency in agile project management.

But the task of maintaining transparency becomes increasingly hard with larger projects. It is easy to lose sight of the forest when there are eight or even 15 teams dashing through the trees at full speed. And the more stakeholders there are, the harder it is to keep them all well informed. The following practices can help.

Practice 2: Establish a common language

As a leadership team, define simple reporting that reflects the status of the project. As with any reporting, it will be a drastic simplification of reality. Make sure it is understood and accepted as a sufficiently accurate reflection of the project reality by all teams as well as by the stakeholders.

The basis of such a reporting will usually be a burn-up chart (see Peter Hundermark’s “Do Better Scrum”, p60). This valuable chart can help to forecast the range of time within which a project could probably be completed. It is based on team velocities and their estimate of the future work to be done. Since this is a team’s subjective estimate, it is a good idea to crosscheck it with real-world deliverables. This crosscheck provides an external yardstick for the team, which is particularly recommendable if the team is entering unfamiliar ground. Some real-life crosschecks can be provided by:

• Products of comparable scope that can serve as a benchmark in product development.
• Size and complexity metrics of existing databases and code in migration projects.
• Function-point analysis.

Whatever the reporting consists of, if mutually accepted, it can become a common language between teams and stakeholders. They can start using this language to talk about where the project stands and what the issues are.

Stakeholder management

As mentioned before, project stakeholders need to be well-informed. But what if a major problem occurs? What if a decision is to be made amid strong dissonance among the stakeholders?

Practice 3: Manage stakeholder expectations

However good your reporting is, it is important to keep in mind that it remains a simplified view of reality. In an agile project, reports will help us to roughly estimate a time range within which a project realistically can reach its main targets. However, we do not know and do not aim to know in detail what scope will be delivered then. On the contrary, we want to give ourselves leeway to adapt – “responding to change over following a plan”, states the Agile Manifesto.

That may not always satisfy the expectations of stakeholders who want precise delivery dates with predefined results. In order to build stakeholders’ trust, it can help to openly convey the uncertainty in any forecast. Stakeholders with different business backgrounds can relate to explanations if they hear these in a language they understand. It is the job of the project environment facilitator to keep this information flowing smoothly. He or she takes over this responsibility from the product owner, who can then in such discussions push for what he or she thinks is best for creating a great product for the customer.

Practice 4: Turn affected stakeholders into involved stakeholders

Publicly convey problems as the natural things they are in large projects. There is hardly a better thing to do to wither an ominous threat than exposing it to daylight. A problem then becomes a chance to involve your stakeholders in the process of solving it: offer affected stakeholders information and possible ways to contribute. This can turn them into involved stakeholders: people who contribute instead of comment on the project from a convenient vantage point. Any stakeholder’s project evaluation will from then on be in part an evaluation of his or her own work. What better stakeholder commitment could a project wish for?

Even if the stakeholders bounce the problem and solution back to the project, playing it open will still engender the most important asset in a project: trust.

The product owner and the project environment facilitator apply this practice together. While the facilitator can moderate such discussions (which can get heated at times), the product owner can focus on “delighting the customer”, Stephen Denning’s first principle of radical management (Denning 2010, p4).

Communication between inside and outside

George Bernard Shaw allegedly said that “the single biggest problem in communication is the illusion that it has taken place.” Direct communication in agile setups can allow for multiple communication loops of asking and reframing, avoiding many illusions. But how can direct communication be maintained among multiple stakeholders and multiple teams? If we follow the idea of self-organization being in the DNA of an organization, then communication must be self-organized as well. However, when circumstances change, e.g. when a new large project is launched, smoothly functioning communication might take time to evolve – particularly if people in and around a project don’t know or even mistrust each other. Having adequate spaces for getting to know each other and finding commonalities can facilitate project communication and resolution of conflicts.

One example of a project that makes it exceptionally difficult to establish effective communication is a company merger, as different cultures and opposing interests collide. One approach to such projects is the unfriendly takeover, which aims to establish one dominating culture over the other – with one organization and all its experience usually ending up a big pile of collateral damage. The following practice pursues a more collaborative approach. It can be used in mergers or other situations where there is little trust in and around a project:

Practice 6: Don’t stand in the way of communication but facilitate it!

As project facilitators, think of the right time and the right settings in which the key stakeholders can debate sensitive issues with team representatives. Try to provide a safe environment for discussion. Let the debate flow as long as it heads in the agreed direction within the agreed frame. Do not try to control or evaluate the contributions made. If the conversation heats up, make sure that it is a fair fight but do not step in the line of fire.

At one merger project that was conducted with agile teams, we set up an off-site workshop with one managing director from each of the two merging IT companies plus representatives from all teams working on the project. The agenda was to create a common picture of the situation and to debate some concrete issues at hand. As a leadership team, we merely functioned as facilitators there, giving good thought to the time, place, and agenda of the meeting. In our perception, the vivid emerging discussion grew the trust of the managing directors as they found some of their perceptions about the project dissolved. At the same time, the project teams expressed their commitments to the project right to the face of their managing directors. This commitment was like an invisible contract that had a lasting effect. All in all, the organizations took one important step forward in their struggle to find a way together.

What can be taken away?

In summary, the holistic approach described in this article offers a setup and practices to address the key challenges of large agile projects. It has been deduced from successful agile projects spanning five to 15 teams in size and can be reused as a beacon in setting up future ventures. It understands organizations to be subject to constant change, and change as something that requires facilitation. This requirement creates room for leadership, a new form of facilitative leadership that aims to channel the forces within and outside a project to push it forward. The approach embraces LeSS as an effective basis from which to deal with operational challenges. It reaches further by introducing two new roles: the project facilitator and the project environment facilitator. Together with the product owner, they form a leadership triangle that is fit to meet the main challenges and risks that large projects typically entail. The article further provides a selection of practices that can help this leadership team in their day-to-day work.

About the Author

Thomas Spielhofer lead his first agile project in 2001 – a new Internet banking venture that was built from scratch with extreme programming in nine months. Since then, he has helped to introduce Scrum to organizations as a responsible line manager and as a consultant. He is co-founder and managing director at Y Unternehmensberatung in Austria, where he works as a systemic and agile coach. Thomas has undiminished curiosity about agile methods, which he pursues as editor of Platform for Agile Management.

References

1. Bachl, Walter and Spielhofer, Thomas (2010), “Successful leadership with Scrum: a case study”, Platform for Agile Management. 
2. Böhm, Christina and Haselberger, David (2012), “The Concept of Transparency in Agile Project Management”, Platform for Agile Management.
3. Charron, Todd (2013), “Scaling Agile at Spotify: An Interview with Henrik Kniberg”, InfoQ. 
4. Cohn, Mike (2010), “Succeeding with Agile”, Addison-Wesley.
5. Croome, David (2014), “Scaled Agile in der Praxis”, Agile World. 
6. Denning, Stephen (2010), The Leader’s Guide to Radical Management, Jossey-Bass.
7. Elssamadisy, Amr (2013), “Has SAFe Cracked the Large Agile Adoption Nut?”, InfoQ. 
8. Hundermark Peter (2014), “Do Better Scrum”, v3.02, ScrumSense - soon will be available for free download on InfoQ. 
9. Larmann, Craig and Vodde, Bas (2010), Practices for Scaling Lean and Agile Development, Addison-Wesley.
10. Larman, Craig and Winn, Matt (2014), “Large Scale Scrum (LeSS) @ J.P. Morgan”, InfoQ.
11. Leopold, Klaus and Kaltenecker, Siegfried (2012), Kanban in der IT, Carl Hanser Verlag. (English version due 2015)
12. Luhmann, Niklas, (2011), Organisation und Entscheidung (Third edition), VS Verlag.
13. Kaltenecker, Siegfried et al. (2011), “Exec Summary of the study on ‘Successful agile leadership’”, Platform for Agile Management. 
14. Königswieser, Roswita and Exner, Alexander (2008), Systemische Intervention, (Ninth edition), Schäffer Poeschel Verlag.
15. Sliger, Michel and Broderick, Stacia (2008), The Software Project Manager’s Bridge to Agility, Addison-Wesley.
16. Spielhofer, Thomas (2011), “Agile requirements management saves you from trouble, doesn’t it?”, Platform for Agile Management. 
17. Spielhofer, Thomas and Kaltenecker, Siegfried (2012), “Agile Leadership Model”, Platform for Agile Management. 
18. Walton, Helen (2014), “The Agile Organisation: Are You Ready for Revolution?”, InfoQ.