Yes, plan, the more planning the better. But set the deadline first, and plan and design around meeting the deadline. Ask yourself, "I have two weeks to deliver this, but if I had to deliver something tomorrow afternoon, what would I do?" -- and do that first.
Why Development Teams Struggle to Deliver on Time, on Budget, or at All
41–50 of 239 posts
Re: Why Development Teams Struggle to Deliver on Time, on Budget, or at All
#42The eternal conversation, apparently.
I agree with making fine-grained plans as a way to uncover issues. Just remember, no plan survives contact with the enemy. On the other hand, fortune favors the prepared. (I actually think those are both Eisenhower quotes, aren't they?)
Re: Why Development Teams Struggle to Deliver on Time, on Budget, or at All
#43The reason that planning software development is bullshit is that you simply cannot know all the little details because in software development you're always doing something you've never done before (because if you did you could just copy-paste your previous work).
To use the 'going to the supermarket for milk' example. I could make a fairly accurate estimate for that because I've gone to the supermarket hundreds of times. I know all the different things that can go wrong and account for them, because I've encountered them before. The elderly person who wants to pay cash and has a bag full of coins. The guy who finds a 10 cent discrepancy on his €92,30 receipt and has to argue for 5 minutes with the cashier (while the row behind him keeps growing). etc. etc.
Now imagine that today is your first time going to a supermarket. In fact, before today you had never heard of the concept of supermarkets, or milk for that matter. How good will your estimate be ?
The only time you can make a decent estimate is after you've finished. Or to put it differently: making an accurate estimate is possible, if you're going to accept that making the estimate is going to take a long time, but I can't tell you how long.
Development time estimation, and every methodology that attempts it (I'm looking at you, Scrum), are little more than desperate attempts by managers to feel in control and relevant.
Re: Why Development Teams Struggle to Deliver on Time, on Budget, or at All
#44Earlier quoted context omitted.
Wholeheartedly agree with #1. I'm fond of saying, "If it takes longer than four hours, you probably haven't broken it down enough. Find the monsters hiding inside your big tasks."
I’ve seen concerns and FUD over getting lost in too many tasks. How do you manage the overhead of 20 4-hour tasks against 2-3 high level tasks?
Well, they're just checkboxes inside the main tasks. You just think through how you're going to perform the task (which you'll anyway have to do when you get close to actually doing it), and note down the sequence of steps. Then you try to estimate each step. Sounds simple, but it works.
Re: Why Development Teams Struggle to Deliver on Time, on Budget, or at All
#45In my experience, deadlines set by higher-ups long removed from (or never having) the technical chops to be determining the deadlines in the first place. VP's and Directors are often the ones dictating the direction, which is great, but then also introducing deadlines, with helpful input from Directors who ALSO haven't touched code in many years. Generally that results in one of two things: * Product delivered on-tim…
In the beginning was the Plan. And then came the Assumptions. And the Assumptions were without form. And darkness was upon the face of the Workers. And they spoke among themselves, saying, "It is a crock of shit, and it stinketh." And the workers went unto their Supervisors and said, "It is a pail of dung, and none may abide the odour thereof." And the Supervisors went unto their Managers, saying, "It is a container…
Did you write this yourself? It's very good.
Re: Why Development Teams Struggle to Deliver on Time, on Budget, or at All
#46Having been through multiple month long planning "phases", that were eventually shown to be wildly inaccurate I disagree.
This is exactly what we used to do in the waterfall days. It didn't work.
The only way that's been compatible with me is to build something really small but valuable. So small that its hard to be disastrously wrong. Once you've released that value, build upon it.
Stakeholders tend be much happier as they at least have something they can use really early on.
Re: Why Development Teams Struggle to Deliver on Time, on Budget, or at All
#47Conway's Law: "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations."
And most organization -- or collections of three or more people -- have dysfunctions. There are rarely process problems where technology is the main problem; it's the wet-ware between the keyboards and the chairs that make or break projects.
Re: Why Development Teams Struggle to Deliver on Time, on Budget, or at All
#48I think neither solution is the correct one.
I find that in the case of the second solution: "thorough planning" you get a bunch of people fabricating estimates of estimates with padding or not padding or trying to estimate a bunch of unforeseen events that are too far ahead to get an accurate handle on. Sure, the second is likely to be much more accurate just because the second is likely to be much, much longer but I have never given one of these estimates without it being followed up by immense disappointment by business with a desire to strong arm me into something shorter. This demonstrates a fundamental issue with the topic. Its not about the estimate at all.
I think the problem with estimates is their finality and assumption of correctness. I figure once you're in the developer-years category you might as well iterate the estimate a bit to get a better sense of it. Error bars should be translated into risk for the business decision.
Too often I see people claim to be making "rational, facts based" decisions on estimates (beyond 1 year+) are complete codshit. This is not rational decision making. These decisions should be about risk management assuming failure as opposed to thinking you can slot year+ development estimates together.
I think very often the desire to lock down development estimates into "rational fact" are business decisions of risk masquerading as technical developer decisions of fact. I have yet to see a situation where we deliver an estimate that blows a business decision out of the water where the business just backs down. It just learns to ask a different question and gets the answer it wants out of that.
Re: Why Development Teams Struggle to Deliver on Time, on Budget, or at All
#49The number one reason is scope creep.
Re: Why Development Teams Struggle to Deliver on Time, on Budget, or at All
#50In my experience talking to hundreds of software engineering managers, running a software project management business, and being involved on software dev teams for 20+ years, there are two reasons why teams don’t ship or ship poor software. 1. Poor engineering planning. The way to do this well is to break down a feature until they’re at about half-day sizes tasks. Identify any obvious risks or ambiguities with the te…
Have you ever been in a situation where communicating and breaking things down takes longer than the actual work? IMHO most disasters I’ve seen occur when ‘Product’ tries to strictly control the ‘Developers’. It just does not work for certain kinds of projects. It also diminishes the developers’ involvment and leads to a culture of mediocrity and CYAs. Also, a person that does not have to do the work will always be w…
This is why agile tries to push the business stakeholders to define -problems- rather than -solutions-. Developers then try and come up with a solution, and pitch it to the business (effectively).
Almost every issue I've had with the business/developer dichotomy (and I use that instead of product because different orgs place product differently) has been due to the business trying to pitch solutions to dev that invariably end up not actually addressing the problem (even simple things like "that's the wrong color" or similar, are because they believe they're responsible for the solution, and they have a very clear idea of what the solution should be, without actually being able to articulate or recognize the problem. Does the color actually matter? If you have a problem that implies it does, yes, if you just came up with a solution on your own and in your head that solution was yellow, no).