This post is cross-posted from the Tabar page at their blog

LeSS is more in Australia

It was great to have Bas Vodde in Melbourne from 24 - 26 February 2015 to bring the first Certified LeSS Practitioner course to Australia. Its been several months in the making following a plot with Bas to visit Australia, crafted over great Japanese barbeque and Sake at Clarke Quay in Singapore. The Melbourne location was also good enticement to exploring Tasmanian Whisky in pursuit of the most excellent in the world! With that trigger discussion still clear in my memory I started day 1 of the 3 day LeSS training with Bas and 15 others at our partner organisation Elabor8’s training room.

My initial expectation of LeSS was that there could not be that much more to scaling Scrum that we weren’t already intuitively doing in some way, so anything new under the sun? I was very wrong! It dawned quickly that what Bas presented was taking Scrum itself to a whole new level of excellence! What I learned was somewhat of a surprise because “LeSS lets you do better Scrum” too. It’s not only about scaling teams and large product delivery but also at the same time amplifying the practical goodness at the heart of Scrum i.e. the agile stuff that really works. The course also brings many new agile aspects to the fore while also remaining simple, compact and focused. The particularly powerful concepts that resonated deeply with me were:

• Steps and strategies to evolve Agile scaling into the wider organisational context in a low risk productivity enhancing way
• Building cross functional feature teams across the organisation while driving understanding and contribution to the business domain
• Applying organisational, product and process improvement from running retrospectives (overall) at scale emphasising that learning is at the core of LeSS
• Specific roles for management steers them in support of teams and not control of people
• Managing the one product backlog and driving Done and Un-Done work to get to extended enterprise level “totally Done”
• Sincronisation of sprint time boxes into the same calendar cycle
• What do we do when the product requires more than 8 teams i.e. going “Less Huge”
• Two step sprint planning to cover enterprise level and team level planning for delivery
• Managing the backlog according to dynamic requirements areas that reflect the enterprise contexts
• Moving the teams and the organisation structure to customer and whole product focus
• Applying Less principles underpinned by systems thinking that further enhance and support better Scrum
• Moving away from project focus to continuous emergent Inspect and Adapt driven delivery
• Moving from component teams to feature teams using a planned strategy based on a long term adoption map
• Sometimes temporary fake product owners are valuable and needed!
• Using and authority matrix to differentiate responsibilities for product owners, management and teams
• The simplicity at the core of LeSS will de-complicate the organisational structure over the longer term and drive efficiency

In summary LeSS is not only about how to scale Scrum into a transforming organisation but also how to do better Scrum at every level. This emerged strongly from the stories throughout the training informed by Bas’s years of experience and deep thinking on practical application of LeSS.

Indeed a great start to more LeSS being done in Australia! I am convinced that LeSS.works as what happened to the relatively recent and unknown Tasmanian Whisky is also earmarked to become the de-facto reference to Scaling Agile excellence in the world. Go LeSS!

This post is cross-posted from the Gosei page at their blog

Comparing LeSS and SAFe

Both Large-Scale Scrum (LeSS) and Scaled Agile Framework (SAFe) have a history with Nokia and use it as a reference. What most people do not realize, is that Nokia was two big loosely coupled companies. LeSS was and is mostly used at Nokia Networks (now still called Nokia Networks) side while SAFe was mostly used at Nokia Mobile Phones side (now mostly Microsoft or closed down).

Both sides of Nokia were gradually facing the same problem that they later tried to solve by scaling Agile: overspecialized component organizations and external coordination. Most big organization around the world face the same problem. Nokia provides a relevant story to understand and compare what these approaches offer.

Our analysis of Nokia may seem blunt, but it is for a reason. We want to communicate our point of view clearly. Coordination Chaos is significant and treacherous pattern. Its real impact will surface late.

In big organizations the culture and organizational structures constrain what people are able to do. We want to express our empathy for the individuals, who have done their best as the members of the system.

The authors contributed to the implementation and evolution of LeSS and SAFe at Nokia Networks and worked with SAFe in Nokia Mobile Phones. Gosei founders have been working with all Finnish companies that tried out SAFe in the first wave about five years ago. One of them is currently implementing SAFe en masse in an enormous global product company. We have seen the SAFe SPC course by Dean Leffingwell last year and now certified LeSS trainings by Bas Vodde and Craig Larman.

