Subj : Re: Expect/standards/lineItemBilling (was: How much should I charge...) To : comp.programming,comp.lang.java.programmer,comp.lang.lisp From : Scott Ellsworth Date : Wed Aug 31 2005 05:00 pm In article <0001HW.BF359952020510DDF0488550@news.verizon.net>, Randy Howard wrote: [...] > Ahh, there we are. A story points chart, doesn't that sound > lovely? Well guess what. It's a dated to do list, although > when created by people that buy into lingo instead of action, > it's probably not as informative. I have joined very few software teams whose programmers had a good grasp of time, or progress towards the goal. After one dreadful experience, I started to make 'what is the goal, and how are we doing on getting there' a part of my toolkit. Not because I love project management or project planning - I prefer writing code - but because I saw teammates get their teeth into an interesting problem, then burn cycles trying to optimize something only done once in a blue moon. The whole 'story points' or other agile bushwah at least gets the programmers committed to shipping software that does something somebody wants. Sure, that is what management is supposed to do, but a lot of those managers have never been taught how to manage. Thus, a wise developer finds ways to manage their own time, and ways to be clear about what they need their manager to do to get the job done. Story points is just one of many ways, and it works or it fails depending on who does it, and how much their own management is listening. [...] > "Well, herešs the bottom line: Agile methods are merely a > technique for managing software projects. Their purpose is to > provide managers with the data they need to make timely > management decisions. And this should be good news for those > project managers who know that managing a software project often > involves more prayer than science." Yep. I have used Agile and XP methodologies, along with waterfall, seat of the pants, low hanging fruit, and hardest problem in sight. Each one worked or failed depending on the team, the project, and the management. > So there is the smoking gun, it is to make managers happy. Note > that it doesn't say anything about better, faster, cheaper, or > anything that might actually be useful, but gives them better > charts for their powerpoint presentations to the next layer of > morons in the meeting next Tuesday. I sense bitterness. Look, better, faster, cheaper, and useful all depend on the next word - better than _what_. If an agile methodology means that your team figures out that they have six months of work, and three months of schedule sometime in month one, rather than in the last week of month three, then it did its job. If it then lets you prove it to whoever is setting the schedule, then you had a big win. If it is just a set of buzzwords a manager uses, and that the team could care less about, it is a waste of time. Like any other methodology. It is not magic, it is not a mind control laser that will make your management get clue it has lacked. It may, though, have the buzzwords needed to get someone to listen. Very often, getting a dramatic change requires evidence that someone else tried a similar change, and is still employed. Scott -- Scott Ellsworth scott@alodar.nospam.com Java and database consulting for the life sciences .