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.
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.
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.
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)
According to Richard Hackman (Leading Teams) and Ruth Wageman (Senior Leadership Teams), a team’s effectiveness is defined as follows:
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 |
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!
RSS feed