Many companies have implemented scrum. It has become the industry standard for software development. However, many companies struggle to achieve the expected benefits. They will never become truly agile. How come?
Agile and scrum are often mentioned together. By doing scrum you’re supposed to be able to do twice the work in half the time. This allows for faster innovation and the ability to quickly respond to market changes, enabling agility. For the executive team, this is a dream that comes true.
Management orders a scrum pilot. The newly formed scrum teams start enthusiastically and with dedication. Unfortunately they fail to fulfill the high expectations and often the resulting situation is even worse than before. The pilot fails and agile gets the blame. What is overlooked is that by implementing scrum, you will not automatically become agile.
Scrum, but not agile
Just implementing scrum in your software development department is not enough to become truly agile. Many companies ignore the necessary changes in company culture, management style, processes and way of executing projects.
Scrum is a method, agile is a mindset.
Management kills innovation
Changing a company’s culture starts by changing the way management operates. Oftentimes the top-down and command and control style of management perseveres alongside scrum. When something fails, management demands an explanation and looks for the person that can be blamed. Processes are therefore designed to prevent failures by implementing many formal checkpoints. Before you’re allowed to do something you have to deliver detailed documents to the right departments to get a stamp of approval. Because employees are not encouraged to go beyond these boundaries, innovation and agility gets killed.
Projects on top of scrum
Together with the old company culture, plan-driven project management also perseveres. A project only gets approved when management can be convinced that they will get value for money. Delivering on time and within the budget and predefined scope is still expected. In a scrum organisation, this will result in a project manager having to negotiate with the product owners and scrum masters. Scope is often defined as an expected deliverable, instead of achieving a business goal. The mandate for the product owner to decide how a business goal can be achieved is very limited. Pressure will quickly build when the deadline is no longer feasible, for example due to new insights. The team is requested to work throughout nights and weekends to meet the deadline, resulting in shortcuts in quality.
By combining waterfall with scrum, a situation is created that is even less efficient and effective than the old situation.
Only by letting go of old habits and working methods, agility can be achieved.
What does an agile company culture look like? It starts with a basis of trust. Management trusts that the best solutions emerge from having the right people collaborate with each other. People are given the trust and freedom to autonomously explore ideas and solutions, without needing to ask for permission. It’s no problem if something fails. Failure and learning from failure is encouraged, because experimenting and failing are the prerequisites for innovation.
To enable agility, decision making power and responsibility should be implemented at the lowest possible level in an organization, ie. in a scrum team. If people are allowed to do what they think is best for the company, they will take ownership. Management steers only through communicating strategic priorities and (measurable) business goals. Scrum teams are trusted to figure out for themselves how to achieve these goals.
Managers become servant leaders and will only work on tasks that teams cannot solve themselves.
Transforming to agile
A company cannot become agile by just implementing scrum in the IT department. If management expects scrum to solve all their problems, it will become a big disappointment, unless they are prepared to address the preconditions. Transforming to agile is often a big shift that requires a lot of change.
Traditional vs. agile companies: the biggest differences
Rules and policies
Agile: Because of the high level of trust in the people, the amount of rules and policies are limited and not necessary. Only when it comes to business critical things (like security and compliance), rules are created. Most of Airbnb’s policies are based on “gut-checking” if it feels risky.
Traditional: Many rules and policies exist. Centralized departments (like architecture and security) must give permission for your change. An initiative can only start when the Project Start Architecture has been approved, even if it is not a big overhaul.
Agile: Teams can themselves deploy code to production, and stay responsible for incidents and errors. Quoting Amazon’s CTO: you build it you run it. Handovers to other departments are prevented as much as possible.
Traditional: The software will be handed over to the test- and ops departments. After their approval it will be deployed in production. When incidents happen, the operations team will try to analyze and solve them.
Agile: “Managers encourage collaboration to solve problems rather than dictating a solution. Managers help to address impediments that the team cannot solve themselves“ — Spotify’s agile manifesto on servant leadership.
Traditional: Managers dictate solutions and tell people what to do. People often escalate to management instead of trying to solve the problem themselves.
Agile: Managers of engineers always have technical skills and knowledge, because they often have worked as an engineer themselves first. If you apply for a management job at Airbnb, you first have to be a successful code contributor for six months.
Traditional: Managers oftentimes don’t need to have technical knowledge. Maybe because they are managing a process. This results in noise and confusion when they make a decision or try to solve a problem for their engineers.
Agile: In multi-disciplenary teams, roles blend. For example: Spotify does not employ testers, but they do have engineers that teach other teams how to achieve and measure the quality of their work product. Testing becomes a competence instead of a role. From quality assurance to quality assistance.
Traditional: HR dictates fixed roles with defined carreer paths and expectations. If you are a tester, architect, or system administrator, you stick to the tasks associated with your role.
Agile: people have a ‘can-do’ mentality. At the office of InfoScout, a San Francisco startup, G.B. Shaw’s famous quote is prominently printed: People who say it cannot be done should not interrupt those who are doing it.
Traditional: People often complain and emphasize problems instead of thinking about solutions. When faced with a challenge, they look for reasons why something is impossible.
Agile: Only the best talent is hired. Apart from engineering skills, attitude, communication and soft skills are important. Checking for cultural fit and seeing if the new hire is able to take responsibility is an important part of the interview process. This ensures and protects the agile company culture, attracting even more highly skilled talent.
Traditional: High potentials will not stay if they are not continuously challenged and are able to learn from other high potentials. The environment of many traditional companies make it hard to retain them. This results in a downward’s spiral. Quoting Steve Jobs: “A-players hire A-players. But B-players hire C-players.”
Agile: Decisions are often made based on data. Everything is measured and by experimenting with different variations the best solution becomes evident.
Traditional: Decisions are often based on the opinions of managers. At Google, it is encouraged to stay away from dangerous Hi.P.P.Os: Highest Paid Person Opinions.
Agile: The job is done only when the perceived business goal has been achieved. At Google they call this ship and iterate. Get your product in the hands of customers asap. Gather feedback and measure the effect, iterate quickly to discover the best product. Big projects with deadlines are prevented as much as possible.
Traditional: Product development is done by executing big projects with a fixed deadline and scope. Often it is predefined how the work has to be executed and the why (business goal) is forgotten and not even measured after the project starts. The project is dismantled when the first version of the product is in production.
This content was also published on: