Large Scale Scrum (LeSS). It is the framework for scaling agile development, done by multiple teams, as they work on same product and work for a single Product Owner. In order to be effective, LeSS requires organizational descaling that means simplification/flattening of organizational design.

What is Organizational Design? To understand it better, let’s look for analogy in construction industry. What is required to erect a building? In our analogy, we shall stay simple: bricks (foundation block) and cement (connective material that holds bricks together).

Imagine two buildings: Building A and Building B.

Building A uses brick as its main foundation block. In fact, when looking at the building’s facade, the most prevalent object, caught by a naked eye, is a brick. Bricks are positioned next to one another, with just enough cement in-between to glue them strongly together. There is no excess of cement anywhere: the connection layer is very thin/lean.

Architectural design of building A is simple and flexible: the structure is flat (one-story high) and it sits on strong foundation, also made of brick. Because of its design, architectural adjustments are possible in various sections of the building, independently, with little additional labor. Due to such modular structure, the building can be expanded laterally, just by adding more bricks to the wall. Of course, due to its flat structure, the building is also very stable and can withstand a strong wind, flood or an earthquake: practically nothing can be shaken off or washed off the building.

When waste is produced inside the building, it becomes noticeable immediately. Waste disposal is also very simple: it does not require complex chutes or automated waste ‘packaging’ systems. Waste removal can be mostly done manually, by building residents. Any necessary supplies (e.g. food, water, furniture, other materials) can be easily delivered to any building area, without the need of advanced technology or mechanics.

Finally, building inspection and maintenance is a very easy process, because of flat structural design: foundation, walls and floor assessment – all can be performed with a naked eye; corrections can be done timely and efficiently.

This is what building A looks like:

Building B is made of a very few bricks and a lot of cement in-between that holds bricks together. In fact, the ratio (by weight) of bricks-to-cement is very low.

Architectural design of building B is rigid. It has many floors, with top floors made primarily of cement. The building represents a heavy and monolithic structure, and although it also sits on brick foundation, as building A, the bricks are widely spaced with lots of cement in-between. This means that the overall weight of building B is dangerously high (foundation can crack). The building’s expansion limit, to accommodate growing occupancy demands, is low: it cannot be easily extended (scaled) horizontally with a couple of extra bricks added to the side, because the bottom brick layer would require multiple horizontal cement layers added on top – to follow the originally intended building design. If additional cement layers are added on the top of foundational brick layer this will further increase risks of foundation cracking.

Waste disposal is a serious issue for Building B. While waste can be relatively easy removed from the bottom floor (it is also not in abundance there) and, to some extent, from top floors (by taking it to the roof and using a waste removal chopper !:-) ), there is a huge amount of waste that gets accumulated at middle floors – and it sits there. It is extremely challenging to remove this mid-section waste and what building management does from time to time, is ordering for this waste to be moved from one floor area to another (the building is very compartmentalized). Sometimes, waste gets moved to floors above; sometimes – below. This creates an illusion of waste removal. But waste remains.

Delivery of supplies and food to Building B occupants is a real challenge, especially if elevators are out of order. This makes occupants angry and frustrated and sometimes they turn onto each other; become competitors and rivals.

Finally, building inspection and maintenance is a nightmare for Building B. Many living units are out of compliance with building codes, but violations (and violators) are hard to identify and remove because true facts are well concealed and numbers are gamed by building occupants.

This is what building B looks like:

Large Scale Scrum requires organizational design that is analogous to the construction represented by Building A.

In LeSS:

Team represents the main building block (a brick). Selected team representatives (developers) and mentors-travelers–ensure effective coordination/connection between teams. There are no additional roles required for coordination. Cross-team events are minimal (Overall Product Backlog Refinement, Sprint Review, Overall Retrospective).