What problem is “scaling Agile” solving?

Nokia was growing about 35% per year for long times, which is very hard to lead. The natural solution was specialization: component teams, functional teams, specialists know, managers decide, and teams execute. This was true for both Nokia Networks and Nokia Mobile Phones. Both companies relied heavily on program and project management in getting things done.

This became increasingly difficult by the time. The more overspecialized organization needed even more external coordination. This pattern of Coordination Chaos was one of the main reasons leading to the infamous “Burning Platform” of Nokia Mobile Phones.

The hidden problem – learning

By taking the path of specialization and external control of the front-line engineers, Nokia needed less education for the mass of them. The specialists knew, project managers coordinated, and intelligent recruits easily learned their narrow roles. This experience suggested that more learning was not needed, and strengthened the machine metaphor in management thinking. This management thinking optimizes resources and cost, locally and in the short term. It treats learning as cost, especially learning outside of one’s special role.

Let’s contrast this with a Scrum team (the team + the product owner + the Scrum master). It cross-learns inside the team. It inspects and adapts at the market. Here learning creates value. This is what you want to scale up.

Both LeSS and SAFe are based on Scrum at the team level. Both have their own selection of Lean and Agile practices to support the scaling. The critical difference is, how the proposed process and organizational structure drive learning, because Organizations learn like horses

SAFe and Nokia Mobile Phones problem

A new Nokia phone model had a limited life span and a tight deadline. The huge backlog (plan) had detailed old and new features for the numerous components. Every component needed to implement system-wide features, like a new consistent UI design.

As the solution, the first SAFe process was introduced internally at Nokia Mobile Phones around June 2009, having release trains, planning meetings and 4-level hierarchy in the product backlog. There was the first version of the famous SAFe big picture, accompanied by 170 slides carefully crafted together by Dean and Nokia management. Since those days, SAFe has incorporated a wide set of Agile practices and dropped obsolete Nokia flavor. However, the core value is still explicitly there:

Program Execution – SAFe

When looking at the market, this seems to be the solution to the perceived problem in many organizations.

The core of SAFe is a new very detailed process layer on top of Scrum, intended to coordinate the big mess and give predictability. In many cases the new process may stop old stupid things and take a step towards Agile values. For example starting all-hands-planning may energize and improve communication. SAFe removes projects and encourages to control Work In Progress.

It is difficult for the authors to imagine that an old troubled organization would be able to implement SAFe process by the book. The competence of the people will limit the possibilities. In a large organization, there will be diversity between different implementations of SAFe. Things will change by the time in each implementation of the SAFe process. It is a philosophical question, when and how long the new way will still be called SAFe.

The detailed process serves as a very good sales story. Based on the actual circumstances something different will emerge.

Learning in SAFe

Organizations as cultural learning systems will optimize the one primary focus. In SAFe that is program execution, and the given process defines the way. This is not inviting learning at the organizational level. There is the danger that investment in learning is further delayed, when the primary goal shows some success.

Second comes the new Lean and Agile way of working for the several defined roles. For the decision makers it is a new commitment step, scaling the investment in learning. SAFe consultant network supports this by training and consultation. The actual practices are not especially unique for SAFe, so the real question is how good are your consultants, and how much do you invest in learning.

LeSS at Nokia Networks

Nokia Networks is producing extremely complex and long-living products. Some products were required to offer 20 years of maintenance. Still the development was mainly coordinated with heavy release programs, often lasting years.

The evolution of LeSS is not attributable to a single corporation. LeSS at Nokia Networks started around 2005. Now, after nearly ten years there are LeSS huge organizations still going on in Nokia Networks.

So what was the perceived problem at Nokia Networks? Lack of productivity and flexibility in the product development. A more careful analysis reveals the death spiral: fragmented organization, cluttered flow, confused leadership and narrow learning. They are the root causes of Coordination Chaos. LeSS is reversing this spiral. Authors’ condensed wording as LeSS value proposition is:

More with LeSS. – LeSS

LeSS is scaling Scrum teamwork up and out without adding layers or processes. On the contrary, it is simplifying the organization radically – more with less. The teams take care of the technical coordination. The product owner team works with the market and with the teams. The managers become coaches. No layers of indirection are added.

