And then you make a good plan with buffers and it fails too.
Cause you forgot so many things that cost time: you'll catch a cold, the warm weather distracts, ignored the existance of family & friends, computer breaks down, ...
Why Development Teams Struggle to Deliver on Time, on Budget, or at All
71–80 of 239 posts
Re: Why Development Teams Struggle to Deliver on Time, on Budget, or at All
#72In 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…
How do you estimate how much time a task will take, especially when it's a novel idea, at least for your developers?
Invest time in determining the right approach and planning it out.
Most of that will be doing spikes: http://agiledictionary.com/209/spike/
It's one the most underappreciated agile concepts. I wish people would shut up about standups once in a while and give more thought to doing spikes.
Re: Why Development Teams Struggle to Deliver on Time, on Budget, or at All
#73So the author of this has a vested interest in their "solution" being the correct one, but I fundamentally disagree with it.
I agree with their hypothesis that we are bad at planning/estimating, but the solution is not spending more time on it, but rather less.
Firstly I really like this humorous look at the problem: https://www.quora.com/Why-are-software-development-task-esti...
You cannot estimate what you don't know, and you don't know what you don't know and no amount of upfront planning will surface those. In their own example, you can't know upfront that there is a road closed or an accident or that only one cashier is working until you get to that point.
In my opinion the most reliable solution is to break the work down into small pieces that deliver value (ideally less than a week's work). Prioritise and then deliver the first piece. Have regular reviews/checkpoints with stakeholders to decide whether any value was delivered, are there new learnings that we need to apply to the rest of the project, or indeed new 'pieces' that we've discovered now need doing, what is the next piece we need to do and is it worth continuing.
Re: Why Development Teams Struggle to Deliver on Time, on Budget, or at All
#74The 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…
Recent discussion:
Re: Why Development Teams Struggle to Deliver on Time, on Budget, or at All
#75In 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…
> The way to do this well is to break down a feature until they’re at about half-day sizes tasks. I have never seen that work in practice.
I've never even seen it work in theory.
Re: Why Development Teams Struggle to Deliver on Time, on Budget, or at All
#76Earlier quoted context omitted.
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 invar…
Maybe, maybe not. I’m very suspicious of things that are pitched as a panacea for everything.
The real world is a messy place where even with a good team, a good plan and sensible expectations you can fail spectacularly.
If there is one thing that I really like is aggressive validation of the assumptions that are being made + keeping the product as small and lean as humanly possible (and the latter should apply across the board to everything you do).
Complexity and Entropy are preparing the coffin for your work even before you have the idea. You can give ‘em a run for their money, but in most cases you’re going to end up 6 feet under. As soon as you accept this and are genuinely open to failure you will be ready for the opposite.
Re: Why Development Teams Struggle to Deliver on Time, on Budget, or at All
#77As someone that does this every day across all industries and project types, I agree 100%, but proper/effective planning is not a panacea for project success.
Identifying and managing Risk is as equally as important. As is Interface (the people to people / team kind) management and correct Quality Assurance.
On top of all of that you need good Project Governance to handle change properly, with clear limits and bounds for changing durations of activities, budgets, scope and acceptable quality, defining responsibility and accountability, delegating authority, setting regular reporting requirements and cadence.
Managing (non-trivial) Projects well is difficult, it takes hard work and careful thought. That is why we struggle. We revert to System 1 for all aspects of project management, not just planning.
Re: Why Development Teams Struggle to Deliver on Time, on Budget, or at All
#78In 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…
How do you estimate how much time a task will take, especially when it's a novel idea, at least for your developers?
> How do you estimate how much time a task will take when it's a novel idea
In my experience, they just pretend it doesn't exist and remove it from the "plan". Where I see this the most is in figuring out how things work. For some reason, non-programmers have it in their head that once you've finished college, you ought to know (even though they don't) how everything that goes on a computer works instantaneously. We're going to use Apache Kafka! Ok, need to spend some time figuring out how that works. Um, ok, that should take like an hour, right? Because there's no time in the budget to learn anything. If you push back, they say, "ok, never use anything new that you have to learn. Only use the things you already know". That doesn't work either, because the things that we have to integrate with don't work with the old things. Or, "you don't need to know how that works, Bob knows how that works, just ask him. But don't let it take any time, because there's no time in the plan for that" And Bob is sick of all your questions that you'd know the answer to if you'd just spent a two or three days reading the online documentation and installing a test system and testing it out.
Re: Why Development Teams Struggle to Deliver on Time, on Budget, or at All
#79Earlier quoted context omitted.
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.
Why bother estimating? you have the checkboxes, now just get to work. If the pace of checking those boxes is slow then you can start cutting things out. Estimates are for managers, much better to just ship it already.
Re: Why Development Teams Struggle to Deliver on Time, on Budget, or at All
#80The thought occurs to me that no matter how much planning you do or how good at estimating you are, the development is going to take however long it's going to take. You can plan your trip to the store to buy milk and figure out exactly how long it will take, but the only thing that actually matters is that you arrive back home, with milk. If that milk is absolutely necessary, whether it takes 30 minutes or ten minut…
> the development is going to take however long it's going to take
Hofstatder's law: It always takes longer than you expect, even after accounting for Hofstatder's law.