Agile Metodologies and the exoterism behind the numbers

Scrum, XP, Safe are frameworks to manage and control the process of software development. These frameworks are self considered agile frameworks, but why are they agile?

Agile and waterfall

Before the era of agile methodology, software management used to be waterfall, with a planning phase, execution, testing to at the end release the whole project. The problem with this approach is the time to release a new product. Software took too long to be released an when released, market sometimes had changed and the time wasted to planning, develop, test and release goes to nothing.

People in waterfall are high specialized, with specific functions, as the mechanist factory way of work. People are gears of a big machine (company), each one specialized in one area.

Rises agile manifesto! Focused on people, delivering value faster, interactions over process. But the manifesto isn’t about how to do things, it’s about a philosophy of what to prioritize.

Agile frameworks

The manifesto was getting strong and the hype of agile managament was increasing fast. Then, a framework called scrum appears and became the alias of the agile principles. People started to heavily use it, thinking they were agile because they have SCRUM.

For many years I belivied in that too. Scrum was the agile, the way you use to reach it. So, one day I realized that scrum wasn’t the agile. Scrum is a tool to become agile. And being a tool means: it can be use for good or for evil. And that’s the problem. People were using scrum to mascarade their waterfall workflow.

Scrum and frameworks are tools, not philosophies

In company’s I’ve already worked all areas were implementing scrum, kanban or safe, each one in your way like the frameworks say: “We are just a guide and you can modify whatever you want”. And the charts were appearing, metrics, points, weights and meetings everywhere to try to predict future and the product!? Always on the paper.

Scrum-masters were more concerned on how to collect more metrics, how assertive were their planning. How many groomings in a week to plan more about the next sprint. And the product again? None.

In my opinion, they were spending time of an entire team to predict the unpredictable. There are so many unmapped and unconsidered variables that your metric reflects to nothing. Metric is the way waterfall calculates time spent in a project, and this is still doing.

When I go to an agile event and watch all scrum masters exhibiting their boards and metrics saying how I putted post-its on the wall etc and no one saying how much is the value they were delivering this is so sad.

The exoterism

In my opinion, metrics is more a belief than a reality. The scenario and variables are too many to be computed into a graph.

Software development must be seen as an art. We are not constructing buildings which has their norms and a predefined way to do things. We build software and each part of it, is a creation from it’s maker mind. We create things not build them following an especification.

I’d like to compare us with a writer. A writer can’t predict when his book will be finished, they just know he will finish it. Editor pays the writer only when the book is delivered. Somedays the writer will be inspired and can write 50 pages of his book, other days he won’t and will deliver 1 or 2 pages.

To a software developer the same can be applied. We are humans not gears and we are creating a story of our software. So, should we get paid when software is done? Uhmmm … maybe. But when the software is done? I think we must get paid when a feature is shipped to production.

Nowadays

I am facing some important starting to question this behavior. At the last Agile trends Brazil people introduced the topic: we have a high specialized IT department until the company is still working on the old way.

This is why I think we are wasting time trying to justify the numbers, budget and over planning things.

Company’s should evolve to team ROI mindset. This team costs how much? How much value it brings? This should drive every product team.

Yes, a team should know how much it costs and must understand the value it should brings. Today teams are over protected, they can’t product decisions. They are engines.

About my actual situation

Today I work on a self-management team. Our startup is living inside a big company and we ships code everyday to production. We don’t have an agile framework, we don’t have metrics and we don’t have a project manager. We are free artists with a business conscious mind. Free to decide when is the time to make a refactoring, how this and that will affect the product and system.

We don’t need a framework or a process to say what we have to do because we all know what to do. Deliver features and actions to increase revenue. And people forget that there are two ways to increase it. Increasing the incomings and reducing maintenance. Unfortunately teams don’t see the second one as a choice and it will never receive the importance it should.

So, don’t spend time measuring anything. Spend time getting things done and how can the team be more productive and autonomous to decide between maintenance and business feature.

Don’t let your creation (die) by pression. Things will be done in the time it should be done. If the requester isn’t happy you must remember that you can argue and have a discussion. And if you can’t argue to find a good solution for both sides reclaim for a time to spend fixing the things to do it right after delivering the feature. Remember, a software is like a company’s son and it’s the developer responsibility to educate him and give him the possibility and the bases to have a healthy growth. If you hit him and never go back to fix that he will grow and in the future he probably will become a problem. A problem that you could avoid.

The only problem here that brings some lazy days is that we don’t have to care about money yet. When you have this need, all of our days become even more productivity and focused.