Feature teams is a key concept in LeSS. Specialization is necessary. It creates clarity and efficiency. However, it is critical in which dimension you specialize. LeSS clearly recommends to specialize in the customer-centric and product, not in component direction.

If the organization is new and growing, LeSS can give some golden advice to avoid the death spiral.

There is no magic available. Transforming a large old organization does not happen overnight. There are many phases and silos along the process. It takes time to pay back the organizational and technical debt. LeSS adoption respects inspect and adapt. You start in one corner, make sure that things work, and then expand. The long lasting cases are best way to study, what kind of value has been created.

Learning in LeSS

It has surely become clear, how central learning is in LeSS. The coordination cost transforms to investment in learning. LeSS tradition supports this by sharing experience of what has worked in what context.

Strategic decision

Which way to go? The decision is heavily influenced by how the decision makers perceive the organization’s situation.

SAFe suggests a direct solution to a burning perceived problem, a new better program process, explained in familiar terms. It is easily understood by the traditional operative management. It is scratching the same coordination itch as the massive project and program management industry, adding Lean/Agile methods.

LeSS provides a radical long-term solution. The simplicity of LeSS makes it versatile. Different kind organizations are able to use it for long time. However, because of this versatility, the decision makers, including the top management, need to have more understanding and courage to take this path.

In many large companies, the top management actually wants to have the radical change. They are for example establishing internal startups to create totally new market-oriented culture. LeSS is a way to scale this evolution up.

Next

In the next blogs we will explore more details, for example the very different ways to scale Scrum, and the organizational layers of SAFe versus the customer oriented teams in LeSS. We will comment 1) leadership and power 2) organizational structure and hierarchy 3) flow of value 4) learning, adoption and continuous improvement.

We will give a session about this topic at XP2015 in Helsinki.

Cross-posted. Find the original at the SolutionsIQ Website at this link

Thanks for taking the time to read (and watch) this introduction to LeSS (Large-Scale Scrum)!

If you prefer video to text for an introduction to different aspects of LeSS, please take a look at these videos at the the LeSS website less.works. From that list, a good video to start with is Introduction to LeSS (short video) – Craig Larman.

A Creation Story

Where does LeSS come from? In 2002 I wrote the book Agile & Iterative Development: A Manager’s Guide. At that time many people “knew” that you couldn’t scale agile development. But from my experience within Valtech — that does outsourced development, and where I worked — we could see that it was possible. And I started to get requests from clients to apply agile concepts and especially the Scrum framework — as an early-days Scrum coach starting in the late 1990s, and early Certified Scrum Trainer — to large-scale development. This eventually led to work with groups such as Ericsson, UBS, Bank of America Merrill-Lynch, JP Morgan, and and Nokia Networks, among many others. (By the way, Nokia Networks is the telecom infrastructure group, not the Nokia mobile devices group eventually bought by Microsoft.)

You can read more about some of these client experiences at the LeSS case studies site.

A key thing to appreciate about LeSS is that it wasn’t created on “on paper” or in theory; it came out of our experience working with many clients since 2005 who have been adopting large-scale Scrum.

While at Nokia Networks in early 2005 it was a great pleasure to meet and start to work with my friend Bas Vodde, who is the co-creator of LeSS. Bas played a key role in helping groups adopt large-scale Scrum at Nokia Networks, as part of their internal “Flexible Company” team, and was also a member of the leadership team of a large (roughly 1,000 people) multi-site product group that was adopting LeSS. So Bas had a tremendous amount of in-depth long-term experience in introducing and doing large-scale agile development, from debugging large organizations to hands-on embedded systems development. He wasn’t a classroom teacher or someone who just spent a few days in a management meeting talking about scaling. He was in the trenches doing this for years. And he has a wealth of insight into systems thinking, modern management principles, and agile and lean systems, including Scrum (as he is also one of the early Certified Scrum Trainers).

Bas was and is a great complement to my coaching and consulting with scaling agile development, and I’ve learned a lot from him. And we’ve both learned a lot from our customers adopting LeSS over the years. So we ended up collaborating as partners in coaching and communicating about LeSS, starting with the first LeSS book we wrote in 2007, based on our experiences with customers, Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum. This was followed by our 2009 second volume on LeSS, Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum. And now we’re completing our third book on LeSS, which is a simple primer to help people successfully get started, Large-Scale Scrum: More with LeSS.

