Failing (and winning) at planning software projects
1–10 of 24 posts
Re: Failing (and winning) at planning software projects
#2Planning and estimating projects (or sprints within projects) is associated with a lot of uncertainty and frustration on all sides. At the same time, teams feel they have to adopt processes like Scrum (or their own interpretation of it) and then expect that to fix everything which is usually not the case of course. In reality what I find lacking in most teams is direct communication and close collaboration as well as an appreciation for the valid and reasonable needs and interests of each and every project stakeholder (that's not only engineering and design but also product, marketing, finance maybe etc.).
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.
Re: Failing (and winning) at planning software projects
#3When was the last time the functionality and scope of an application was defined BEFORE it was built (and didn't change before shipping)?
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).
Re: Failing (and winning) at planning software projects
#4> Actively keeping a backlog is most often simply a waste of time. That is not only the case for feature tasks but also for bug reports – a bug that has not been addressed for the past six months is unlikely to be addressed in the coming six months.
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.
Re: Failing (and winning) at planning software projects
#5> Actively keeping a backlog is most often simply a waste of time. That is not only the case for feature tasks but also for bug reports – a bug that has not been addressed for the past six months is unlikely to be addressed in the coming six months. 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. Wh…
Not maintaining a backlog doesn't necessarily mean you cannot collect ideas etc. anywhere. I think the two main points are:
* 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.
Re: Failing (and winning) at planning software projects
#6> Actively keeping a backlog is most often simply a waste of time. That is not only the case for feature tasks but also for bug reports – a bug that has not been addressed for the past six months is unlikely to be addressed in the coming six months. 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. Wh…
Not maintaining a backlog doesn't necessarily mean you cannot collect ideas etc. anywhere. I think the two main points are: * 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…
Re: Failing (and winning) at planning software projects
#7Earlier quoted context omitted.
Not maintaining a backlog doesn't necessarily mean you cannot collect ideas etc. anywhere. I think the two main points are: * 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…
https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...
Sure, you should have bugs documented somewhere but I'm not sure a bug that hasn't been fixed for x months needs to be there since it's a bug the team obviously decided not to care about.
Re: Failing (and winning) at planning software projects
#8Earlier quoted context omitted.
https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...
Sure, you should have bugs documented somewhere but I'm not sure a bug that hasn't been fixed for x months needs to be there since it's a bug the team obviously decided not to care about.
I personally fixed bugs that have been opened for longer then that, so nope, they can get fixed. Plus, it prevents people from opening them again and again and again and again as they all notice the same thing.
Re: Failing (and winning) at planning software projects
#9Earlier quoted context omitted.
Sure, you should have bugs documented somewhere but I'm not sure a bug that hasn't been fixed for x months needs to be there since it's a bug the team obviously decided not to care about.
I personally fixed bugs that have been opened for longer then that, so nope, they can get fixed. Plus, it prevents people from opening them again and again and again and again as they all notice the same thing.
I've fixed a couple Firefox bugs that were filed in Bugzilla 10-15 years ago. :)
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 .html to match Chrome and IE behavior.)
This xkcd comic is relevant: https://xkcd.com/1172/
Re: Failing (and winning) at planning software projects
#10> Actively keeping a backlog is most often simply a waste of time. That is not only the case for feature tasks but also for bug reports – a bug that has not been addressed for the past six months is unlikely to be addressed in the coming six months. 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. Wh…
ShapeUp[1] makes the same argument as TFA. Either it's a bug worth fixing now, or it's not. If it's not, ignore it. In reality, nobody ever goes through the backlog saying "gosh, I have nothing to do, let's find old bugs to fix".