21–30 of 147 posts
Author here if anybody has any questions.
It doesn't provide high-level estimates that management provides, doesn't do budget planning for you etc.
How do you approach these topics with Kanban?
Author here if anybody has any questions.
Kanban plus occasional pair programming sounds like a great software development methodology, but it's not project management. It doesn't provide high-level estimates that management provides, doesn't do budget planning for you etc. How do you approach these topics with Kanban?
Earlier quoted context omitted.
I think what a lot of people fail to take into account is the amount of effort it can take to "estimate" tasks. From my experience, the more pressure there is to give an estimate the less time they want you to spend researching the work. To increase the accuracy of an estimate, you need to do more research and if you take that to its logical conclusion then the best estimate is given after the work is completed. So t…
High level estimates aren’t optional for most development. Customers waiting for an important feature won’t take “ it’ll come when it comes, estimates aren’t real” as an answer. You can skip low level estimates, but the consequence of that is that high level timelines are uninformed by them. That’s how you end up in the archetypal situation where all the engineers know a project will slip while their managers report…
The author touches on this indirectly a couple of times, but I think the main realization this gives me is that we tend to conflate two things when doing software project management: * Getting the project done well and on time. * Evaluating the performance of invidual programmers. This is probably a natural thing to do because one measure of "good programmer" is "gets projects done well and on time", but I think dire…
It's pretty refreshing to read posts that admit 'management is difficult' on HN. We can get a bit lost in our bubble of tech work, and forget how important management is to actually accomplishing things.
Earlier quoted context omitted.
This was a great write up! I’ve been thinking about this problem A LOT while building a project/team planning software startup. What do you think about having every engineer estimate one task for the upcoming sprint? Also, I’ve found that the estimation process ( I.e voting ) in my experience is better if blinded, otherwise there will be extreme peer pressure to over or under estimate.
That pressure can be very real. Personally, I don't see a tremendous amount of value in overthinking estimates as much as re-evaluating estimates once the task starts. The methodology I mentioned calls for exactly that, estimating best case, realistic and worst case...and then re-evaluating once the work starts. You never really know until somebody dives into the work and it's rare to actually get time before an esti…
Any suggestions for how to effectively communicate a "best guess" and a "re-evaluation" to a business side that basically demands "hard deadlines" for projects?
This worked well and was driven by his understanding that most of his effort needed to be focused on identifying and mitigating delivery risk. Most often the key risks lay in trying to estimate the level of effort required to develop key new functionality when all involved had limited prior experience in developing similar functionality. In those cases funding a short time bounded study to explore the technologies involved and figure out the art of the possible reaped huge rewards downstream.
If only all customers were that enlightened!
Author here if anybody has any questions.
A few years ago I was technical lead for a team that worked one of the largest IT systems in the UK that you've probably never heard of. The customer was truely enlightened and would fund short technical de-risking studies to understand and scope challenging tasks before asking the contracting organisations to produce a firm price proposal for delivering the capability. This worked well and was driven by his understa…
Every step in a software project is solving problems. You don't know how long it will take to solve the problem. You don't know how many new problems you might run into along the way.