The short answer is NO, I don’t hate Scrum. However, I do hate the idea of Scrum being sold and considered the holy grail of project management and that implementing Scrum, or any other Agile framework for that matters, will save our projects from failing.
I think there are a lot of misconceptions about Scrum, one of the most important ones is that Scrum is a framework, not a methodology. From Scrum org: “Scrum is a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.” But what does it mean that Scrum is a framework? and how can that affect our desired results when applying it? Let’s take a quick look at the differences between Methodology and Framework:
Oxford dictionary defines methodology as “A system of methods used in a particular area of study or activity” I know, I know, a methodology is a system of methods… huh? but in other words “A methodology is an approach to ‘doing something’ with a defined set of rules, tests activities, deliverables, and processes which typically serves to solve a specific problem.” I’d like to define it as a standardized way of doing things with no much room for improvisation which could be a good thing since it has been tested and proved that it works IF you follow the rules.
A framework, on the other hand, is a set of processes that provide structure and direction on a preferred way to do something. In essence, frameworks provide guidelines, not rules. As an organization, you can adopt a certain framework to conduct your projects and that would give you guidelines but there’s room for flexibility and creativity as opposed to using a methodology.
A methodology will indicate the what, when and how to do things; a framework will tell you what to do and will give you several options for the how and when but it’s up to you to decide on those and here is where the issues start when using Scrum because if you don’t take the right choice of how-to and when-to you are putting your projects at risk.
When working for large organizations, it’s always recommended to use a methodology because if a large organization has a framework only to guide its employees, the employees will inevitably make different choices although they are using the same framework and there will be definitely a lack of consistency. However, if you work in a small or medium organization, using a framework will make more sense, especially on the non-repetitive type of projects where creativity and flexibility are greatly appreciated and even encouraged.
But then, why can’t we just adopt Scrum and be successful? First, we need to understand the following, Scrum is:
- Lightweight
- Simple to understand
- Difficult to master
It is lightweight and simple to understand because it’s very concise and straightforward as opposed to a PMBOK framework, for example, which defines 10 knowledge areas and 47 processes, that’s like a lot isn’t it? Lightweight means that the overhead of the process is kept as small as possible, to maximize the amount of productive time available for getting useful work done.
But if it’s lightweight and simple to understand, then why it’s difficult to master? Well, let’s take a look at the three pillars of Scrum: Transparency, Inspection, and Adaptation; and the five Scrum values: Respect, Focus, Courage, Openness, and Commitment. These pillars and values are non-negotiable, if you don’t have them then you’re not doing Scrum. With that said, it means that if you are planning to implement Scrum, you need to make sure you and your team have these values which imply, most of the time, a change in the company’s culture. First of all, your team needs to know that they’ll be adopting Scrum, they need to be formally trained in the framework to understand every aspect of it. Having a traditional team or a Scrum team is quite different, Scrum team developers don’t “just write code”, they have more responsibilities like estimating, and managing their own work as well integrating their work with the rest of the team to produce an overall solution. They are also expected to work directly with business users to understand the requirements. Scrum requires a high level of maturity, accountability, and trust between all the roles in the Scrum team. Now let me ask you, how realistic is to achieve this level of expertise in your company?
Another important aspect is the role of the Scrum Master, which we all know in the traditional methodologies has a correlative figure, the Project Manager. But these two roles are actually very different, the Scrum Master leads by example and coaches the team to continuously reach higher levels of maturity, accountability, and trust with each other. The Project Manager’s main focus is the project and the health of it if the project is in good shape and on track, his/her work is being done, there’s not much room to be concerned about the team’s health whilst for the Scrum Master, the main focus should be the team, it’s a servant role and it’s expected that he/she coaches and protects the team as well as helps them to achieve the goal. In an ideal world, the Scrum Master shouldn’t be managing the planning or being constantly pushing to accomplish the deliverables because it’s assumed that the team is self-driven, motivated and organized, we all know this doesn’t happen quite often, or at least, not from one day to another.
At the end of the day, there’s no secret recipe, it’s all about practice and taking the right choices, learning from past experiences, there’s nothing wrong with predictive, adaptative or any type of methodologies and frameworks, the problem is when we try to implement something that we’re just not ready to or that it doesn’t fit the needs of the project or the expertise of the team. We need to conduct proper research before jumping into one framework, hire the appropriate resources to provide guidance and don’t fear to fail, even implementing a framework could be considered part of a Scrum project itself, you go through iterations (projects) and then retrospect on what needs to be adjusted for the next one. “Perfection is achieved not when there is nothing more to add, but rather when there is nothing more to take away.”