LeSS is less

If I had to boil down a description of LeSS to something really short, one thing I’d say is, “LeSS is relatively small and simple.” You see, I have a background also consulting and coaching in the 1990s with the RUP (Rational Unified Process). One of the key insights I got from that experience is that frameworks with a lot of definition and “prescriptiveness” don’t really work in terms of large-scale adoption. They aren’t contextual enough. They inhibit empirical process control (a key Scrum principle) and the unique learning and exploration which must take place. Development groups (and the work of development) are just too varied for anything like a detailed highly-defined framework or process, or much of a standard recipe. Now, the RUP tried to counter this concern with the idea of “tailoring down” or deleting elements to make it ostensibly simpler. That sounds fine in theory, but I saw in the real world that it just didn’t work. Groups ended up “adopting” too many roles, structures, processes, and techniques and becoming overly ‘defined’ and complex. Even though they were advised to “only take what you really need from the buffet of options.” And people in these groups had the assumption that they could delegate or avoid the learning, discovery, and resolution of their systemic weaknesses because “the problems are solved by adopting the framework we’ve bought.”

But here’s something we’ve learned: more defined process leads to less learning, and conversely less defined process leads to more learning.

…But LeSS is not Minimalist: The Goldilocks Zone for Shu Groups

Now, the logical conclusion of “less defined process leads to more learning” is to adopt essentially no defined process or framework, or as a variation, to adopt a system with only a few simple principles. For example, there are ‘systems’ such as the Learning Organization movement, which recommends systems thinking, personal mastery, mental models, shared vision, and team learning. Who can argue with that? These are great principles!

But… run this experiment: Go to a telecom infrastructure product group of 500 people in 5 sites, that has been working a very traditional organizational design and culture for decades so that the old system is really baked in, all the way through people’s brains. Or likewise in a bank. And then say, “Hey folks, do this: systems thinking, personal mastery, mental models, shared vision, and team learning!”

Nothing really changes.

And that’s a second thing we’ve learned over the decades being involved in change initiatives: For a group that is in the beginning-adoption phase of a major change, they need a certain critical mass of concrete advice about structure, policies, processes, roles, and so forth, in order to actually do something about the change. Otherwise, if it is a “Shu phase” (the beginner-learning-fundamentals phase) group with strong traditional elements, either they don’t really change anything, or because of strong status-quo forces that resist change, then the change is ‘faked’ in some way to superficially conform to the change, but when you scratch below the surface, it’s the same old system. By the way, often that faking is done by redefining or overloading the new terminology to mean basically the same as the status quo.

So, there’s a Goldilocks zone for a modern development framework for a Shu-phase organization, in between “just a few simple principles” and “lots of roles, structures, techniques, and processes.”

We observe (and many others have observed) that regular one-team Scrum is very much in that zone, for a small product group. Its simple concrete elements provide just enough definition to enable its deeper principles to be realized: empirical process control with transparency, self-organization, and so on.

And similarly LeSS (large-scale Scrum) takes this same theme: just enough concrete elements for a Shu-phase organization to make real changes and know what to do to get started, to enable the deeper principles of empirical process control with transparency, and self-organization. But it’s just barely enough. There’s vast space in LeSS for the unique situational learning and adaptation that is required for the myriad and unique organizations. LeSS Focuses on Root Causes in the Organizational Design

Also, in boiling down a description of LeSS to something short, I’d say, “LeSS focuses on the root causes of organizational weaknesses when scaling.” Many organizational-design experts know that key root-cause problems include (1) the existing status quo organizational structures and roles, and (2) command-and-control policies that deny the reality of inherent variability and human motivations in development work. But similarly, many experts or consultants tip-toe around these issues and avoid raising them, because they challenge status-quo power structures and beliefs. That’s another reason why “fake change” happens. Change is only allowed up to the point that it challenges or interferes with status quo roles, power structures, and policies…. “Well, you programmers are welcome to adopt this scrum-thing. Do whatever you want to be more efficient. But make sure it’s all done by your committed delivery date!… And the project managers will be measuring you to ensure you’re on track.”

Of course, any “change” introduced into such an organization will just be a superficial layer of new terminology and techniques on an essentially un-changed system…

