8 Mistakes companies do when going agile

Let's face it, 90%, probably 99% of you can relate to the meme above or the one with Will Ferrell saying "By Agile you mean waterfall in sprints". At least I can, in all the contexts where I've been, we were working exactly this way. I call it the Chaotic Waterfall. And here it is, in all its majestic chaos!

Each two weeks there are 4 small teams working on different things in a frantic way. The analysis & design team works on designing something, but developers do not even see that except for the very last second where they will need to shoot some story point estimation. In those two weeks Developers will be developing something else and fix the bugs on something they developed two weeks before. Same paradigm goes for Testers and Deployment team.

There are other variants like trying to design everything upfront and then developing only in sprints, but the concept is still the same, a bastardized hybrid "wagilefall" thingy.

Here is a list of the most common mistakes done by companies when approaching agile.

1. Project or Product?

More often than not the very first step towards becoming an Agile company is the wrong one because Leadership wants to "test" Agile with a Project. This is already fundamentally wrong. In Agile you should think about Products. Projects typically have a start and an end date, project managers and team members will complete the project, go live, transition to an operation team and leave. Products don't "finish", you need to maintain them, evolve them, you would have a product owner who is ultimately responsible for maximizing the output of the Agile team working on that Product.

But why are companies doing this? Possibly the main cause is a mindset still bound to the commitment on scope. "Let's define a final outcome and see if an Agile team can deliver it better".

2. "Follow the money" - fixed scope - power shift

In Agile you don't pay for a specific scope, you pay for a team (with specific skills) for an amount of time (if you don't know the iron triangle take a look here ). This team will be responsible for releasing new features of the product, upgrading the core, fixing bugs, etc... As anticipated above the responsible for maximizing the value generated by the Product is the Product Owner (PO). Value is the keyword. Team capacity is limited, each sprint the PO will need to prioritize the User Stories he believes needs to go first to mitigate risks or maximize value.

The question that comes to my mind is "who pays"? Very often the budget for a "Product" is fragmented, because again comes from legacy. A business function usually pays for the initial build of a project, another will pay for costs of maintenance and infrastructure, maybe IT, and someone else will eventually pay in the future for enhancements, security patches, etc... Usually who pays rightfully wants to decide what will be done with that money, which makes sense in general, but a stakeholder does not necessarily know all the other user stories or the value each of those will generate. Long story short the budget for a product should be one, the PO will then decide what to prioritize.

3. Minimum Viable Product vs Maximum Viable Product

In theory you should try to release Stories to Production at the end of the Sprint, this will allow you to see actual consumer feedback and start gathering data. When the Product still needs to be created, it makes sense to bundle a significant number of Stories before actually releasing the first version of the Product. The "significant amount" should anyway lead to a Minimum Viable Product, let's remember the objective is to be fast in delivering, measure results and evolve.

Fact is everything is part of the MVP and nothing goes to Production until all the user stories are ready.

4. Who cares about data, we have a plan

This is very much linked to the previous point. Businesses typically have a plan and we all like to stick to a good plan. Again, one of the pillars of Agile is actually to change the direction based on facts coming from data, but 1 - if you don't go to production asap with each story you won't have data to look at. 2 - no one ever looks at data. 3 - Even if they do, Rarely businesses change their plans because data was suggesting the plan was not so great after all.

This is also linked to not being able to really prioritize. Some stories might be shifted from one sprint to another, but only because the company will still wait for all of them too be completed before actually releasing anything.

5. Time&Material contracts with no SLA

In a fixed price/scope project the vendor will estimate the cost and add contingency. The Client will add all sorts of SLAs and penalties if a date is not met and so forth.

What about Agile? If the team is outsourced, what penalties or SLAs can you have? What "guarantees"? I've noticed multiple times the contracts are purely time & material basically just paying the hours of the team. There are different ways to go about this though. Let's start with these assumptions:

1. If you pay an external company to do something you would expect to leverage their knowledge/skills/expertise;
2. If the estimate is on a 1 year project it is not absurd if the estimate is off significantly, but if the estimate is on a 2 weeks (sprint) duration, you would expect that is fairly accurate, especially given you are paying an expert.

Here is where you can find the "guarantee", in the quality of the deliverable, and quality can be measured. We need to make a premise here: purists will tell you that you should think in terms of Story Points (SPs) and not man hours or man days (MDs), the debate can be vast and it will require a dedicated article. A Team Member will work roughly 10 days during the Sprint, but out of those 10 days, not all the time will be spent on building new stories, some of the time will be actually spent on fixing bugs that were not found within the sprint. A possible solution to the purely time & material approach is to:

1. Fix the relationship between SPs and MDs, for example 1 SP = 1MD
2. Fix the minimum threshold of time each member needs to spend on developing new things vs bug fixing, for example 75% of their time (7.5 SPs)
3. Pay per SPs delivered

6. Dev and DevOps

I still remember when I talked to a person from AWS explaining to me that for each of their services there is a small team that is responsible for delivering it, but also operating it, meaning if "it goes down" they would still be responsible for restore it. This drives a lot of accountability, it is in the best interest of a Developer to produce good stable code, with proper error handling, etc.. etc..

More often than not there are Operations teams calling themselves DevOps, when the Development team is actually a separate one. The solution here is obvious, no need to explain much, but again it is a power shift.

7. Manual testing and manual deployments

Automate automate automate. If testing and deployment are mainly manually performed then of course it is extremely hard to go to production in a sprint time. Manual testing will take much more time, hence the manual testing portion needs to be reduced to a minimum.

You probably heard of the test automation pyramid introduced by?Mike Cohn . The portion of tests that can remain manual is the E2E/UI testing, everything else should be automated. The same goes for the deployment.

Ultimately CI/CD pipelines are what's typically missing and teams try to add it later on.

8. Let's get Scrum Masters certifications

This is probably my favorite. It seems like this certification is magically going to make the company an agile company whereas 1 - Scrum is one of the many agile frameworks, 2 - in theory the scrum master could not even be part of the team at all once the team is well run in. Also the training is like 16 hours! What can you expect to happen in such a short time?

There are so many impacts, from budget allocation to procurement and finance (it's hard to commit to a business case when the scope will change every 2 weeks), but the focus is scrum master certification. Why? In my opinion it is done because it is easier and quicker. Much quicker than changing the processes around budget allocation, business case approvals, adding CI/CD, etc.. etc...

Personal consideration: I believe the Product Owner is the most critical role, but you never hear about training them.