Know the Difference: Why Adopting Scrum Is Not Enough to Become Truly Agile

Screenshot_25

Many organizations have adopted Scrum methodology. It is nowadays standard for software development. However, many companies have difficulties in the agile approach and will never become truly agile. Why?

By practicing Scrum it means that you’re doing agile – i.e. doing twice the work in half of the time. This will allow you faster development and the ability to quickly respond to client’s changes, enabling agility. For the management, this is a very desire-full method.

But not always the outcome is positive. In some situations, the newly formed Scrum teams start enthusiastically and with passion. Sometimes they fail to fulfill the high expectations and often the result situation is even worse than before. The trial project could fail and agile will get the blame. What is often ignored is that by implementing Scrum, you will not automatically become agile.

Why Scrum does not mean agile

Adopting Scrum in your software development team is not sufficient to become truly agile. Some organizations ignore the required changes in overall behavior, management approach, processes and way of executing projects. Scrum is a method, agile is a mindset.

You should first change the organization’s culture by changing the way management deals. In some cases, the top-down and command & control style of management can’t be present together with Scrum. If something goes wrong, management will look for an explanation i.e. for the person that can be blamed. Classical processes are designed to prevent failures by implementing many formal checkpoints. The employees are usually not encouraged to go beyond these procedures, thus, innovation and agility will disappear.

If you combine waterfall with Scrum, there will be a situation that is even less efficient and effective than the classic approach. Only by abandoning the old habits and working methods, agility can be achieved.

Agile behavior

The agile culture in a company should start with a trust building. Management thinks that the best solutions come from putting the right people to collaborate with each other. People should have freedom to individually search for ideas and solutions, without asking for permission. It should not be a problem if something goes wrong. Try and error method should be encouraged, because experimenting and failing are the prerequisites for innovation.

To stay agile, you should transfer responsibility and management at the lower levels in the company – the Scrum team. If team members are allowed to do what they think is best for the company, they will take the lead. Management usually looks for communicating strategic priorities and measurable business goals. Scrum teams should rely on themselves how to achieve these goals.

The organization can’t become agile by just implementing Scrum in the software department. If management wants Scrum to solve all open issues, it will become a big setback unless they are prepared to address the requirements. Switching to agile is often a big step that requires a lot of change.

Traditional vs. agile approach:

Reporting

  • In the Agile approach – teams assign them to deploy code to production, and stay responsible for errors: build it & run it. Giving tasks to other departments is avoided as much as possible.
  • In classic approach – software will be forwarded to the test and operations departments. After their approval software will be deployed in production. When incidents happen, the operations team will try to locate and resolve the issues.

Rules / policies

  • In the Agile approach – since you have built up trust among team members – the number of rules and policies are limited and not necessary. Only for business critical items (like security and compliance), rules will be created.
  • In classic approach – there are many rules and policies. Central departments (like architecture and security) must give permission for all items. Flexibility is only possible when the initial project architecture has been approved, even if it is not a big rebuild.

Management and control

  • In the Agile approach – managers inspire collaboration to solve problems rather than ordering a solution. Managers help to address barriers that the team cannot solve by themselves.
  • In the classic approach – managers enforce solutions and tell the team members what to do. People often ask the management instead of trying to solve the problem themselves.

Product development

  • In the Agile approach – the job is complete only when the desired business item has been produced (ship/ iterate). You should deliver the product in the customer’s hands immediately. Get his feedback and measure the effect, iterate quickly to find the best solution.
  • In the classic approach – product development is done by executing large projects in a fixed deadline and size. In many cases , you define how the work has to be executed and the reason for the business goal is omitted.

Roles

  • In the Agile approach – with multi-disciplinary teams, roles blend. Some companies do 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 and not a role.
  • In classic approach – the organization has fixed roles with defined career paths and expectations. Every specialist (tester, architect, or system administrator), will be stuck with the tasks associated with his/ her role.
Rate this post
Jack Foxford Avatar

About the Author

Jack Foxford

As the Head of Ecosystem, Jack Foxford is inspired to build long-standing relationships with developers and partners to deliver world-class product solutions. Being higly experienced in engaging with developer communities, Jack has a strong working proficiency in defining the overall ecosystem strategy, and works closely with the product organization to ensure that key feature requirements make it onto the development plan.

  • Good points Jack. I’m a firm believer that Agile principles, not just practices/mechanics, are what make a team or company more Agile. Doing the mechanics without understanding why you’re doing them (the principles) may provide short term improvements, but often results in burned out teams and under-performance. Collaboration, transparency, and a reflect & adapt mindset are so much more important than 2-week sprints, user stories and a good looking burn-down chart.