If product definition widens and more developers are included, another team can be formed and positioned laterally to existing teams – just like a brick. Should product definition become too wide and the number of required developers exceeds 50-60 people (8 teams), another product area can be identified (new independent module, made of bricks). Now, LeSS becomes LeSS Huge. The only additional coordination that would be required in LeSS Huge is between Area Product owners and Overall Product owner – for strategic planning of Potentially Shippable Product Increment (PSPI) at the end of every sprint. In both, LeSS expansion from 2 to 8 teams, and LeSS Huge expansion beyond 8 teams, there is no need for additional coordination that is different from what is described above (no extra cement needed to keep bricks together). Also, in LeSS Huge, when one Product Area expands and another one shrinks, moving the whole team from one area to another, does not require expansion or shrinkage of any additional “supportive” organizational layers.

By design, LeSS foundational structure is very lean: flat, fungible and cross-functional. There is no waste or overhead with roles, responsibilities, events or artifacts. Everything is very minimalistic. If any waste is generated in LeSS, it has practically nowhere to hide.

Because there is so much transparency in LeSS, waste is seen immediately. Any findings of waste or any other required improvements to individual teams or LeSS framework, can be effectively done in Team Retrospective or Overall Retrospective, respectively. Thanks to its flat organizational structure, LeSS (and LeSS Huge) don’t have to worry about waste removal from additional organizational layers – they [layers] just don’t exist. There are fewer layers that sit between LeSS teams and LeSS Product Owners and these layers are much thinner.

What happens with LeSS organizational structure during rough times: slow down in business, increased market competition? Arguably, because LeSS is so lean and there is continuous learning, it is much less likely that LeSS people will be displaced. LeSS is also more likely to withstand other types of reorgs and shake-ups because LeSS has very few moving parts, loose pieces or weak links.

Organizational designers that support LeSS think like building architects that want to build strong, reliable, easily-maintainable, low-waste, cost-effective and long-lasting structures!!!

Many thanks to all LeSS Trainers, Coaches and Practitioners building reliable structures ! ;-).

Introduction

The first LeSS conference started with assumptions, questions and unknowns.

One assumption was that most people come to conferences wanting to be entertained through interesting and inspiring speeches with other interesting people. As fun as that may be, the actual benefit to the conference attendee seems minimal. At best, they walk away inspired, a couple of new thoughts & contacts. What we wanted, was a deeper learning experience through interactions over traditional speeches. The idea of teams became a central theme of the conference. This raised a number questions.

Can a team of five full-time consultants who have never organized a conference before…organize a conference using Slack? Can we create a conference optimized for learning rather than simply entertainment? Would conference attendees be willing to participate in tactile exercises rather than simply listening to interesting speeches? Would (given the opportunity to opt-out) attendees create teams designed to encourage learning through dialogue? How do you even form teams of 170 people that have never met each other?

The only way to answer these questions was through experimentation; specifically a field experiment:

Field experiments are so named to distinguish them from laboratory experiments, which enforce scientific control by testing a hypothesis in the artificial and highly controlled setting of a laboratory. Often used in the social sciences, and especially in economic analyses of education and health interventions, field experiments have the advantage that outcomes are observed in a natural setting rather than in a contrived laboratory environment. For this reason, field experiments are sometimes seen as having higher external validity than laboratory experiments. However, like natural experiments, field experiments suffer from the possibility of contamination: experimental conditions can be controlled with more precision and certainty in the lab. Yet some phenomena (e.g., voter turnout in an election) cannot be easily studied in a laboratory -Wikipediea

The experiment

The hypothesis

Having conference attendees self-organize into teams will:

Increases the chances that you will try team self-design in their own company

Accelerate learning through dialogue and creating a product

Longer lasting relationships after the conference

More fun

The procedure

1. Bejewl each attendee

As part of the registration process, each attendee was asked 4 questions. Based on the answers, each attendee received a jewel to affix to their badges.

Are you a certified LeSS practitioner

Are you a developer

Have you ever tried implementing large scale scrum

Do you have any visual artistic abilities

2. Form the teams

I had originally budgeted for 75 minutes. The whole process took roughly 60 minutes. What I covered:

Explain the purpose and the background of the team formation exercise (see article)

Team formation guide(see deck to the right)

Form, storm, norm, perform in 5 minutes. After forming, I asked each team to get to know each other through a name association game and one interesting fact about themselves.

Brand the team. Each team selected a name and some even created a logo.

Tweet a picture of the team(see below). My idea here was that there is something about taking a picture and tweeting it to the world that would make the teams more “real”.

