During one of the internal training sessions that I was giving on Scrum – a member from the creative team said that he didn’t care about the values and philosophy: “Just tell me what to do in Jira and how”. That was a huge input for me. For some professionals and clients, Agile remains just a buzzword.
Let’s get it out of the way right from the beginning – we all love Agile. This is the most progressive… way of doing things? Set of frameworks? Practices? Will see below.
First, a bit about Agile itself, and then I will highlight a few aspects that appear after starting to practice Agile in real projects.
Agile as a Core Project Management Philosophy
I like to approach Agile as a philosophy. Because you can’t apply it unless you grasp its concepts, principles and share the values. By the way, I have a clear analogy for you that will help you to get the idea of these principles. Think of Agile Principles as if they were Principles of Law.
Keep calm, you won’t find anything too complicated or boring here. There are many levels of legislation, jurisdiction, starting with the Constitution, which is the supreme founding document. Everyone studied it in school, you might remember those small books with generic phrases about rights and freedoms.
Principles are quite abstract in comparison to a formal set of laws, they rather define borders and consistent patterns that shall be taken into consideration during the decision-making process. For example, the presumption of innocence. You can’t name and consider someone guilty unless it’s proved. It’s the default concept, no matter what, who, or where.
The same thing applies to agile principles when you have to decide on how to proceed within any project or situation. In other words, in the situation when you must make a critical decision and its circumstances don’t match the handbook cases, ceteris paribus, we turn to Agile principles.
E.g. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
So, when we choose between delivering or postponing the release, we remind ourselves about “early”, and, what is even more important, about customer satisfaction – and it gets easier to decide.
As a result, in my opinion, the principles and values, the manifesto overall, point out the key difference of Agile:
You can’t have statists anymore, people that don’t actually understand the methodology and are just told what to do.
In Agile you count more than ever on the team, you give them the authority to make a lot of decisions. You let them do whatever they want if it fits the philosophy. To accomplish that, they must see the whole picture, be fully informed and prepared. And this is the main strength and the main weakness of Agile. Because old-school management is very different, and you have to be able to deal with it.
Entering the Real World of Agile Project Management
If you are sure that your organization is ready to implement Agile practices, you should be able to give concise answers to the following two questions:
Question 1: Can you afford it?
It is a change. It costs. It’s always painful, long, and without guarantees. But change management is not the subject here.
Besides that, you can’t implement Agile just in one team, while the rest will work as they did previously. It’s always about the whole organization. Even the entire environment.
Because when your non-agile boss asks an agile team two of the most common questions in the corporate environment: “What is the project deadline?” and “What is the estimated timeframe?”. You can’t answer. Because you can’t tell him what you don’t know.
You’re probably going to make a hypothesis, together with the team. Try it. Deliver an MVP early, and then see how it goes. And you will let your team be self-managing.
And what next? Your boss will not understand, neither will your client. Changing their mind will lead to many expenses, both time-wise and money-wise. And, probably, you will have to accept losing a couple of team members during this process. Are you ready for this type of investment?
Question 2: Are your people ready? Are you ready?
The part where I made the most mistakes during my Professional Scrum Master certification was about self-organizing teams. To make a long story short, Scrum suggests letting people form and manage teams by themselves.
And when the question was something like “How to proceed with 80 people when there is a need to form teams?”, this is my free interpretation, I didn’t trust them 🙂
Honestly, I don’t think that 80 people can manage themselves and form teams. It works the same way everywhere: initially, some leaders emerge who organize the entire process. They are drivers and get things done. But, you can’t be sure that they will organize everything the way it is required for the delivery. Wait, are they at least aware of the requirements and what needs to be delivered? Just the emerged leaders or all 80 people?
In my opinion, self-management doesn’t have to be understood literally. It matters a lot what kind of people you deal with – their experience, expertise, motivation, values, etc.
There is a well-known quote about the football team: “They don’t need a manager. Such brilliant players can win without a coach.”
It’s true – when you have a bunch of gurus with experience, normally you don’t need to do a thing. Just set up a team and explain the scope, constraints, and dependencies. And let them do their job. But, what if it is not the case?
In the real world, you normally have a heterogeneous team with juniors and seniors. Veterans and rookies. Some of them don’t need explanations, while others require regular one-to-ones, control and assistance with managing their workflow. To make it clear – I think 70-80% of employees are just not ready to manage themselves – they need to gain some experience, or just have the need to be supervised.
Once again, I like the situation when the team is autonomous and self-managing. I just want to say that it works only with high-level professionals, who are willing to understand the framework and the context.
The good news is that when you accomplish understanding the main principles – Scrum Guide has 13 pages, the third of which is “philosophy”- it will allow you and your team to deal with the majority of practical situations.
So, don’t be statists. Be agile.