BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News The Planning Poker Prevents Fallacies in Effort Estimates

The Planning Poker Prevents Fallacies in Effort Estimates

Leia em Português

Bookmarks

In his recent  blog posting “Planning Poker: Avoiding Fallacies in Effort Estimates” Hayim Makabee discusses a common problem of effort estimation called planning fallacy and why planning poker helps to avoid it.

Effort estimation might be one of the most challenging activities in software development for managers and engineers. One  common problem in this context is effort underestimation caused by planning fallacy. Wikipedia defines planning fallacy as

a tendency for people and organizations to underestimate how long they will need to complete a task, even when they have experience of similar tasks over-running.

To illustrate possible characteristics of this problem, Makabee quotes Daniel Kahnemann, nobel laureate and author of “Thinking, Fast and Slow”. Many plans and and forecasts are unrealistically close to best-case scenarios, and they could be improved by checking the statistics of similar scenarios.

Makabee thinks that in software engineering there might be two major reasons for the planning fallacy:

  • If the manager is the one doing the estimates, he has an interest to make them hard to achieve, in order to push people to work more productively. Managers always want to see the work completed as fast as possible.
  • If the worker is the one doing the estimates, he will be ashamed to assign too much time to himself. People are afraid of doing pessimistic estimates for their own tasks, because they may appear to be lazy or inefficient.

Thus, additional people should participate in the planning who do not have a personal interest in the task.

This is why, according to the author,  the Scrum planning poker is helpful. It enforces independent and consensus-oriented effort estimation by multiple participants. In the planning poker each participant gets a set of cards with numbers and chooses one of the cards to estimate the effort for a specific  task. The cards are "simultaneously shown and people can compare and discuss their estimates". Makabee proposes to leverage planning poker in order to avoid the planning fallacy, because many people are  estimating in the planning poker including those not responsible for the task. In addition, participants make their own independent estimates and need to explain their estimates, especially when they are very low or high.

A couple of readers commented to the article.

Putcha V. Narasimham thinks, the planning poker is really helpful:

Recently I came across Planning Fallacy but I did not know that Agile has a remedy for it through Planning Poker. In deed it is a great and practical trick. A rare sensible thing I have seen in Agile Method.

Kirschilan adds:

In addition to all said above, it should be noted that estimating using planning poker is one aspect of this. Another is using real empirical data to fit scope to the plan. In agile this concept is called velocity.
The idea is that, assuming our estimation model is rather stable, regardless of optimism, we can use these numbers to figure out how much did we really fit in in previous periods, in order to plan the upcoming one.
Using these data over time helps the team “consult the statistics of similar cases” in their own recent history.

Here is a post referring to using empirical data to to continuous planning, rather than plan once up front:
http://fostnope.com/2012/05/14/what-does-a-butterfly-say-at-the-end-of-the-day/

Another reader, Pavel Bekkerman believes that effort underestimation by managers is the worst practice ever, caused by absence of adequate training. In addition, he says:

In absence of methodology we have individuals and teams largerly desynchronized in their work and not aligned with master plans. We have managers struggling to find their place in a chaos, and not providing any impact. And now the bottom-line question:
Do you REALLY think that with such a legacy, it is possible to expect anybody to learn from previous experience and provide adequate estimates on any task longer than 1-2 workdays?

… to which Makabee responds

