Team-based Conference - Conference Review Bazaar

Conference Review Bazaar

In the previous blog post, I introduced the second iteration of the team-based conference concept, which ended with a Conference Review Bazaar. This post collects the output of the Bazaar.

How does it work?

At the end of the conference, the teams get together in their team space and they have an hour to create “a representation of their conference experience.” This could be absolutely everything such as a retrospective, a summary of what they’ve done, a game, a major learning, a website, a test, or a song (?!). My team struggled with finding a nice idea and ended up making a Scrum Master card game (Quartets). I guess we’ll need to productize in the future.

After the team creation time, Craig opened the Conference Review Bazaar, which is done the same way you can facilitate a Sprint Review Bazaar. Each team has some representative which presents their teams work, while the other team members walk around and visit the other teams to see their output. In this case, we added a game element to it where every person could vote for the ones they enjoyed most. This is not recommended on a true Sprint Review Bazaar, but in the Conference Review Bazaar it works well. The Black Ops team created a LeSS Karaoke and they were voted the most interesting product. Below we have a video of them singing the LeSS song.


We don’t have the output of all the teams yet, but will keep updating this post when people send us more photos. If you have a photo of your output and it isn’t here yet, please drop us a mail!

Black Ops

Black Ops

Black Ops
Black Ops

The Super 8

The Super 8



Lesson Learnt

Lesson Learnt

Team-based Conference - Iteration 2

Team-based Conference - Iteration 2

It is already two weeks ago now… the 2017 LeSS Conference in London. I’m still missing the discussion, my team, the wine, the people, the weather. Well… not the weather. It was wonderful, I enjoyed it thoroughly and hope and think the other people did too!

One thing I considered very successful this time was the team-based conference idea. This idea started in the previous 2016 Amsterdam conference. In that conference we experimented with this. The origin is in a discussion the organizing group had, which is that in LeSS we focus on teams… but most conferences are done individually. That felt like not following our own principles… so we thought about how we can make the conference experience more of a team experience. In Amsterdam we tried the first iteration, which was rough but good enough to keep trying. The second iteration was much better.

How does it work?

The essence is to make the conference experience a team experience where you learn together with your team, have a place to return to, people you got to know better, and can create a shared output.

The structure is like this:

  • In the beginning of the conference, we hold a self-designing team workshop so that the people can form their teams.
  • The teams find a space, which is their team space for the rest of the conference.
  • The team has a round of introductions where they share their expectations and create a name
  • After each session, there is team reflection time where the teams share the learning of their session or discuss about the session when they went to the same one.
  • Lunch is naturally also done within your team
  • Near the end of the conference, the team has one hour to create a “representation of their shared conference experience” together.
  • The conference ends with a Conference Review Bazaar where each team share their creations with the other teams

In this blog post, I’d like to share the teams that were creates, in a future post we’ll share the outcome from each of the teams.

The Teams

If you were in one of the team and want to share something about your team or experience, drop me an email and we’ll put it in this blog post which we’ll keep updating regularly.

If your team is missing, lemme know and I’ll add them.

Video of team self-design



Black Ops

Black Ops





Game Changers

Game Changers



Lesson Learnt

Lesson Learnt



Something Catchy

something catchy





The Flying Horses

The Flying Horses

The Super 8

The Super 8

Unknown team

The Super 8

How to Ensure Scrum Teams Launch Successfully

How Most Agile Transformations Start

Most of the Agile transformations I have witnessed have started like this: First, a company raises a strategic initiative on so-called Agile implementation. A large budget is allocated and a tender is arranged to purchase Agile coaching services from companies on the market. Then employees are trained, and the pilot teams start working. However, they immediately stall, because there is lots of tension between them and an old cultural landscape. 

Here are only a few of the issues that pilot Scrum Teams usually face.

  • Teams organized around internal business processes and, consequently, artificial dependencies on other teams.
  • No political will to assign a real Product Owner, who would be the product’s mini-CEO and could quickly make decisions, increasing both the product’s- and, in the end, the company’s agility.
  • Challenges with assigning full-time team members, the team being dragged apart.
  • Difficulties with creating full-scale cross-functional and cross-component teams.
  • Tasks being thrown at the team by functional managers.
  • Difficulties with locating the whole team at the same location.
  • Dependency on vendors.
  • Hierarchy inside Agile teams, with Tech Leads and Team Leads preventing teams from taking independent decisions and their self-arrangement.

All of the above are examples of “organizational gravitation”. Even when it’s not present, each company is plagued with many other factors that, visible or not, fully contribute to the fact that pilot teams can only implement superficial changes. My experience shows that most pilot projects have very limited success. Often, companies even don’t realize how effective their teams could potentially be.

How to Make Pilot Teams More Successful

In a small start-up, success is largely defined by skills and competency of team members, the level of trust between them, their drive and enthusiasm, and good practices. 

In large companies, however, the culture (that is, behavior and beliefs) depends on other factors, namely the system of dedicated Teams, bureaucracy level, KPI and bonuses system, the number of levels in company hierarchy, etc. Organizational gravitation is so strong that it makes sense to create the right structure for future pilot projects first, and then launch the Scrum Teams. Below I will explain why this approach is more likely to succeed.

The Team’s Effectiveness Is Defined Before It Is Launched

In my work, I saw teams and companies whose pilot projects had tremendous success. There was no need for metrics and KPI to see the difference. For a long time, I thought about the things that make these teams different from the less effective ones. I was happy to read Richard Hackman’s and Ruth Wageman’s works because their research fully supports my personal experience.

“60% of a team’s success is defined BEFORE the team is formally launched.” (Ruth Wageman)

60/30/10 Rule