BEFORE, TRADITIONAL: UX analysts write up an Experience deliverable to give to others, Business Analysis team write use cases and hand them off to programmers, Architects define UML PowerPoints and push their designs to programmers, programmers write code for the testing group to test, after it’s been integrated by the Integration Manager, etc.

AFTER, ‘AGILE’: Agile-UXers write Experience Stories for others to read, Agile-BA teams write user stories for handing off to programmers, Agile-Architects define Architectural Epics and push their designs to programmers, programmers write code for the Systems Team to integrate and test, etc.

Really, what’s changed?

But the good news is that LeSS doesn’t skirt around these key issues: it directly addresses the root cause organizational design issues that are at the heart of systemic weakness when scaling: myriad single-function teams handing off WIP deliverables to other teams, the Contract Game, command and control management, entrenched status quo positions, and so forth.

Success with LeSS

Of course, there’s more to understanding LeSS and adopting it than this brief article has touched on. A great way to get started is with the Certified LeSS for Executives or Certified LeSS Practitioner course (see course listings), reading and seeing videos at the less.works website, working with a coach who has hands-on experience with LeSS (see coaching companies), and reading the three books on LeSS. LeSS is simple but powerful, and we want to help you succeed with your adoption.

We’ve got a guest post from Ran Nyman who briefly reviews last weeks Certified LeSS Practitioner course:

Last week I participated Certified LeSS Practitioner course that was thought by Bas Vodde in Helsinki, Finland. Bas is one of the key persons behind the LeSS-framework, who has co-authored 2 and half books on the subject (The half if upcoming Large-Scale Scrum book that is not published yet). Before the course, I had spent time at reading already published books and draft of the upcoming book. The amount of material is overwhelming, and it was interesting to see how all the content can be compressed to 3 days course.

Overall impression was that Bas covered the relevant content in great detail, and some of the topics he just mentioned. This approach worked well since no one wants to see a slide show with five slides per minute and be overwhelmed by information overflow. Bas managed to select key topics to focus, so the training created logical whole.

I picked some themes from each day that I felt important from each course day. In day one we focused on learning and knowledge in an organization and what impacts on organizational design those have. In day two we started by defining products and how the definition affects LeSS adoption. Bas linked the Definition of Done as one of the key driver for LeSS adoption which was surprising. Day 3 we spent in great detail looking how LeSS works what structures it has and looking at steps that are needed to start LeSS adoption. One takeaway from this was that after having initial LeSS structure in place focus on the outcome instead of trying to form the organization to perfect shape.

I am strongly recommending this training to all doing or considering doing any format of Agile product development in large organizations since it will give you principles, framework and guides that will increase your success in it.

Last week, I finished the first Certified LeSS Practitioner course in Helsinki, Finland. It went really well I think. A lot of my training material is in a new order than I’m used to so that caused me to be somewhat uncertain about timing and things like that. Also the participants were probably above average in LeSS knowledge as some of them I’ve been working with for years (whereas some were quite new).

The first day, we focused on the LeSS overview and the LeSS principles. We also did some causal loop diagramming. One team decided to use it to ‘proof’ that offshoring was a bad idea but the further they went the better it started to loop. It wasn’t what they were expecting making it quite amusing. We also looked at feature teams and component team structures.

The second day started with some reflection and we discussed a lot about what the products where that people were working on. Mostly what the advantages and disadvantages were at defining product at a certain level (and how that impacts management practices). The biggest thing for this group was probably the creation of Feature Team Adoption Maps which caused long discussions about what steps the selected products would need to go next in their LeSS adoption. We discussed the Product Owner in-depth and spend time looking at changes in management practics and organizational structures when adopting LeSS.

The last day started off with the LeSS events and a discussion on how to deal with really large backlog items (with the concept of Leading Teams). We stil dived a bit into engineering practices and moved on towards adoption of LeSS in your organization. I spend about an hour sharing two case studies of LeSS adoptions with the group and the last day ended with ScrumMaster discussions.

All in all, I felt the course went pretty well. It gave me a lot of feedback on further improvement, but the feedback from the group was very positive. I’m excited about it and looking forward to the next course, hopefully in Melbourne. If you are in Australia, don’t forget to register for the course