[…] However, I do think that some companies are in much better shape than others. In particular, I’ve seen how the adoption of Agile methods has improved the situation in practice. [...]

 

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Again, ill informed agilists throw baby out with bathwater

    by Ethar Alali,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    A planning poker in itself does nothing without the feedback loop that gives us knowledge of how accurate we are as teams.

    Back in the old days, the practise of estimating for best, most likely and worst case scenarios was taught to every student of software engineering. This is also taught to students of management and forms the basis of the PERT and Six-sigma estimation mechanisms.

    Agile methods aim to do something similar to the above, but instead of statistically aggregating the time estimates of 'best', 'most likely' and 'worst' by the individuals doing the job, the planning poker often degenerates into a group think process.

    When differing opinions are not encouraged or there is a social penalty for doing so (like explaining their stance, which is not for everyone if the members of the team include more introverted members), or the safety factor is not there (the safety check is only part a retro process normally) then estimates will align to the views of any capable team members, those who shout loudest, have the greatest perceived respect or will even cause members to conform to avoid explaining their individual score, especially if they have had to grudgingly change it in the past. This leads to a group think process where estimates converge to a value which is not necessarily more accurate than before, just more predictable (same means as estimates before, but the standard deviations are narrower).

    Additionally, most teams do not monitor how well their actual delivered work (velocity) matches their estimates. Some of the 'toy tools' out there that teams use on the premise it aid teams, completely fail to provide accuracy estimates. As a result teams have no idea how well they are doing.

    That said, the breaking down of tasks into smaller atomic tasks is a really good idea. We humans are hopeless at estimating the size of things as they get bigger. For proof, just ask someone to draw a one inch line. Then ask them to draw a yard line. Measure them both and compare the differences between the drawn lines and the actual distances and you will see what I mean. So making the tasks small and trivial will help control the variance a lot!

    I would nudge people in the direction of Joel Spolski (Joel on Software) who has a good section of his site on how you can adjust estimates over time to reduce the variance in dev estimates. Most devs will either find it way over their head or have no interest in it. So Scrum masters and project managers may want to shoulder that responsibility as part of their process improvement responsibilities.

  • Agile or Lean shouldn't be used where estimation is needed

    by Adam Nemeth,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    An estimation can be only used on plans. If you have no plans, estimation doesn't work.

    Plans needs "moderately big" upfront design. It actually needs a pretty correct design, which shows realities well, and is based on previous data.

    Now, this is documentation, BUFD, and "waste". None of these works in coder-oriented methodologies like Agile.

    However, if you switch back to old methodologies, suddenly, you can calculate with ease: using a model-based estimation like FPA, and some good software design skills based on a few projects' practice RUP or Iconix or whatever, you can create dead-preciese estimations.

    So, it's not that estimation doesn't work, it's just that if you have actually serious deadlines, forget Agile.

  • Re: Agile or Lean shouldn't be used where estimation is needed

    by Ethar Alali,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    As much as I am desperate to agree with you Adam and often do, I can't wholeheartedly agree more than about 95% on this one (estimated ;-).

    Lean can be based upon actual statistical analysis of the delivery of software by that team over time gone by (after all, the manufacturing roots do it all the time), in a similar way that function pointed methods (e.g. FPA and Weighted MPA) can be used. After all, if lean is done properly, then things like lead times become a major factor in improving delivery and so should be a metric in any lean continuous improvement cycle. This is why my comment started with 'the baby... bathwater' comment as I am pretty sure that once data is collected then these methods can equally well apply to them in an agile environment. Note, the 'time gone by' bit, as you are quite right, if you have not done a project as a team before you can't estimate and it just becomes a guess.

    IMO, It is that people do lean wrong in software. Any attempt to get them to do it right is seen as 'enforcing a process' and suddenly it becomes BUFD/BDUF, documentation and waste which is a convenient argument to not do it, despite the ironic use of 'tools' [*nod* and *wink* at the agile manifesto... then a *shake of the head*] such as LeanKit which, in my experience, is used like a toy and doesn't contain any decent statistical analysis tools to aid prediction, improvement or correlation of practise changes with effects. Such basic tools deliver meaningless statistics for 'cumulative flow' which gives no better probability of success than guesswork, which is really what you are saying.

    Hence your point of view, when seen from this perspective, I wholly agree with!

  • Re: Agile or Lean shouldn't be used where estimation is needed

    by Dave Nicolette,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Adam,

    I might suggest that if you have serious deadlines, the thing to forget is fine-grained estimation. If you have time-to-market pressure, do you have time to do the BDUF required to support FPA as an estimation tool? Is your customer asking for estimates or for results? Regarding planning poker, even that may introduce too much overhead if you have "serious" deadlines (I'm taking the word "serious" seriously.)

    Instead, you might want to consider a highly streamlined approach that just knocks out work items one by one in priority order without analyzing them to death first. It's only software, after all. The difference in effort won't amount to years vs. minutes. It will be more like x weeks vs. y weeks. The investment in up-front estimation might not be repaid if we're on a tight schedule. Besides, no one will really care if your estimates were accurate. They will only care that the maximum possible amount of high-value functionality was delivered in time to matter to the business.

    See davenicolette.wordpress.com/2012/06/28/choosing... for one POV. (That's not strictly about estimation, but it's related to the idea of dropping back to traditional methods when we are facing a tight delivery schedule.)

  • Re: Agile or Lean shouldn't be used where estimation is needed

    by Dave Nicolette,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Adam,

    Sorry to be repetitive, but I just noticed your comment seems to be based partly on a misconception that there are some delivery methods that don't have plans. There's always a plan. With some methods, a detailed plan is created in advance and then progress is assessed by comparing actual results with that plan. This appears to be the only planning approach you're aware of. Other methods have plans, as well. Adaptive methods proceed based on less-detailed plans and evolve their plans based on lessons learned along the way. With adaptive methods, progressed is assessed by looking forward, toward a range of likely outcomes, rather than backward, toward a comprehensive plan created at a point in time in the past. With both traditional and adaptive approaches, however, there is always a plan.

  • Re: Agile or Lean shouldn't be used where estimation is needed

    by Adam Nemeth,

    Your message is awaiting moderation. Thank you for participating in the discussion.



    but I just noticed your comment seems to be based partly on a misconception that there are some delivery methods that don't have plans. There's always a plan. With some methods, a detailed plan is created in advance and then progress is assessed by comparing actual results with that plan. This appears to be the only planning approach you're aware of.



    Beg your pardon?

    Trying not to be tongue in cheek, but:

    1) There's no plan always. Look at Lean Startups: they don't plan beforehand, that wouldn't be Lean. Brain-dead, stupid? Guess so, at least, to apply this generally. Unfortunately, noone died in IT for participating in a failing project with faulty ideas, so they'll go on to the next project to have the same stupid ideas.

    2) It seems that Agile and Waterfall are the only methods you're aware of. Sorry, between them, there are lots of design-oriented methodologies. Now you have to understand two things about design: design differs from the real thing in that it has a restricted set of concerns (viewpoint) and it has a restricted resolution. An executable program is not really a design, since it encompasses all the viewpoints and it can be extracted to 1-1 resolution.

    3) Since design differs in resolution, you can have either a big design of low resolution or a small design of high resolution. Or you could do implementation, which is creating a big design in high resolution...

    4) Concerns are separatable to unknowns and knowns in case you care about it. With Agile Planning Poker, you don't untangle stuff. With FPA, you do. There are knowns and unknowns.

    5) It might be surprising, but if you do untangle these, and measure them through the project, you'll see that the time it takes to do a single "known" or "unknown" part both fall within a bell-curve given that the team and the techonology is the same. That is, you can expect that a project consisting of 5 input forms, 2 display pages, 3 datatables and an external API will take a certain amount of time, +-10%, because you know for each part, that it'll take about that time.

    6) RUP does high-level design while the low-level implementation of the first parts is already underway. This way, we'll have precision control on two levels: how much a 'big block' costs and how much 'small blocks' cost. In theory, there's low level planning in Agile, with daily stand-ups and commitments, in practice, I'm yet to see if failing a daily (and sometimes: sprint) commitment actually had any effect in any companies. Usually all the benefit it had that it moved the air molecules a bit while the person was speaking, and when the soundwave rippled off, so did the promise.

    7) The planning abilities with user stories and planning poker is about that of a bad joke. With FPA I did have numbers, and I did have +-10% runoffs at most at the second project of the same team. But that needed careful understanding through design of what we're doing, and since that is not really found in Agile (the lightweight design methods proposed by Agile are like toys based on anecdotal success compared to some older desgn methods, or those used by other communities)

    8) Of course, you have to understand sometimes you need to make changes as sometimes things don't go according to the plan; if it doesn't matter, you could change the plan as well, but removing obstacles while keeping the plans would be a much more benefical way. It seems Agile people love their obstacles better than their plans, but when they tell the customer that because of this, he has to drop his plans, it's a bad joke. Work on removing the obstacles, and forget your Agile playground - if a tool doesn't work well, get another one or throw it out, if a method doesn't work well, get another one or get a tool to do it instead, if a team doesn't work well, restructure it.

  • Re: Agile or Lean shouldn't be used where estimation is needed

    by Adam Nemeth,

    Your message is awaiting moderation. Thank you for participating in the discussion.



    I might suggest that if you have serious deadlines, the thing to forget is fine-grained estimation. If you have time-to-market pressure, do you have time to do the BDUF required to support FPA as an estimation tool? Is your customer asking for estimates or for results?


    I don't know about your customers, but mine usually ask for both. And I don't know about you, but if I have a serious deadline, the first thing I throw out of the team are the coding cowboys, those who don't plan just code. Those who can't think straight when there's a deadline, and refuse to do so when there's a deadline are in panic mode, and shouldn't be employed on places where the deadlines are short. When I didn't have these, we always succeeded. When I'm required to keep those I try to assign non-essential tasks to them, like coloring all the buttons red or such.

  • Re: Agile or Lean shouldn't be used where estimation is needed

    by Adam Nemeth,

    Your message is awaiting moderation. Thank you for participating in the discussion.



    IMO, It is that people do lean wrong in software. Any attempt to get them to do it right is seen as 'enforcing a process' and suddenly it becomes BUFD/BDUF, documentation and waste which is a convenient argument to not do it, despite the ironic use of 'tools' [*nod* and *wink* at the agile manifesto... then a *shake of the head*] such as LeanKit which, in my experience, is used like a toy and doesn't contain any decent statistical analysis tools to aid prediction, improvement or correlation of practise changes with effects. Such basic tools deliver meaningless statistics for 'cumulative flow' which gives no better probability of success than guesswork, which is really what you are saying.


    I'm slowly accepting the fact that development became a playground: Agile and Lean isn't about what they're called, they're about kids not wanting to grow up, and fascinated by shiny interfaces, and refusing to work on schedule, or do serious thinking which doesn't involve playing with a beloved concept (like, TDD, or role-playing of Scrum... oh, how I hate gamified retrospectives!) or tools.

    All pen-and-paper technologies we had are lost, well, except for the post-it-on-whiteboard thingy, for which I find a decent project management tool and a plasma screen to be much more effective. I loved going physically to a different office in order to put a sticker physically to a board in order to make them do it in that sprint.

    Not to mention that a huge amount of developers are socially impotent, and can't talk to customers and especially in a way in which they provide respect for them. Words like "luzers" for users are all-too-common. They can't understand that someone just wants a task to be done. They could be gorgeous girls who could cook really well and perhaps at home they're also interested in Manga or whatever, it's just they don't want to cram through an interface made up by someone who knows too much about computers.

    The net result of this is that design activities are completely taken out from the hands of the developers: they can argue about CouchDB vs MongoDB, or how many cloud instances should the system have exactly, and the real design is done at the UX departments: Grab a UX book, or watch an enterprise UX team: they'll define all the algorhythms, all the data structures for you besides all the screens to the user, and they won't even provide you with an explanation on how it should be done. And they won't respect you: for them, you're a monkey, a kid, who could never grow up and can't do the essential stuff: the code monkeys.

    Look at any UX book (About Face, Interaction Design beyond, The Inmates Are Running The Asylium (just the title is enough: those inmates are called developers) to see how UXes think of development: it's just implementation, and they're right: if they'd care to make their output more MVC-like, programming average applications would be a typing lesson. Fortunately, they're a lazy artistic bunch, who also like to have their own shiny toys (drag-n-drop for the masses! Don't care that it has no affordance nor visibility, that all your textbooks tell you it's unusable, if you do it often enough, people will learn it for sure! Yeeez...), so the fights will continue for some time...

    But we aren't winning in that right now. Perhaps for tomorrow on, UX will take on planning as well.

  • Re: Agile or Lean shouldn't be used where estimation is needed

    by Dave Nicolette,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    "There's no plan always."

    Yes, I perceived your misconception the first time.

    "It seems that Agile and Waterfall are the only methods you're aware of."

    Really? You must have me confused with someone else. I don't even care for the words "agile" and "waterfall" because they are subject to so much subjective interpretation...such as your own.

  • Re: Agile or Lean shouldn't be used where estimation is needed

    by Dave Nicolette,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    "... refusing to work on schedule..."

    Well, if that's the root cause of schedule slippage, then we can all save a great deal of time by not bothering with any root cause analysis. Just blame the team members. Easy-cheesy.

    In general, your comments serve as a description of The Problem with software delivery. I don't know if you're expressing this point of view as a sort of devil's advocate, or if you really believe the things you say. If the former, then congratulations - you got me!

  • Re: Agile or Lean shouldn't be used where estimation is needed

    by Ethar Alali,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    With all due respect Dave, I have rarely come across a team who actually do the process improvement bit well, when it comes to improving delivery times. We are all aware of the cone of uncertainty and how both agile (well, lean) and more heavyweight methods such as RUP and indeed waterfall attempt to deal with that. So in Adam's defence, if he has been with teams who exclude the top rung planners and improvers, then he can definitely be forgiven for coming to the conclusion that agile doesn't work which is exactly the stance agile practitioners took with waterfall.

    You are right in that there is always a 'plan', or as I prefer to put it in agile, a 'vague' strategy. The question I ask of the industry is how do they improve upon them. Adam has offered a reasoned argument and all that I have seen in response is "you can't believe in God because you are not religious". As someone with a heavy empirical as well as theoretical bias, I would need to see strong evidence that teams do this and deliver on this. RUP and it's planning allowed me to deliver almost every time on time and in budget. Agile I have had less success with. So I know what I prefer, though am certainly not averse to lean agile when done properly.

  • Re: Agile or Lean shouldn't be used where estimation is needed

    by Adam Nemeth,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Thank you for the support Ethar.

    Personally, I've always delivered on predicted time with RUP, or at most reasonably on time (my largest slippage was less than a week, of a 3 month long process compared to the prediction, but in these cases usually we build in safety margins anyway, so it didn't hurt anyone)

    And I've seen the "perfect" Agile company in motion (they make mobile phones). They can easily slip by multiple hundreds of percents. "Oh, Mobile World Congress is coming, are we ready yet?" "Nah, just don't show this feature" "OK, MWC has gone by, but next quarter there'll be CES. What about that?" "Ah, we aren't ready yet" - and then, "Cr.p, Google released a similar app compared to what we've been doing for months!" "OK, we'll bring something out quickly", and the one and half a month (3 sprints) passes, and then they'll show something. Everyone thinks they copied Google. Nope.

    If NASA had used Agile, we wouldn't had people on the Moon.

    Sometimes I bring up the fact that the demise of this company coincidentally started when they introduced company-wide Agile, but there are just so many believers on this developer-centric approach that everyone will just quickly dismiss this claim, as not having deadlines is fun.

    And they do Agile perfectly right: they have these personal improvement stuff, they have these retrospective meetings, and they literally spend billions of Euros to make sure that they do Agile right. You can't find a single book according to which they don't do Agile right. They have people whose sole job is to do Agile Oversight.

    In case you think there's always a plan, look at this, "We don't know the problem" - or this. Industrial Logic is a funny bunch in the sense that what they say is pretty cool until you try out their product. It's a startup producing worse-than-enterprise quality applications, which I thought it was the lowest quality possible.

    I don't think that we should have applications on the quality level of IL, and I think IL and this mobile company are the perfect examples of that no matter how much you do TDD or Lean or Agile, your product can be still a mess beyond all belief. So, in general, Lean is even worse than Agile.

    I'm dead serious that there are people out there in this industry who don't want to do upfront planning even on what's possible. I'm dead serious that I don't really want to work with them and I don't want to use their products.

    Every single year, it becomes harder and harder to explain to students and young software engineers, that yes, they could still estimate, yes, it is still possible, yes, applications can be designed, as they come from crappy environments where being late is the normal way of life. They say: "this is software. This is always new stuff. So we're entitled to be always late."

    Every single year I have to look for younger and younger people who don't have this expectation.

    Every single year it gets harder to explain complex stuff to programmers, as they're unused to complexity anymore. If the complexity is just a bit over what could be easily handled by their framework-of-choice, they're lost. I remember, when designing a map application, I had to explain trigonometry. I don't even try to show complex algos, but tell them instead: look, you'll have a function to call. Call this when the user presses the button A, ok? In one instance, I was going back to a point where I simply asked for write access to their source repository....

    When I work alone, customers are surprised... suddenly, everything is clear, suddenly, deadlines are matched, suddenly, they see what's important to them first, then I excuse myself for about a week, come back with a rough prototype they can test, we speak about it, and about a month later, on the day of the deadline, they have a perfectly working application, for which they had continous input, daily in most part of the process. They just plug it in and it works. Agile can't deliver that, RUP can.

    It's not that other developers couldn't do this: the craziest part is that they're not even interested in it! When I tell them, that: "you see, with just a spoonful of design, you can match deadlines effortlessly" to which the answer was: "a software is ready when it's ready. And it's always late". They're interested in the tribal wars of Spring vs Ruby on Rails, they're interested in "how to bring this to the cloud", they're interested in technology muslings.

    So, as I said, as things stand, developers will become more and more unreliable, and they'll be more and more degraded to the role of a monkey. While Agile brought freedom, the way developers became the kings of IT (as no matter what, code has to be written), the way developers exploit this freedom will be their demise soon.

  • Re: Agile or Lean shouldn't be used where estimation is needed

    by Adam Nemeth,

    Your message is awaiting moderation. Thank you for participating in the discussion.



    Well, if that's the root cause of schedule slippage, then we can all save a great deal of time by not bothering with any root cause analysis. Just blame the team members. Easy-cheesy.


    You misunderstood me. I don't blame anyone. I fire them and deliver on schedule, with full functionality. I'm an architect. An architect is fully responsible for the result. I can't blame PMs, I can't blame team members, I can't blame the customer, I can't blame anyone, I can't blame even Agile, or industry situation in general. I promised X functionality to be ready for day Y, and either it's ready or not.

    But it'll be only ready if I leave the Agile-priests behind. There are plenty of other teams when they can enjoy their own way.

    I have the root cause. Software is about people, and their way of thinking. It's only it's a bitter root cause that Agile thinking hurts the industry, and there are only a few people willing to swallow it.

  • Re: Agile or Lean shouldn't be used where estimation is needed

    by Ethar Alali,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Indeed. The thing with agility is that a lot of things have been redefined compared to traditional methods. For example, there is no such thing as a production 'bug fix' in some methods. These are redefined 'releases' (rightly or wrongly) and so it gives the illusion of a 'release' (and consequentially affects velocity) relative to other methods. So a pinch of salt when someone says "we release every day" as it could be that they are releasing a whole set of bug fixes :-D

    As for the links you put up Adam, I think agilists in the industry have missed the point when they say they don't know the problem. There are two ways to look at development. The first is the foresight way, where you look ahead into the distance and either plan all the steps to get there (or look into the distance and adjust as necessary, which even Beck's work on XP encourages us to do) or alternatively, work completely reactively, assuming everything will go wrong, so you plan to put things in place to mitigate the risks when they do. All these methods require some foresight, even the latter 'defensive' approach (harking back to the days of defensive programming, admittedly which TDD is a form of, believe it or not).

    You are absolutely right about the quality of graduates nowadays. They are absolutely abysmal when it comes to say, optimisation problems (which are the sorts of things engineers truly do, remembering that optimising teams is the same class of problem). In the UK, the number of grads with experience who can't do the basics is astounding and getting worse. XP was designed to get improvements out of 'developers of average ability' and that is what they are getting. Obviously the smart developers/architects are vastly outnumbered by developers of lesser ability by maybe 50 to 1.

    So when ideas advocated in XP 1st edition take hold (whether done well or badly is immaterial), it will be very difficult to shift. You just have to improve on it, presenting it in ways that cater for the average staff you are trying to convince, since the other option would be to wait until the 1 in 50 comes along and given the way agile is killing the roles and need for that proportion of the populous (i.e. these odds will get worse) then you could be waiting a long time, potentially risking longer term business and projects.

    Adam, I am with you and if I had my way and the world was perfect, scheming wouldn't be needed. After all, there is almost no fault in reason or logic, but the reality is human beings get in the way :-D

  • Re: Agile or Lean shouldn't be used where estimation is needed

    by Dave Nicolette,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I don't want to get into a circular debate based on observations by people who have not actually used all the different methods they are comparing, but I would like to comment on a few points made by Ethar and Adam.

    Ethar: Like you, I also have not seen many teams that practice ongoing process improvement effectively. This has nothing to do with the topic of the original article. While the observation is accurate, it is not connected with any particular methods or practices those teams use. It has more to do with the fact that most people tend to want to follow a method by rote and not apply critical thinking in their work. That's an important topic in its own right, but not the topic of this article.

    Ethar: Plans in "agile" methods are not "vague." The comment demonstrates limited practical experience with these methods on your part; nothing more. As in many walks of life, the important thing is the planning activity, not the specific point-in-time plans that come and go over time.

    On those occasions when you wanted to apply "agile" methods, perhaps you were unable to come up with anything better than a "vague strategy." That's unfortunate. You probably did it wrong. Yes, I know that's a stereotypical response, but bear in mind that when any of us tries to do something for the first time, we're likely to make mistakes. Search your memory for the first time you tried to use the methods you now depend on. Didn't it take some practice for you to master those methods?

    Ethar: Your "religious" comment is pure, unadulterated bullshit. I am the least "religious" person with regard to software development methods whom you will ever meet. Ever. Different methods are useful under different circumstances. The key is to understand what those circumstances are and which methods are called for. It is you, and Adam, who seem to be looking for a Single Best Way, and "religiously" discarding anything that doesn't correspond with your personal experiences. Good luck with that.

    FWIW, I'm not disputing the validity of your experiences. Based on your own comments, I do wonder about the range of different experiences you may have had, though. All the things you and Adam say have worked for you have also worked for me at times. All the things you and Adam insist cannot possibly work have also worked for me at times. Over the years I've been learning how to tell when a given approach is applicable. You can learn from that or you can just repeat "religious!" "religious!" mindlessly. Your choice.

    Adam: When I have seen people delivering in line with their estimates time after time, it has been in situations when the work is somewhat consistent from one project to the next. Once we have delivered a couple of projects pertaining to the same business domain and using the same general set of tools, it is certainly feasible to estimate the third, fourth, fifth, etc. projects that have the same general scope and overall characteristics. This is not the sweet spot for "agile" methods. If you attempted to use "agile" methods in that sort of situation, then I would expect you did not obtain value in return for the process-related overhead of incremental delivery, iterative planning, and customer feedback loops. When we are in a situation that calls for collaborative exploration of the solution space, then methods that include those sorts of activities can yield benefit. When the solution is largely predictable, then the cost of the overhead of "agile" methods is not repaid.

    Adam: You don't blame people, you just fire them. That says everything anyone needs to know about your professionalism as a manager.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT