One of the most frustrating software projects I've been on, was when we designed a product that never got built!
A couple different things happened on this project that made it difficult...
First, the project was being sold to use an agile process, but then was suddenly switched to fixed cost at the last minute.
Secondly, there were too many people in management positions.
It created confusion where team members were getting conflicting instructions.
The client was telling each manager different things!
And lastly the client had never designed a software product before.
We tried to warn them to design a simpler product than their entire vision, but they wouldn't listen.
Because they tried to design the product up front, they designed a product that was too complex for a first release.
Though we did what we could to keep the project on track, it ultimately was too expensive for them to build.
I hope this video helps you avoid some of these mistakes on your software projects.
Visit my site to watch the full video (or listen as a podcast):
📺 Watch or 🎧 Listen
🔔 Subscribe for over 100 videos on healthy software development
Top comments (7)
We have a joke about corporate logic:
In canoe racing, you have 6 people rowing and 1 guy giving out the commands. When the team doesn't win, they replace 2 guys who row with 2 guys who give commands to make the canoe faster :D
Lol never heard this - thanks for sharing.
While it's very frustrating to work on something that then doesn't get completed, in some ways it's probably better to fail in planning/documentation stage than have half-built application.
Would be interesting to see what other here consider "minimum viable documentation" to progress with project - being agile by definition means you won't have all the docs and designs, but there surely needs to be something solid in place before coders could start writing actual code.
Yeah I agree. I think a big problem was that when the client got cold feet about agile, they felt the fixed cost design helped them throw “everything but the kitchen sink” into the product.
No agile process seems to help people be more humble about their ideas - it’s more a mindset thing IMHO.
Have to admit the companies I've worked for never fully implemented "proper official" process, it's always been selftought and implemented in patches.
Even with not going the whole way it's made massive improvements to dev side, however you can imagine my face when I relatively recently discovered management/client/stakeholders need to be actively part of agile process as well.
mind blown
Do you think in general it's more about people not happy anyone "mess" with their ideas than lets say any proven/measurable financial benefits?
Absolutely. This is why I tell people the resistance to being an agile team (and not just another team that uses agile processes like scrum but doesn’t change direction) usually comes from people not wanting to be humble enough to admit there are other sources of good ideas than themselves.
I do wonder if non-techies could be scared of being "more involved" in development, or they might not care, because just implementing dev-specific processes improved raw code efficiency and they get what they want out of it - therefore, why change it?
On project level, would you still need some sort of set mission statements that don't change?
Or is it better to not enforce any and go "with the flow" so to speak?
I mean, it's kind of unlikely that you start with building CMS system and end up with open world PS4 game, so it might waste of time to even worry about it.
On other hand I could see how it could end up exactly like you described in your story, where it seems company lost the concentration and went crazy with including features.