Explain next steps:

Meet regularly for 30 over the next two days

Create potentially publishable content for the scaling community

Sprint bazaar at the end of the conference

3. Re-calibrate the teams, create a product & Review

Re-calibrate the teams (20 minutes). On the second day, Bas facilitated a re-calibration of the teams where teams could disband or choose to join another team.

60 minutes to create a product. Many teams had been reflecting by creating visualizations of the conference. These final 60 minutes were to allow the teams to focus on the creation of an artifact that would be demonstrated at the sprint bazaar.

Sprint Bazaar and choose a winning team.

Each conference attendee was given 30,000 in LeSS money. (We are a very wealthy conference :)

Craig reviewed the concepts behind a sprint review

Although, competition is not part of an actual sprint review, we decided that teams competing using the LeSS money would be fun.

Conference attendees were given 6 cycles of 5 minutes to review the team output.

A single team won by creating a very clever game.

Observations & Initial data

~170 attendees

5 opted out of the exercise

~18 teams were formed

~11 products were created

1 potentially publishable content

~5 teams disbanded on the first and second day

Teams formed in less than 10 minutes

Attendees reported that the creation potentially shippable content was too aggressive a target for teams

Original post

The original post has a survey result and additional photos of the teams.

Designing the LeSS Conference

The first ever LeSS conference was held in Amsterdam on August 30 and 31. An amazing 186 participants from Australia, Japan, the USA, Finland, Singapore, Switzerland and many more joined us for 2 days of sharing, learning and self-management.

We, the organisers, did not want it to be a commercial conference, in the sense that there would be booths and sponsors influencing the speaker list and so on. We wanted it to be about practitioners sharing real world insights about LeSS adoption. And about letting the world know that there is a way to Scale Scrum and keep its values. We also wanted people to experience LeSS in person.

For the practitioners, we introduced an Experience track with all kinds of case studies on LeSS and LeSS huge adoptions.

For experiencing LeSS in person, we introduced an experiments track. We did 3 main experiments.

Having a team based conference;

Having a Open Space parallel to all other sessions;

Forming into communities.

Furthermore, we did not plan for breaks, only for lunch; did not have a program printed; and we did not have a single person who was in charge. I remember that the people of the venue were searching for the one person to make all decisions, but this person was not there. We all made decisions and leadership emerged.

It was fun for us, confusing for some and insightful for all.

Different Kind of Conference

So, the LeSS conference was a little bit different to a ‘traditional conference

Traditional conferences

LeSS conference

Program printed and stable

Program only online and changing.

Drinks, beer and wine costs extra

Drinks, beer and wine included.

Price over Euro 1000

Price Euro 250

Organisers guess what people need and create appropriate program with tracks and timelines.

People need to decide for themselves and decide what works for them

People work as individuals

People work in teams

Mainly consultants doing talks

Mainly practitioner doing talks

There is 1 person in the lead

Organisers use situational leadership

You expect to be entertained and sit back

You are encouraged to actively participate and take ownership of your learning.

Make money

Needed to add money out of pocket :(

1 t-shirt

3 t-shirts

Team experiment results

The teams-based conference experiment is considered a success. We now know that we are going to repeat this at the next LeSS conference in London 2017. A lot of people told me that they really enjoyed working with the team; getting to know people and socialising was good, and especially the discussions after the sessions.

“…people in my team went to the same talk but had very different views on what was said…the discussions we had gave some great insights…”

Of-course not everybody enjoyed the team experiment, but then again you cannot please everybody all the time :)

Community experiment results

The community experiment is considered a success also. We now know that we are not repeating that one :). But I am actually happy with the results. A number of new LeSS communities started in Berlin, The Netherlands and also online using Slack and our LinkedIn group is growing rapidly. @Viktor is having a busy time accepting all the requests.

What’s next

We are already planning for the next LeSS conference in 2017; it will be in London. We are also already thinking about new experiments to do. So, if you have suggestions the coming year, please share them with us.

Oh, yes, we do not want to loose any money next year and will aim for break even.

Achieving system optimisation goals in LeSS

