Scrum is the most broadly used agile framework nowadays. My observations confirm that. Whenever there is a question at meetups or conferences about the method the audience uses, Scrum collects the most risen hands. During job interviews I have a chance to learn the same. But what I also notice is that people sometimes don’t really understand the why or how. They just follow some ceremonies, that are often flawed, without any deeper understanding. Actually, I am guilty of doing the same. So here I share a list of things that people confuse, consciously or not, and provide some explanation.
Scrum is not a Silver Bullet
I used to play in some metal bands in the past. I stopped, for numerous reasons, but later wanted to get back to playing. I was a Scrum practitioner, Scrum was working for me (or to be more specific – it was better than waterfall, which I had experienced before), so I wanted to apply it to band forming. It was really funny. Band mates were confused to say the least! And you know what? It didn’t work. Surprise, surprise.
You may laugh (I can hear that!), but I learned that you have to be pragmatic with such choices. You need to learn other approaches and be open to new ideas. Mastering only one is dangerous, because if all you have is a hammer, everything looks like a nail.
Some teams and companies use Scrum because of its popularity and accessibility. It’s easier to read 16 pages of Scrum Guide than books about Lean, Kanban or others. Besides, it’s effortless to get certified Scrum Masters (or to get certification yourself), to be trained by certified Scrum trainers and so on. It’s safe and seems to be easy.
Yet sometimes (or maybe – in most cases) Scrum is not the right choice, and definitely not the only viable possibility. In order to choose well you need to learn what other solutions are available, get the best parts from them, and use them wisely. And not be afraid to modify your process.
Scrum is not a Religion
Recently I attended an agile community meetup and there was a really awkward moment for me. I was listening to the speaker and suddenly he asked the audience about the Agile Manifesto. People started to recite the whole content in unison, like a prayer in a church.
It was not the first time I have faced a religious approach to agile. I was also guilty of acting like a Scrum priest at times. I was questioning how scrummy this or that practice is, and whether we are doing Scrum or “Scrumbut”. Hey, I was a Scrum Master after all! This produced funny situations, for instance when priorities changed, we wouldn’t adjust the sprint backlog, because this is forbidden in Scrum. Stakeholders were really happy with that…
The bad news is that nobody pays you for using pure Scrum (unless you’re a Scrum trainer). Companies pay for doing a great job. So instead preaching about the sacredness and greatness of Scrum, think about what may work for you and your team. Don’t be a zealot.
Scrum is not only a Set of Practices
Really, doing standups will not make your business tick. Nor planning sessions, backlogs or product owners. They may help, but that’s not the whole story. Implementing practices without building the right culture and living agile values is destined to fail, or at least to not make a real impact. And that’s the hard part, because changing how people think is not an easy task.
Scrum is a product that supports agile values and principles, it has its own principles as well. Those principles and values are something you should be looking at and striving to embed in your environment, rather than obsessing over Planning Poker cards. Practices are just practices.
Scrum is not a Process or Methodology
Yes, I know this may be considered a religious dispute, but my point here is not about names, but rather the understanding about what is and what is not a part of a Scrum framework.
Maybe I was unlucky, but whenever I was taught Scrum, there have also been User Stories, Planning Poker and other practices that are not actually part of the framework. At the time I was too green to distinguish what really was a part of Scrum and what wasn’t.
If this picture is taught to fresh adopters of Scrum it may also mislead them. Because they were told to implement Scrum as a whole, otherwise there’s no guarantee of success, they’re afraid to change User Stories to something else. Story points, tasks, Planning Poker and release planning are NOT a part of Scrum. There are a bunch of other practices to use instead if you need them. Do you?
The message I want to send is that you should not blindly use any framework, methodology or process without really understanding your problem and what other options you have to solve it. Use each new or trendy idea as an inspiration rather than a prescribed solution for your problem, because the chances are very high that it wasn’t developed to help you with your challenges.
Do you agree with all of this? Would you add something to the list?
I’ve been programming since ’75. I was lucky, I started out in an “Agile” environment, and have mostly only worked in agile environments in my 40yr career. Some of you will be foaming at the mouth, and Googling the publishing dates of manifestos, and such like. But it was around 40 years ago. Your manifestoes, Scrum, Lean, etc are just attempts a putting in to rules what we have always been doing without them.
“If you cannot do a project with 7 good guys and lots of overtime, you need over 50 and 5 times as long. There is nothing in between.” James R. Westrick circa ’75.
If you think about it, its all about communication. 7 good guys in a single room can identify, analyse, architect a solution to a problem, and get back to work in 15min. The same process with SCRUM will take 48hrs and several weeks worth of meetings and documentation changes in a 50 man shop.
So understandably you can imagine my smirk at this and similar posts. The Agile Manifesto SHOULD be, “The minimum COMMUNICATION it takes to get the job done”. And the Job is getting code out, how every you define code.
Dave Kidwell is the best project manager I have ever had the privilege to work with. He used excel, and managed the team ad hoc. Doing the work usually done in “stand-ups” by sitting in same room as the programmers, and inferring the changes from the programmer-analysts working discussions. Anything he did not understand or did not know how to change in his plan, he would ask at the end of the discussion. No stand-ups needed, minimum interference with the workings of the Coders. Within a week of his starting with us, we where relying on him to keep track of decisions, schedules, and other “secretarial work” that he tackled with glee. Yep, at least 50% of Project Management is secretarial level work, I know I’ve had to do enough of it… Dave organised the development into 4 releases a year, and coordinated the changing work / backlog between us and our stakeholders. Deadlines where never in discussion. The process was just right for the Bank and Application we developed. (1997-2001)
No Scrum is not meant to be religion, it is just a collection of tools that worked for several projects of a specific size and complexity that someone formalised. They are meant to help you keep on top of what is going on.
But in no way can they replace FULL UNDERSTANDING OF THE PROJECT BY EVERYONE INVOLVED.