And there I was, “happy” with my charts, my twenty-thousand indicators, my deadlines, my analysis and design documents, my expected contribution margin, etc… So all of a sudden, the company decides that agile is starting to become quite trendy and we need to put on the agilist medal. The send me and everyone involved in project management to a scrum seminar. Not bad for now.
So there we were in this seminar, that at that time was teached by a scrum certification company. And they start talking about sprints, sprint reviews, stand-ups, sprint plannings and all that stuff. And a concept starts to emerge: ‘my-scrum’:
—”Be careful, if you don’t have a daily stand-up, that’s not scrum: that’s my-scrum”
—”Don’t you dare to modify you current sprint: if you do that’s not scrum, but my-scrum”
—”The sprint deliverable should be show to the client only at the end of the sprint: if not, that’s my-scrum“
Being at this, someone asks:
— “What happens if we do my-scrum?”
And watch the answer:
— “Then the methodology does not work“
We are talking about something that happened about four years ago. After hearing this, with my waterfall mind, it’s clear that this is more of the same: another methodology, but quite trendy.
Now we jump till a few months later. The company, with a classic hierarchical structure tries to take its first steps with scrum, in an environment full of analists, project managers and deadlines. Obviously, it doesn’t work. In one of the projects I’m in charge of, I manage to obtain permission to try scrum in a very small development. Of course with deadlines. And of course, when I try to apply scrum, it does not fit the project reality. But I persevere: in some strange an magical way, if I get to avoid degenerating to my-scrum, the methodology will work. Of course, at the end this scrum test ends being useless and almost ridicule.
Now, with a few years of perspective, I’m aware that quite a big part of this industry has not understand agilism. They think this is just a bunch of methodologies in the classic sense, that you can apply in the same way you applied waterfall methodologies. Take your company, pay for a few certifications for your managers, and long live the agilism! And in the way some certification companies have arised.
Agilism is not a methodology. Agilism is a style for solving problems, based in certain principles. Is to clear up all that is accesory, so you can focus on the essence: use reason, not dogmas. Let see the agile manifesto:
“We value people and interactions between them, over processes and tools“
So to say: if you think that applying a certain methodology you’ll be able to make a bunch of desmotivated, with a bad team culture, not very bright developers, do a high quality product, you’ve got another thing coming. To obtain speed and quality, you need good, happy developers. Period. Forget about magical methods. Processes and tools are for helping good developers to keep their work well organized, all their repetitive task automated, and to be happy. Not for hiding bad professionals, or bad working conditions.
“We value working software, over comprehensive documentation“
Don’t kid yourself: you are making software. Anything that delays or distracts you from making software, is quite possible a waste of time. Keep some documentation, but only as long as it helps you maintain/develop your software in an efficient way. Also, I would add that the more clean your code is and the better is your UX, the lesser your need for documentation is: try to force you to genere very little documentation as a way to encourage yourself to write better code and design a better UX.
“We value customer collaboration, over rigid contract negotiation“
Nobody, except for the logical exceptions result of probability, has achieved a requirement analysis at the start of a project that really describes what the customer wants and needs. Don’t try, it can’t be done. Don’t waste energies trying to avoid change. Instead of that, employ your efforts embracing the change in a way that its impact is the smaller possible. The usual conclusion of this is to show to your customer your progress as frequently as possible. But don’t stays with that: write good software, apply TDD, design patterns, etc. All this help to make a sustancial change in your application less traumatic.
“We value responding to change, over following a fixed plan“
A bit mixed with the previous one. Software development implies uncertainty. From what the customer really wants, till how long will it take you to have the flash of genius to resolve a given bug. You cannot follow a fixed plan, except in general terms. Work in sprints, or don’t, but try that your work flow implied a constant redefinition of where are you going.
So okey, my great personal discovery during my last years, professionally speaking, is that you don’t need anything else but this principles. Forget about methodologies, practices and so on: use them if they help you follow the agile principles. But don’t tie yourself: modify them if you need to. Abandon them at the middle of a project if they don’t fit your needs anymore, and go back to them if they fit your needs again. Try, experiment. Use scrum and disfigure it till it says to you “father, kill me”.
And above all, be aware of the waterfallers of agilism. Of those who tell you that my-scrum will not work. Of those who force you to do a daily stand-up no matter if it makes sense in your project.
Avoid the agile liturgy.