Large-Scale Scrum(LeSS) has incorporated deep Systems Thinking ideas in its recommendations. Whether it’s the way Sprint Review is done or the recommendations around team co-ordination, LeSS recommends system optimisation over local.

In this short post, I would like to share two system optimization goals in LeSS out of many.

Organizational design to deliver the highest business value

Agility

Organizational design…

Traditional organizations have many layers of management with multiple siloed groups turning their machinery as fast as possible. As we all know, this siloed way of working results in local optimization.

To avoid local optimisation in the context of org design, LeSS recommends:

The organizational structure itself is recommended to be lean with no functional organisations like a QA department, a release management or a deployment group. Teams are encouraged to work directly with each other without any intermediaries.

Agility

Agility could be defined as the ability for the organisation to turn on a dime for a dime. It is also the ability to change the course or direction with low cost and friction. See Continuous Improvement Towards Perfection for more.

To keep the post crisp, I will focus on a single backlog vs separate team backlogs.

In LeSS teams pick items from the one prioritized backlog rather than having separate team backlogs.
You might be wondering, how can separate backlogs hinder agility as teams will be more so-called efficient if they can work independently?
The answer is, having a separate backlog not only makes each team to be deeply specialized in one area, but also results in losing the focus on the overall priority. At the end, single specialisation is a bigger problem than becoming multi-skilled as a team.

The actual trouble with multiple backlogs starts when the organisation wants to change the priorities. Due to the nature of single specialisation created due to separate backlogs, the teams won’t be able to turn around quickly and learn new skills thus hindering agility.

The solution is to encourage building T-shaped “teams” and avoid allocating the items upfront to specific teams. Teams should get involved in multi-team PBR reducing the implicit backlog dynamics thus increasing agility and avoiding local optimization.

Reflections from a team manager after visiting the “Large Scale Scrum Conference 2016”

So… LeSS… !?!!

Well, I had read about it over last year or so - on the web and in the book scaling lean & agile development. In my role as agile and lean team manager I wanted more of LeSS after these appetizers - so I signed up for the first LeSS conference.

What was I geared up for? Pretty much just a positive anticipation but from the webpage I had this in mind:

What is Large Scale Scrum Conference 2016?

In this conference there are:

Experiments and Experience

Teams and Communities

Less Booths - More Practitioners

Join us for two days of sharing and learning about Scrum at scale

So what was my experience of the conference then? Well… very interesting.

On a concrete level -

I was at times a bit disappointed yet at other times really delighted with what was going on. Experience ranged from slightly chaotic and confusing to really really great.

Low: A team experiment that initially felt confusing and some not so interesting talks that brought little new that value to me.

High: Talks and discussions packed with deep insight. E.g. Craigs talk on the topic of owning vs renting. To me in some sense about the right to have a meaningful work – presented in a transparent and professional way. Or as in Bas’ talk when he lit a camp fire and took us from the concrete picture of scrum into something more deep and meaningful.

On a meta level –

On a meta level, even lesser experiences have grown upon me. Some experiences have changed into being valuable as I reflect upon the deeper meaning and learnings from them.

What you see and understand is not always the only thing you get – it might mean more as you reflect over time, fill in the blanks and associate it with other stuff that you’ve heard or thought…

So for instance: the above mentioned team experiment had on a concrete level its fair share of miss-communication, people ignoring the role of the facilitator, conflicts and poor team dynamics. On another level it had very interesting and valuable learnings on as I started to observe was really going on. Tuckmans stages of team dynamics for instance. The real experience of self-organizating teams as another example.

I feel it is completely impossible to describe everything that happened on this conference in a short post - but I do feel that I learned a lot, at the same time realize that my organization also could contribute to the agile communities outside my company… and most of all:

I really really appreciated the professional experimental culture with learnings that emerged even during the conference – and impacting the way it was conducted!

Some of the principles – build bottom up, fill in the blanks, experiment and inspect and adapt, self-organize was something that I did not only hear about – I actually was allowed to experience and be part of experiments with said principles.

Do I want more of LeSS after this conference?

O yes.

As a manager that really wants agile I feel liberated from some of the stuff I learned.

Thanks to all that made this a great event from Magnus – ever learning agilst and team manager