When talking about Scrum, people often imagine the picture above: framework and its roles, artifacts, and events. Scrum rules are fairly simple, and they are thoroughly described in the Scrum Guide. Obviously, Scrum is attractive because of its potential advantages (value, speed, etc.). At my certified Scrum Trainings, I often meet company executives (even non-IT ones) who have read Jeff Sutherland's famous book The Art of Doing Twice The Work In Half The Time and are eager to implement Scrum and get the promised goodies. It seems that once roles are defined and certification training is over, everything is settled. Unfortunately, this is not quite how things are... or, not even close to how things are, and here's why.
The Hidden Side of Scrum
Actually, the chart above is the least interesting one. There are different ones that, to my mind, more accurately define the nature of Scrum.
Freedom
For me, the main features of Scrum are freedom and creativity, when you can break from the ties of scientific management, which says that each employee is lazy by nature and therefore, performance can be increased only through mandatory standardization of working tools, methods and environment. This is where functional silos come from.
Scrum Team is a self-organized, self-managed unit that, ideally, should be able to make independent decisions on the broadest range of tasks possible. Here are some examples:
-
How to do the work (design, architecture, modeling, planning, tools, etc.);
-
Team setup (the Development Team decides whom to hire or fire together with the Product Owner; the latter allocates budget for the decisions taken);
-
Coordination: cross-functional teams are free to make their own decisions regarding internal and external interaction. The manager's role is no longer needed, because coordinating cross-functional teams is a trivial task that can be done by Developers;
-
In the Scrum paradigm, the Product Owner is regarded as a mini-CEO (think Steve Jobs) who is responsible for ROI, making independent decisions, shaping the product vision, defining the business value model and is responsible for its optimization.
Teamwork
Here's what teamwork means in Scrum:
-
Common success or failure (think how individual KPIs in a company enhance it);
-
No formal hierarchy in the team ("Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule);
-
Active mutual help, thinking outside the "I am a Java developer and my sole task is writing Java code" box. The main task of each Development Team member is helping the team to the fullest so that it could move its "ball" as far as possible (hence the term Scrum);
-
The whole team is responsible for the result (think how much organizational structure and performance appraisal/bonus system support this).
Cross-Functional, Cross-Platform Teams
Most companies are structured vertically or function-wise, when departments and units bring together people that have the same specialization (Marketing, Sales, IT/R&D, Compliance). There is a line manager in each functional silo. Usually, R&D or IT have further silos (Development, Testing, Analysis, Component 1... Component N). This structure is optimized for maximum resource utilization (efficiency), but it doesn't have much in common with the company's business agility (effectiveness), because in order to create value for the external customer, cross-functional and cross-platform interaction of several units is needed. Very often, this results in functional units being disbanded and feature teams being created.
Incremental, Iterative Development
Under the incremental, iterative approach, the final product is born after extensive experimentation and obtaining feedback from end users and stakeholders. "Iterative" means making changes to the output of the previous steps. This automatically leads to changing the game rules, leaving the Fixed Scope-Price-Time contracts behind and switching to direct cooperation between business and development (Customer Collaboration over Contract Negotiation). Does this entail potential organizational changes? Probably so.
Empirical Control
At the end of each Sprint, the team creates the "Done" Potentially Releasable Product Increment. This way, the Product Owner obtains business agility and can decide to ship the product to the market at any point. Moreover, this makes the project transparent: stakeholders understand the current product status and development progress. Often the progress can be unsatisfactory, which is OK. In this case, product development can be stopped early, with the remaining budget forwarded to other initiatives (undoubted success!).
The most important thing is to stop complaining that Scrum highlighted the existing variations to the development process, and resist the urge to come back to the winner-loser game or to fix-price contracts with attributes such as commitment and zero transparency.
Organizational Structure Change Following Scrum Implementation
I would like to share a case of successful Scrum implementation at a middle-size software development company (under 200 employees). Prior to Scrum implementation, its organizational structure was pretty typical, with a lot of functional silos (see picture below) and corresponding drawbacks:
-
Poor interaction between functional silos;
-
Lack of responsibility ("My task is to...");
-
Excessive management + hand-offs;
-
Lack of agility, low development speed;
-
Decreased transparency ("Where are we now?").
And now, behold: this is the company's organizational structure after Scrum implementation (see the picture below):
Here's what has been changed during Scrum implementation:
-
Several functional departments were merged into a single product group.
-
The number of managers decreased.
-
The teams switched from component to cross-functional structure.
-
Business and development were placed in one product group.
The structural changes that took place became possible, first of all, thanks to the uncompromising support of the company's owner, a great deal of patience, support from employees and, of course, sense of humor. Obviously, this transformation story deserves a separate article on its own.
So, what exactly is Scrum?
Scrum is a driver of organizational change that helps companies become more agile and resilient. Correct Scrum implementation leads to inevitable change in organizational structure, its simplification ("flattening") or de-scaling.
If your organizational chart did not change after Scrum had been implemented, it can mean two things.
-
You are absolutely awesome and agile, and your current organizational structure is already Scrum-optimized. Congratulations!
-
Most likely, Scrum has been implemented only halfway, and organizational gravitation won the first battle, so that status quo and power structures remained intact. Keep your eyes on the prize and don't quit!
Scrum ON!