Why Your Agile Project Failed
There’s a huge roadblock to effective to Agile transformation that a lot of dev teams skip over that can doom an otherwise effective process. It’s something that speaks to the fundamental reason Agile exists and it’s to solve a problem known since at least the 50s.
Fast, cheap or good and you can only have two out of three. Traditional IT shops or consulting agencies will almost always be bound by a scope and timeline at the outset of the project. If you have these constraints, the thing that has to give is quality and your Agile dreams are doomed before they started.
“Working software” should be taken as a commandment for quality-first development. If your work has bugs or, worse yet, hasn’t been tested thoroughly, then you don’t have working software and you haven’t delivered all the value you intended. If you want to constrain quality, then you need to flex on either time or scope. And that can be a tough sell to whoever is paying your team.
So, what to do about it? First thing is to make sure you are being honest with your customers and that you are empathetic to their needs. Make them understand that what benefits your dev team will result in a better product for them. Trust is the grease to this wheel. If they have confidence that you’ll deliver what you say, they’ll be more willing to give latitude. Having a tight relationship with your product owners can go a long way to building rapport. Of course, the most important step to building that trust is to deliver what you actually say you will.
It’s important for everyone to understand that if you ask for a flexible scope or timeline, this is less about getting a concession from your customers and more about accepting reality. Everyone knows that tech deliveries are always late. Scope changes, priorities change, external forces can blow you off course. Setting a flexible scope or timeline is more about your team accepting what the customer will inevitably need rather than them giving you some charity. Say it upfront that you know you can’t pin a date in the future, so let’s all just agree to stay on track for as long as it takes to deliver value.
“But what about my budget?” you ask. That’s a tricky one, but it can be dealt with. I’ve been on the consulting side where the budget is ironclad in a contract and still kept the team agile. The process is to first build a high-level forecast with rough prioritizations (MoSCoW prioritization works well). Think about your must-have features and forecast (as conservatively as possible) when you can hit that MVP level of scope that will make your project at least avoid failure. Now, keep going and forecast out for some shoulds and coulds. In your contract language, set your budget to cover through the shoulds, but only include guaranteed delivery of the Musts plus whatever is prioritized by business in the remaining allotted budget. That one requires a degree of trust and salesmanship, but is a great way to get some flexibility and mitigate the chance of your project being a disaster.