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:
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!