Failing (and winning) at planning software projects
simplabs.com
simplabs.com
The longer I program the more I like small, simple apps that can be chained together to do useful things... and be completely re-written at a later time when the full needs of the company are actually understood. What makes that re-writing or re-architecting a lot easier is clear documentation and modeling of the system at a high level, who the actors are, and what the essential/primary, secondary, and tertiary functions are as well as giving a score that reflects how essential each is to the company's core business (eg: a login/auth system would rate very low unless your product or service is a login/auth system -- this is a component that can/should be outsourced so you can focus on what makes money for your company).
Write the app "just good enough to work and make money" but document the business as completely and clearly as possible with the assumption that at some point in the future a team that's new to the company could write a complete replacement of all of your software (which might just happen if you are successful enough to get a massive investment and need to rearchitect for future growth).
This makes me uncomfortable. I don't exactly know why, but the thought that ideas, nice-to-haves, and bugs move to a /dev/null of some sort, does not resonate with me.
What if that bug re-appears after 7 months. You'd want to pull up the old one and go: "see, it still hardly ever happens, but here's another one".
You could rename the backlog to "archive", but that hardly makes it different: a backlog is still a list of stuff you had no time to think about.
* putting effort into preparing proper tickets for all these ideas is likely wasted time as 90% of the ideas will never be taken on * keeping all the ideas together with the issues that are actually important creates noise and makes it harder to identify the actually important stuff; also having a backlog with thousands of open tickets puts loads of emotional pressure on teams since they are always feeling like they lack behind while in reality most of those thousands of tickets are irrelevant anyway.
Also I'm not sure what the point of being able to say
> "see, it still hardly ever happens, but here's another one".
would be really (except for being right about the existence of something) – if the decision is not to fix the bug it's irrelevant still.
At least one fix, however, upset some people who come to like the "incorrect" behavior over those 10-15 years. (In one case, I changed the filename of saved web pages from "index.html" to HTML <title> .html to match Chrome and IE behavior.)
This xkcd comic is relevant: https://xkcd.com/1172/
They discuss how everyone maintains their own personal list of what's important to them and use that to drive their work.
But maintaining a single, centralized list of everything has little value. Anything important is already being tracked in the roadmap, including bugs impacting customers of sufficient priority.
It really is worth reading the ShapeUp book, it provides a good, alternate view of commonly-held beliefs.
a) it's not actually important compared to other things so having someone work on it in a cool down phase is likely not well-spent time
or
b) there is a dysfunctional team/organization in which important stuff doesn't get prioritized correctly (typical example for this being 100% product management driven organizations in which refactorings etc. never get any time assigned)
Well, that's a bit dishonest, this is not really about coordination, this is about risk and money.
This is about helping people who are not working on the project to sleep better.
I believe that setting the budget and deadline from the start and then asking the team to scope the project is a reasonable way to manage risks, but not the other way around.
I believe it's more sinister than that: it's to prevent the people who are working on the project from sleeping at all. Remember, most developers are on a salary, which means minimum 40 hours a week, but a maximum of 168. People who view other humans as expendable "resources" - the amoral types who inevitably rise to prominence in corporate America - then see planning as a strategy to push that number as high as possible. They thus insist that an inherently unpredictable process - software development - must be 100% predictable and, when that inevitably turns out not to be the case (yet again), they demand punitive uncompensated overtime. This isn't an accident.
There is a very this counter-intuitive thing about predicting the future.
We tend to believe that by cutting our predictions in smaller and smaller pieces, our predictions will be closer to reality, or at least more manageable. But there is nothing further from the truth, the best predictions are made when someone experienced in the field is looking at the big picture and try to give a rough estimation.
This has been proven again and again.
At the end od the day, people are working and projects gets finished not because, but in spite of micro-management and other unhelpful practices.
Also the big picture That one could look at in the beginning of a project and base an estimate on is more often than not not what you end up with at the end of the project anyway.
I am perfectly aware of the difficulties of managing projects and keeping clients happy.
From my experience, what you are describing is something few founders are concerned about, because they understand and embrace risk.
On the other hand middle-management is always trying to push their peons to predict the future and accept the liability.
That's bad just middle management then though. It's also why I'm advocating against project managers who would typically/often/sometimes do what you describe here – if you have someone who doesn't actively contribute to the project influence (or dictate in the worst case) timelines, that's deemed to fail from the beginning.
In this post, I present a set of relatively simple techniques to practice that remove a team's frustration and enable better estimates and predictability.