Nope, your company is not Agile

When someone starts to work with frameworks as Scrum, usually it is easy to lose the big picture about how the things really work and the company real needs. Many times you are hired by a company that pretends to be fancy, claiming they are Agile, and many people tend to believe this, because they land in “Scrum teams”, and they do the usual ceremonies, you know, the daily stand ups, the retrospective… all the fun pack, and that’s all, right? if we review the progress every two weeks (common sprint) and do a couple of meetings, usually without following up the findings, then, that’s all, we did it, we are Agile, yay!

Let me spoil the fun, I’m checking right now some random job offers looking for Product Owner, and just in the first three offers I find I see sentences like “develop clear roadmap for the team”, “translate the company needs in a clear roadmap”, “manage product roadmap”, roadmap, roadmap, roadmap… This is not a coincidence, companies needs to establish some mid term goals in order to know how to position their products in the near future and design a product offer to show to potential customers, but this is the big dilemma, planning is not Agile. Usually, the “lower” layers of the IT companies, are trying to be as Agile as possible, companies hire Scrum Masters, Agile coaches, Product Owners, but they are doing it because is fancy, is trendy, they don’t really understand how the agility can help them, and if they really need it.

So, we can conclude checking the job offers that we have a lot of people working for super nice modern start ups trying to implement Agile, and we can say that the development teams, probably, are doing their best and are the most Agile layer of the company, but this is the big mistake, the agility should be understood from top to bottom, not the other way around, not just because you hire an Agile coach, all the work is done.

If a company has a tight budget, or deadline, or both, maybe is good to re think if Agile methodologies are the best for your purpose, maybe with tight deadlines and budget is better to sit down, and PLAN, because you cannot allow too much space for interpretations and delays, but plan, as I said, is the opposite of Agile, the Agile manifesto says, “Responding to change VS commiting to a plan”. So this is why I was talking before about roadmaps, reviewing again the job offers I randomly just found, I can see concepts as “Scrum”, “Agile environment”, and even the own job offer for Product Owner itself, a Scrum role, implies the use of an Agile methodology.

So why this contradiction is so usual? Basically because the Agile trends are demonizing the use of the waterfall method, this methodology can be perfectly useful depending on the situation the company faces, and when you are asking me, as a Product Owner to create a roadmap, this sounds to me like “waterfall”, because that implies some estimations in advance, for the next quarter or half a year, etc. etc., then the company have a problem understanding the Agility. This wouldn’t be a big problem if the impact on the daily life of the development/Scrum teams were not big, but it isn’t the case… Let’s put some examples.

I remember one company asking me to have a backlog representing three months work in advance, usually this is around six sprints, but in the reality makes no sense to have more than 2 sprints ahead, because yes, things can change in three months. Anyway, I created it, but we had a lot of time issues creating this roadmap, when you need to plan ahead so many items, you take a lot of time from the development team discussing what could be the effort to implement this or that, and happened two things, first, and most important, this impacted the delivery of the current sprints in a negative way, and second, still we had too many unknowns on some items, so we were unable to estimate all the roadmap. Here a solution could be escalate the problem to your manager and take a different approach, an Agile one, be less ambitious on long term, and stick to the things we know while we clarify the unknowns. If your manager/director has some sense, the issue is quite obvious, so it is fair to continue working with less scope defined, but in this case my manager was not the smartest guy in the room, so he took a great decision, every three months, we stopped the development to generate the roadmap for the next months, ok… super Agile, don’t? If at least we could stick to the plan after this week of planning, I can be ok with it, but if a potential customer called us asking for a feature, probably I would get a call from my manager to change the backlog, on demand for a potential customer… just potential, not even a customer paying our bills, this is a big facepalm… In this situation, a true Agile set up would be great to respond to the changes proposed, but even agreeing that my manager was not the smartest guy, the problem came from the C level, eventually they are the ones asking for the plannings, to review the budget so… can this company afford to be Agile? probably not, or not in a full way.

Agile is very interesting in R&D departments, when is assumed there’s plenty of money and no deadlines, obviously, no results at some point in time, would lead to the closing of the deparment, but here makes sense. It can be very useful to build features on top of an existing product if these features have no tight deadline. Also makes sense if everyone within the company makes a commitment, we have this amount of money, let’s see how far we can go developing this idea, maybe we succeed, maybe not, eventually is an investment, and it can be lost, but… in the real life everyone wants the money back…

Another experience I had as Scrum Master, I was hired for a support team that was using Scrum, basically because was company standard… ok, but was impossible to create proper planning, or estable sprints, when you are attending customers with problems, the problems just happen, is not anything you can easily foresee and plan every two weeks. After several weeks of cruel battle against our own process, we realised that Kanban was the way to go, no matter what the company preferred, we kept some useful practices from Scrum, as doing retrospectives, and that’s all, the team started to perform and optimise the time better.

To wrap up, companies, usually, don’t understand Agile methodologies, but claim to be Agile, they never analyse what they really need, just use it because they read somewhere “waterfall bad, Agile good”, companies need to reflect on the nature of their business, and choose the best method to go, not just do things because is how the hipsters drinking power protein smoothies from silicon valley work.