Agile is hot. Many organizations are working agile or implementing it. Despite this, I keep reading blogs that claim that Agile is old-fashioned and that there is a need for a new way of working. I am writing this post to refute this. Agile works and fits our current and future way of working perfectly. There are different agile methods, with Scrum being one of the most widely used. In this blog I will aim at the misconceptions around the agile scrum methodology.
Why would you want to work Agile?
Agile is based on working in complex IT environments. The most important principles are written down in the Agile Manifesto. There are many different frameworks, including SAFe, Kanban, and Scrum that are based on the agile philosophy. Scrum is characterized by working in short sprints, by using reciprocal rituals and having three roles within the Scrum Team. These roles are the Development Team, the Scrum Master, and the Product Owner. Scrum has clear advantages: direct contact and feedback from the end user, small, incremental steps (every 2–4 weeks) that add value to the product, the ability of making quick adjustments in the product due to changes in the environment, and improved efficiency of the team. The Scrum Guide elaborates on this.
It is clear that the agile way of working adds value to every organization (don’t forget the supporting departments!), provided that the organization has an open approach to far-reaching changes relative to the waterfall method. Below, I will refute several arguments against the agile scrum way of working.
“Agile Scrum does not work for big projects with set deadlines.”
As described above, Agile Scrum is most suitable in fast-changing, complex environments. If the environment and the scope of the project are subject to change, Agile helps to add value fast in an iterative and incremental way. By prioritizing the requirements of the project, and when there is a clear focus, value is added to the most important parts of the project and the deadline is met. With the classic waterfall method, every requirement of a detailed plan must be completed. In a complex environment, chances are that not only the priority of requirements changes, but also the content of these requirements! The project deadline is often missed precisely because of this, with all its consequences.
“Agile Scrum creates sham independence.”
An often-heard argument against Agile is that it would only provide a sham independence for the Development Team; the Development Team is allowed to work how they want to, as long as the boss agrees and approves it. This argument is easy to refute. The Product Owner (not the boss or manager!) is the dedicated person to have contact with the stakeholders, to know what is happening in the organization, and with this, to prioritize the requirements. But the way a requirement is delivered – that is the expertise of the Development Team! The Development Team decides the amount that can be delivered and in what way. With this, the Development Team has contact with the client during Sprint Review sessions to receive direct feedback. Other stakeholders outside of the Development Team have nothing to say about their way of working.
“Agile Scrum is not holistic.”
Another often heard argument is the constraint of the multidisciplinary teams with Scrum. Development Teams have between three and nine members, providing short communication lines and an efficient working environment. But if organizations were really agile and holistic, wouldn’t there be team members in the Scrum team that represent HR, sales, and other departments?
This is a clear misconception. Every Scrum Team has its own purpose. This purpose determines the scope of the team and the expertise of each team member within this team should be aligned to this purpose. This way, every team has its own (internal) client for which its adds value. In a completely agile organization, these teams, with each its own purpose and scope, are well adjusted and adapted to each other. This way every team contributes to a common goal of the organization. This is called “Scaling Agile” and organizes multiple Scrum Teams in a way that adds complete value and that is holistic. One of the best known examples of Scaling Agile is the Spotify way.
“Implementation of Agile takes way too long.”
It would take too long to implement the agile way of working (it would take around three to four years), while changes in the environment of the organization happen much faster. At the moment the Agile Team is formed, it would already be abundant. Forming the first Agile Team could indeed take some time, because the majority of organizations are used to their current way of working. Therefore, a lot of organizations are reluctant to change.
Agile coaches help to make the transition to working agile and make sure this process is as efficient as possible. These coaches not only help the Scrum Team with their mindset, behavior, and agile knowledge, but also look to the entire organizational structure of departments and managers. The Agile Coach possesses all the tools to make this transition fast and streamlined.
When an organization is mature in Agile, it is much easier to start new teams and to make changes in current teams. Because of the way Scrum is organized, employees know exactly what the best practices are and what they can expect from the organization. After all, the Scrum framework stays the same and the roles are clearly defined. The lead time for making a new Scrum Team will take less time compared to changes in a traditional organization. In a traditional organization the roles, traditions, and customs must be reinvented by each change.
So, get started!
Agile Scrum is a methodology. When this methodology is implemented correctly, Agile Scrum results in huge advantages in terms of flexibility and quality. By implementing Scrum, the wrong way or by traditional thinking, Scrum Teams are often formed the incorrectly, with the result that they are not able to achieve all the possible advantages Scrum has to offer. For organizations that are getting started with the Agile way of working, I would recommend implementing Scrum in full, despite possible counter arguments and hierarchical changes within the organization. Once Scrum is fully implemented and accepted by the organization, elements can be changed to meet the needs of the organization. This way, the advantages and disadvantages of Scrum, which differ per organization, are insightful and the organization is capable of developing itself further.
If you are interested in knowing more about Agile and how to implement this successfully, please reach out to Rick Jager