According to Richard Hackman (Leading Teams) and Ruth Wageman (Senior Leadership Teams), a team’s effectiveness is defined as follows:

  • 60%: the team’s structure (we’ll talk about this later)
  • 30%: the way you launch the team
  • 10%: the quality and level of team coaching

Thus, the team’s design and structure are key to its future success. 

This is why the right way to start is to begin with organizational structure. 

Before launching a Scrum pilot, prepare the necessary structure. Below is my go-to checklist:

less optimal structure :( more optimal structure :)
“Fake” products organized around internal business processes or organizational components The teams are organized around products or services that are purchased by end customers on the market
Team members work in different locations The Team members physically sit in the same room preferably around one large table
Hierarchy inside the teams (Tech Leads, Team Leads) No hierarchy, the only title is Developer
The Scrum Master and the team are in different locations The Scrum Master and the team are in the same location
Component teams Feature Teams
A Fake Product Owner, who has no real power, does not own the budget and cannot make strategic product decisions The Product Owner is the product’s mini-CEO (think Steve Jobs), full ownership of the product
Contract game is in action, with deadlines and commitments; the efficiency is the goal and project management criterias are used Success is measured by delivered value and business criterias are established (ROI, customer satisfaction, employee satisfaction etc.)
Team members have functional managers who can influence their salary, vacation, etc. The Development Team has no functional managers; the teams work directly with the Product Owner and are fully loyal to him/her
Managers start pilot projects and create teams Pilot projects are launched within the volunteer group, and the teams hire their members themselves
The team is unstable The team is stable, its core members stay for at least 1–3 years
Developers are paid based on their main competency level (e.g. Junior/Middle/Senior Java Developer) Developers are paid based on how multidiscipline they become over time (T-shaped professionals)
A part-time Scrum Master, who is often a Developer A full-time Scrum Master working with 1–3 teams
Training is frowned upon, especially during working hours The teams have access to the necessary training and can obtain additional competencies

Case Study: TOP Games Tech

Prior to Scrum implementation, the company had functional structure (see the picture below). There was no direct interaction between business and development, and many coordinating roles in between created the whisper-down-the-lane effect. Key development decisions were made by Tech Leads and Team Leads, who took responsibility away from the teams, leaving them limited chance for self-organization. The teams were built around architectural components and technologies. The company’s owner complained about low development speed and agility, and lack of transparency. The teams, on the other side, could not see the big picture and did not understand where they were.

Before launching Scrum Teams, we made the necessary changes: disbanded the functional silos and invited Product Owners from the marketing department (later, we expanded the definition of the Product, and there was only one Product Owner for all Teams, thus, we moved to LeSS). The developers were free to create their own stable product-oriented Scrum Teams and hire their own Scrum Masters. Each Scrum Team had its own war room. The unnecessary coordinating roles were removed, Tech Leads and Team Leads disappeared. All team members were now called Developers. The company’s owner was directly engaged in the transformation process and approved all the organizational changes beforehand. In just three months, the new product-oriented team demonstrated high performance and agility. After six months, the company successfully brought its product to the highly competitive Asian market. I believe that the key to success was engaging the people, who got back their responsibility and had transformed their workplace themselves. The picture below shows the post-transformation structure.


It’s not easy to launch pilot Scrum Teams because they face organizational gravitation. The chances to succeed can be increased if the structure is transformed prior to starting the actual work. 60% of team effectiveness is defined by organizational structure, 30% with the right start and 10% by coaching. Get the support you need both at the top and at the bottom levels and implement organizational changes before teams actually start working. 

Scrum ON!

More Learning on LeSS at the LeSS London Conference

When it comes to taking a whole-product focus to scale agile with Scrum, LeSS (Large Scale Scrum) shines. As an agile product coach, LeSS resonates with me with regards to it’s focus on product, smart use of the Product Owner, reliance on feature teams for product requirements clarification, guidance on smart backlog management, use of multi-team backlog refinement, and collaborative workshops.

That’s why I’m looking forward to this year’s LeSS Conference in London September 13-14.

The tracks (experiments, experience, games, and snippets of LeSS courses) offer variety, depth, and multi-mode learning. Attendees and speakers hail from a truly global community.

I am intrigued and excited to participate in a “team-based” conference whereby each attendee joins a team that convenes throughout the conference to reflect and share what we learned—culminating in an end of conference sharing experience.

To set up our teams, we’ll participate in a self-designing team session, led by Craig Larman and Greg Hutchings. We’ll experience how large-scale scrum teams self-form to create our conference teams. What better way to learn a practice than to use it to explain it!

And there is more.

In addition to Open Space hosted by Ari Tikka there is a Knowledge Café session (a multi-round deep conversation technique, similar to World Café), offered by David Gurteen. You can experience a session on organizational culture presented by Ben Maynards that goes deep into the question of culture and structure using system models.

I’ll have the opportunity to share a useful technique in my session “Product Backlog Refinement with Structured Conversations”, in which I’ll explain how Structured Conversations in facilitated sessions enables you to efficiently explore, evaluate, and confirm a shared understanding of refined backlog items, so they are ready for implementation. (In addition, I’ll be delivering a pre-conference training, Vision to Value: Backlog Refinement Practitioner – registration is now open!)

There will be multiple game sessions at the LeSS conference, including Build a Feature Team facilitated by Wolfgang Richter, and Build Your Own LeSS facilitated by Terry Yin.

That’s just a sampling of some of the sessions you can attend in London.

This unique conference is sure to be a powerful event for sharing, collaborating, learning, and growing your professional network. Join us—and be sure to follow and tweet using #Less2017.

I hope to meet you there!

LeSS "Construction": What is it like?

This is a cross-post. The original is here.

Join the 2017 LeSS Conference in London to find more discussions like this.

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 ! ;-).

*Signed: ____The Organizational Building Management ! :-) ***