Uncle Bob is a Scrum Master
what’s the use of any tool if you do not understand its purpose?
In a world full of companies eager to tell everyone they only swear by Agile methodologies, Agile coaches by the thousands and walls full of post-it, almost everyone in I.T. seems to have an opinion on Agile. The five letter word is on every lip and it would seem almost like a blasphemy to say that you do not want to use the miraculous methodologies. Scrum, Kanban and so many others, preached out to you as the saviors of your company. If you were to refuse you would be doomed. And still, many of the companies that would proclaim to use Agile methodologies are not so often doing better than others. That promising change is rarely living up to its expectancies.
Why?
This is a question that can be easily answered. Most of those companies are simply not aware of what Agile actually is. Sure, they would use all the tools. Scrum teams, post-it, daily meetings, demos, burn down charts and so on. But what’s the use of any tool if you do not understand its purpose?
You know what Agile is, right?
Being a Software Engineer, I inevitably faced Agile.
I questioned it.
I understood it.
I loved it.
I hated it.
When I first was introduced to Agile, I obviously started by reading the Agile Manifesto (we all did that here, right?). Written by 17 software engineers who cared about Craftsmanship, it came out as a simple, yet very clear and powerful guide.
If you have read the article up to this point, I encourage you to actually read the Agile Manifesto, you know, just in case.
On top of that, I also strongly recommend that you take a look into the Principles behind the Agile Manifesto. Again, just in case.
As a Software Engineer who cares about the products I am building, this Manifesto is absolutely incredible. Short, yet extremely complete. A very simple wonderful thing. Software developers who sat down together to find better ways of delivering quality software to the customers.
So Agile is about empowering the relationship between the developers and the customers, right?
Agile is not what you think it is
I have been in multiple Agile teams (mostly Scrum teams). I have worked as a Developer, a Scrum Master, a Product Owner and even as a Manager.
I have never seen a truly Agile team.
I have seen teams where the Scrum Master is the Tech Lead. I have seen teams where the Product Owner is the manager. I have seen teams where the Scrum Master is the manager. People always try to translate the positions of their previous organization into Agile methodologies’ roles. It seems like no one can erase this question from their mind:
Ok, so who is the manager?
Let me break it down to you: Agile has nothing to do with management. Like Uncle Bob (Robert C. Martin, check the Agile Manifesto and look for his name) said “An Agile team will be Agile no matter how the project is managed.”. A Scrum Master is NOT a project manager. A Product Owner is not either. Agile is not a magical way to manage the developers. Too often I have seen managers deciding what the developers should do. Change the focus on a daily basis and come up to anyone daring to complain with this incredible phrase :
We are Agile aren’t we? We are supposed to be able to respond to change.
Too often, Agile is used as an excuse for complete chaos. Agile has been taken over by companies as new management magical recipes. Agile Coaches became gurus of certification machines and all of the essence of what Agile was intended for has been completely forgotten.
Is Agile dead?
Well, yes and no.
It is dead when we usually talk about Agile on our daily basis. As I said, Agile has been taken over by companies and became a management tool, a business even. Although you can see people everyday trying to push the true values of Agile forward, Agile as movement has lost.
However, the founding Agile principles are not dead at all! Everything in the Agile Manifesto is still true and well alive. If you listen to people like Martin Fowler or Kent Beck everything that led them to create the Agile Manifesto is still a truth and they still firmly believe in all the principles they came up with. Movements like Software Craftsmanship are still pushing those true values forward and defending them.
This is why, in a certain way, Uncle Bob is a Scrum Master. I took him as an example for this article because he represents what it means to be Agile. I could have done that with Martin Fowler, Kent Beck or any of the other 17. They are not a managers. They are people who can instantly improve the efficiency and quality of a team, because they focus on the context and what works best in that context. They provide the team members with the tools they need. If you ask Martin Fowler a question, he would almost always start by “It depends”. This can seem funny at first, but is also very true and shows that he understands that rare are the answers that are always true. People like that are not trying to enforce strict rules and processes, they favor direct interactions and try to find out what works best in a specific context. But most importantly, they understand that software is at the center of everything. Software is what will bring value to the company.
I have had the privilege to be in a team who understood that. It was not about management or processes. It was about quality software. First thing we did was to gather around a manifesto (greatly inspired by Uncle Bob’s work) that we all had to agree upon. The very first statement in that manifesto was “We will not ship shit”. Statements like this affect the mindset of the team. This is in every way much more powerful than saying “Next week, we will switch to Scrum methodology.”. In that team, we understood that Response to change is something tightly coupled to the archtitecture of your software, not to the project management methodology. A working software strongly depends on you testing strategy and the confidence you have in your tests, not on a random code coverage number you found AirBnb has set for itself. Fixing bugs or improving features is about TALKING to the right people, not about post-its and Excel files.
Agile is about better software, not better management.
