If you worked in large organizations you have probably heard about the term “dependencies”. I am convinced that dependencies need to be eliminated, not managed. With a help of system diagrams in this article, I will uncover the main reasons why Scrum Teams suffer from dependencies, how they impact organizational agility, and what the fundamental solutions to this issue are.

How dependences inhibit Teams progress

The more dependencies, the less chances the feature will be done by the end of the Sprint. Thus, the more time it takes for the feature on average to go from Product Backlog queue to the market (cycle time). As a result, agility is reduced because the organization is unable to deliver potential value to the market quickly. This causes organizational stress.

A typical management response to organizational stress is “divide and conquer”. For instance, if there is a problem with the quality, let’s create a separate department “quality control” with set of its own KPIs. Creating new functions, units, component teams and coordination roles, managers strengthen the fragmentation of the organization. More fragmentation leads to even more dependencies.

High average cycle time makes the organization less agile. But Scrum Teams should not have any dependencies!

Cross-functional teams have all competencies needed to accomplish work independently from ones not part of the team. The team model in Scrum is designed to optimize flexibility, creativity, and productivity. – Scrum Guide 2017

Why do dependencies exist

Basing on my long experience working with large organizations I see some reasons why the dependencies thrive:

• Imperfect organizational design based on component teams ( “bus team”, “analytics team”, “Android Team”, “integration team”). It causes intensive fragmentation.
• Incomplete cross-functionality (lack of one or more skills).
• Unreasonably complicated architectural design ( “there are 256 systems in our organization)”, which inhibits creation of cross-component and cross-functional Scrum Teams.

How to get rid of dependences

The dependencies issue could be solved in two ways: with quick fixes or fundamental long-term solutions.

The quick fix is to visualize and manage the dependencies. E.g. creating additional coordination roles or using specific techniques (“ropes on the boards”). Yes, it somehow helps to survive and continue the movement. You become an artist of the visualization and dependency management. Your work looks like this:

The fundamental solution is to completely eliminate the root of the problem by:

• training people
• making the complicated architecture simpler, reducing the number of components
• changing organizational design and forming cross-component cross-functional Scrum Teams (Feature Teams)

In this case the board for the scaled Scrum could look much better (no dependencies):

Feature Teams do not need the strings because there are no dependencies or they are trivial.

Let’s get back to the system diagramming. On one hand, we have a cycle explaining the rise of dependencies, on the other hand it is a quick fix of the problem, then a fundamental solution cycle and the final cycle of forming a culture of managing dependencies when time passes.

The bad news is that a strong culture of “managing dependencies” will hinder the implementation of the fundamental solutions.

Ideas:

• The more dependencies the less agile organization becomes.
• Dependencies thrive because of the unnecessarily complex architecture, lack of skills, and suboptimal organizational design (component teams).
• Creating additional roles and using dependencies management practices do not eliminate the fundamental issues.
• Fundamental solutions are simplification of the architecture, Feature Teams and training people.

Do you manage dependences or want to eliminate them?

Scrum ON!

Open Space

In one of the previous blog posts I explained the team-based conference and in another post the Conference Review Bazaar. During the conference we had an Open Space running in parallel with the conference and the Open Space information is collected in this post.

What is an Open Space?

Open Space is a large-group facilitation technique based on self-organization (there is more to it, but for now this description will do). It roughly consists of the “opening of the space” where anyone in the group can propose topics that they would like to talk more about. They post their topic in a timeslot and location so that people who would like to come know where to go. After the opening of the space, everyone can join any session they like… or do something else.

In a LeSS adoption, having a regular Open Space event is common for creating a forum for team members to raise topics for discussion and organize around them. I usually recommend to do it bi-weekly and fairly informal, combine it with a coffee and cake session.

Open Space is a common technique to use in conferences too. Some conferences are only Open Space where the participants of the conference create the conference. Alternatively, some conferences have a separate Open Space track where people can post additional sessions next to the planned ones. That is what we did in the LeSS conference.

So, how did it go?

In my opinion, we didn’t do that well. The opening of the space didn’t go smooth as there was a separation from the conference space and the Open Space space. The Open Space explanation was short and could have had some references to how to use it in LeSS. There were few reminders about the Open Space, and we feel that the Open Space was not utilized as much as it could have been. In addition to that, some people feel the LeSS Conference should be an Open Space conference. I’m myself not sure, but it is an interesting thought to combine it with a team-based conference.

All that said, the Open Space track did happen and it did deliver value to the participants. I joined a few Open Space sessions myself and enjoyed them.

Sessions

As with the team creation and the Conference Review Bazaar, we didn’t collect all the photos yet (we were horrible at documenting the conference). This post will be the collection of Open Space sessions that we know of. If you were in an Open Space session and like to summarize it a bit more or have some photos, please let me know, and I’ll add them to this post.

LeSS for Hardware

System Optimization Goal of LeSS

Product Definition in Retail Banking

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.

Teams

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

The LeSS song from the Black Ops Team #less2017 @less_works @jippit pic.twitter.com/MRDsXqV9ry

— Wolfgang Richter (@woof0815) September 14, 2017

The Super 8

NameLess

Lesson Learnt

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

A 1m30 team self-design workshop at #less2017 pic.twitter.com/bV5JtE3Fln

— Jurgen De Smet (@JurgenLACoach) September 13, 2017

CareLeSS

Black Ops

ClueLess

FearLess

Game Changers

N-LON

Lesson Learnt

NameLess

Something Catchy

Divercity

Turtle

The Flying Horses

The Super 8

Unknown team

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.

Conclusion

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!