Why your Agile project is behind schedule and over budget
Since the beginning of project management, people have been responsible for trying to figure out how to hit deadlines and budgets. The collective knowledge of these people created waterfall approach, but it didn’t seem to work. Then we had the Agile manifesto that was supposed to fix it, but most Agile projects still arrive after deadline and over budget. At SwingDev, we’ve been trying to understand why this happens in so many software projects.
Not communicating timelines and costs clearly enough
This is the biggest problem with an agile approach when collaborating with a client. Imagine full agile / SCRUM without working out a detailed plan ahead of time. Your solution to all problems will always be adding more iteration cycles (sprints). A lot of defects found in the software? Let’s fix them during the next iteration. Requirements changed? Was a feature misunderstood and developed wrong? Let’s fix it in the next sprint. Huge technical debt got accumulated? We didn’t tackle the hardest parts first or accommodated big changes late in development? Let’s do a refactoring sprint. There is always a good reason to do one more sprint and then another. This lets timelines and costs spiral out of control in an unpredictable way. Agile doesn’t propose any solution to say how many more sprints are left until we are done and when we can stop paying and waiting. Of course, if you follow Scrum religiously and every sprint ends up with a release-ready version, you should be able to stop at any given point. However, with clients, it’s understandable when they are not satisfied with an “almost done” version. They want the software they are paying for done in the best possible way. The fact that a version is “releasable” doesn’t say much and doesn’t solve any problems — it still might be missing some crucial features. Moreover, the “always shippable version” is a myth. It’s enough to say that the version just before the bug squashing sprint is probably not good enough to be seen by the general public.
I’m not trying to say that other management techniques are solving problems connected with bugs in software or with misunderstood or changing requirements. The problem I have with “agile” is not communicating very clear consequences of those unpleasant events, and they happen in every project. Adding more stories to a backlog and estimating them with some kind of arbitrary story points is not enough. Looking at a backlog is, for a business stakeholder, just one of a myriad of stressful activities they have to take on every day (a.k. a. startup founder life). Neither story point estimates, or backlog position of a ticket say “when” something will be done or “how much it will cost”. You have to compute both of those metrics based on which sprint the story/ticket will end up in. There is no scientific method to perform this “computation.” Even experienced scrum masters might have a problem answering this question. Mainly because the number of story points completed each sprint is not constant, but based on team’s velocity. Velocity is another agile component that is very problematic for me.
Velocity is a vanity metric
As I mentioned already, if you follow Agile to the dot, for every client question of how long until we are done, you will reply “it depends on the team’s velocity”. If you happen to be one of those unlucky clients who gets a little anxious after a project starts, you will have to wait 4–6 weeks to see this number. The dev team will average their velocity from the last 3 sprints, and they need data points to get a statistically meaningful result. Also, velocity measured in story points is a metric that is extremely prone to inflation and losing its original value. It can’t be connected to anything objectively measurable, so the team is naturally incentivized to inflate story points per task. This way they assure that velocity seems to be rising with every sprint. It looks good to deliver a lot of points, but does it always mean delivering a lot of business value? Preventing point inflation is possible. Proper leadership that appeals to the team’s intrinsic motivations and their honesty can take you a long way. At the same time, managing software teams is challenging enough without creating more problems to solve.
Mitigating big risks later than sooner
The same drive for achieving high velocity and delivering planned stories within a sprint will result in the team favouring easier tasks over bigger ones. The team will always pick up the best described and scoped out (and most accurately estimated) items from the backlog. This strategy is generally good, as it minimizes the risk of doing things wrong, but at the same time makes the chance of doing wrong things very high.
Even from the product owner’s or client’s perspective, it will always be easier to specify less complicated parts of the system. It’s natural to avoid making tough decisions that are affecting a big chunk of a system. Those are often connected with hard things like business models or go-to-market strategy. It’s convenient to convince yourself, and the rest of your product/business team, that we still have time to figure things out and that you are actually not under any pressure. Because why would you be? The dev team is busy working on some other parts of the software that don’t depend on those hard decisions. The problem is that they probably do depend on those decisions, but most of the time it’s impossible to judge if they do or don’t before we know the outcome of this important work. Even we mess up or wait too long, it shouldn’t be problem, right? Agile prides itself that it’s designed around accommodating change.
Not differentiating big and small changes
This kind of promise reinforces the wishful thinking of the product owner. It gives another excuse to delay important decisions or not really think them through. It’s easier to assume that “we can always change it later”. The problem is that Agile doesn’t differentiate between big and small changes. Both of them are happily accommodated, but big changes can result in a need to rewrite a majority of the code. Usually, this means abandoning the schedule and budget completely, so no one in their right mind would agree to that. Unfortunately, this situation leaves no other option to the dev team except to do things quickly and cut corners. It results in amassing technical debt or introducing additional bugs. This is a straight path to both the team’s and product owner’s frustration. It’s later addressed usually by introducing more iterations, which was already described.
Outside business environment is not Agile
Resolving all those issues we are discussing here is usually the job of one person — let it be called the project manager or scrum master. The main challenge this person is facing is being a boundary between the agile team and the outside world, which is usually completely not agile. Even if the agreement between the team and the client is structured in a way to facilitate an agile approach, it’s usually just moving this boundary one step further. You will very quickly learn about all those external factors that will make fast-tracking necessary. A marketing plan is usually not agile. Investors are not agile. Wall Street is not agile. Business plans are mostly not agile. At some level, there is always a deadline and a budget, no matter how hard we are trying to convince ourselves that there isn’t. This is fundamentally the big unsolved problem of “how to scale agile” that you hear people talking about. Especially with external product owners it’s becoming more and more stressful, particularly if you want to maintain a high standard of customer service. I don’t envy a scrum master who needs to convince his product owner that some very important features cannot be delivered within reasonable timeframes because the change is too big at this stage of the project. I also feel for the poor pal who needs to convince his team that changing the sprint scope and adding this 50 points item is a must because of some scheduled marketing campaign.
It’s obvious to say that every project management framework has known issues. Agile approach (and it’s Scrum implementation) is no different. It’s much more challenging to propose a solution that could improve the current state. Many Agile practitioners are arguing that issues will go away if you follow the rules religiously. I don’t think that doing “more Agile” will improve the state of given project. We use common sense to create our own hybrids of Agile and long-term planning that will balance all the tradeoffs in the optimal way.
We ended up with an approach where we spend significant amount of time in the beginning to create a detailed plan for future work. The project blueprint is shared with the client in the form of a report. Senior Developer, UI/UX Designer, and very seasoned Project Manager all contribute to its contents. It’s thoroughly discussed and all decisions are meticulously documented. It guides the whole team, including the Product Owner during the stormy times that will come eventually. Of course, it’s not a bulletproof solution and entire product team is working hard on improving our method. There are also fascinating developments made by Tom & Kai Glib in their “Value First” approach. We are analyzing their findings and we won’t hesitate to share lessons learned here.
