Scrum is not Agile

I never took for serious all those methodologies, “scrum ceremonies” and stuff alike, and assumed all others who know how to do their work have roughly the same attitude. But to my surprise almost at all interviews I’ve got some question like “do you work scrum and agile”. So I took a breath and tried to lay out my thoughts. (Spoiler: I’m going to introduce a methodology of my own).

First, scrum is not agile. When I looked back on how I work, I realized that I work agile without claiming that so much. That is, I do what is needed to get the project delivered in the most efficient and straightforward way. If I need to talk to someone - I do immediately, if I see  a need for collective decision, I initiate a meeting, if there may start frustration on the client side I write docs targeted at specific people etc. This is exactly what is meant by Agile Manifesto.

But, once someone says “we have these and these formal procedures, these and these roles which should be strictly followed” he puts processes and tools over individuals and interactions (1st Agile Manifesto statement)

The important thing to understand that every methodology is a model, or a tool. It helps you formalize some action when you understand it is needed. Eg, when the team is big enough, tasks are diverse and of several man/hours size - you probably need to touch base with your team daily, and the formal way of daily standup comes in handy. But just this way - understanding first, tool and process second. This daily standup is not the best and not the only method for communication both within the team and with the client. I won’t go into examples of abuse, they are many. So, the first statement I make: “understanding first, methodologies and tools second”.

The same stands for scrum definitions of a team and roles within a team. If you are agile, that is, driven by your knowledge and experience and focused on project delivery, you will be taking the responsibilities needed at the moment and agreed with others, and that may look sometimes as a scrum master, sometimes as a developer, sometimes as a product owner. One of the twelve agile principles reads: “The best architectures, requirements, and designs emerge from self-organizing teams.” Which should mean the following: people in the team know each other for certain time, they came to know each other individually, driven by common perception of the world and common goals, they speak common language (I don’t mean English or Spanish) and they can distribute responsibility between themselves depending on challenges they face and their personal inclinations. That has nothing to do with a group of people randomly picked up by a recruiter based on some buzzword on a one-page paper and, optionally, some random numbers called “years of experience”.

The same stands for sprints: be it agile or not, to deliver the final product in time you have to pass a number of milestones in time, and this is nothing more than detailed and thorough planning. Once you get off the track, the action is required, and the sooner the deviation from expected are recorded and taken care of, the better. Ideology of sprints for the sake of sprints may distract attention from the delivery of the final product. Sprints go on, we finish successfully each consequent one and plan a bunch of others, but we are mysteriously not getting closer to the final delivery. 

So you may ask, “why Scrum is so successful?” In my opinion, it is not. I would not take stories told by coaches, evangelists and other people not involved in manual work at face value. To my experience, behind any working project there are just people (one or many) who know their trade and work hard. Another case is a failure disguised as success.

So you may ask, “why Scrum is so widely adopted then?” Because it justifies software development for the sake of software development, without ever delivering a result having substantial value. Frank Zappa once said (no matter on which purpose) “people who can't write, interviewing people who can't talk, for people who can't read”. This is reminding me of many things around, and of the current state of development as well. In the age of waterfall, building software meant that you are building something intended to run for decades and  be 100% reliable and predictable for its users. Nowadays, lots of projects die even before being delivered - everyone on the business side wants either a startup or a digital transformation for its own sake, without careful planning and without having a deep understanding of  the business domain, the same about people on the dev side - not having enough training and education with large-scale technological project - both on technological and managerial side. Then they look for salvation in following some rigid procedures. (TBC)