Discussions

News: Article from TSSJS: Agile best for delivering products on target

  1. One aspect of creating quality software is delivering a product that meets users' needs and expectations. In this article, Venkat Subramaniam from Agile Developer and Neal Ford from ThoughtWorks say that in order to do that, you need to use an agile development methodology. The reason for that, they said, is that those methodologies allow continuous communication with users during the entire development life cycle. Developers get high-level requirements, then immediately begin coding and give the users something that meets the requirements. The users can then give feedback on what was delivered, which the developers use to go back and refine the application. That cycle continues until the users are 100% satisfied. "The highest priority is to satisfy the customer through early and continuous delivery of valuable software," Subramaniam said. Interaction is key among developers and between developers and their users or customers, he added. "The longer the gap between requirements gathering and getting users' feedback, the farther off you'll be from your target."

    Threaded Messages (31)

  2. Nonsense[ Go to top ]

    Is anyone else sick of so called agilists trying to keep selling us stuff? With such gems as 'It's not important to deliver on time but to deliver something that works' it's no wonder they're so desperate to get on as many talks and commercial gigs as possible, just think of the endless hours they can bill! In many ways, thoughtworks has figured out how to wring the most out of the consulting gig, just claim that your methodology doesn't allow you to commit to any concrete timeframes, it'll be done when it's done and when everyone is 'happy'. This is, needless to say, many many billable months later, during which you're constantly told you need to ramp up your pair programming and have more of these idiots having fun at your expense. The article is a great poster child for why normal people now mock the agile folks. Quotes like 'Courage is also important, you have to have the courage to say your code is bad and fix it.' are twee, contrived, and pretentious. So I'm assuming that means that anyone not paying these morons any money is a coward of some sort? Do the terrorists win if we're not all agile? It certainly sounds that way based on the rhetoric.
  3. Re: Nonsense[ Go to top ]

    Is anyone else sick of so called agilists trying to keep selling us stuff? With such gems as 'It's not important to deliver on time but to deliver something that works'...
    There must be a cold front coming in Hell, Hani, because I agree with you completely. ;) If the Customer wants the product shipped by October in order to hit the Christmas market, you had damn well better ship something. Now, that's not to say that 100% of the features the Customer wanted back in January are going to be there. Part of the planning process in XP at least is prioritizing the features, and scheduling them such that the highest priority and highest risk features are dealt with as early as possible. The result is that if all features cannot be delivered by the specified date, then the ones that have to be left out are of lower priority. With agile processes, scope is negotiable whereas cost, time and quality are not. Adobe recently discovered this with the Photoshop CS3 release, and found that the agile approach worked much better for them. My experience over the past 6 years has been the same. Having said all of that, if the Customer's focus isn't on shipping a product by a certain drop-dead date but rather to ship a product with 100% of the features, then what the article states is quite reasonable. Dave Rooney Mayford Technologies
  4. Re: Nonsense[ Go to top ]

    There must be some freaky telepathic link at work because this article got my blood boiling as well and I just posted a few thoughts on my blog about it. Not sure if I should just paste it here or point people to it, so I'll just do the latter for now so that agile fans who get easily offended don't feel like they are forced to read something they will disagree with. It's at: http://beust.com/weblog/archives/000441.html -- Cedric
  5. You bastards![ Go to top ]

    I can't believe you would say such things about agile. What has agile ever done to you? :( I've based my entire identity on it and now here you are poking holes in my logic as if these were debatable concepts...When will we learn... If you aren't nice I may have to go in and force it on you through management - oracle style..You wouldn't like that now would you?
  6. Labor is cheap[ Go to top ]

    Cedric, Found this line in your blog. "The people quoted in this article, both with an obviously strong vested interest in agile techniques, are trying to convey the idea that agile practices give users the utmost priority, and that work will not stop until users are 100% happy:" Mind you, Thoughtworks do have a base in India where there is cheap labor when compared to other countries - so they could afford to go back and forth until customers are happy. :-)
  7. Or what got you quite so ticked off? Wow. This article was no more selling something than the link in Dave's signature is. You can't accept that "It's not important to deliver on time but to deliver something that works." You'd rather deliver something that doesn't work on time? Or course not. I'd accept "something that works" as just what you suggested ... enough of the highest priority business value to make it worth purchasing / deploying. "With agile processes, scope is negotiable whereas cost, time and quality are not." Can you cite chapter and verse on that? Our customer can renegotiate dates if he likes. Or scope if he doesn't. Is this vitriol all over some clumsily worded descriptions of the same things you do? Dave's web site does a decent job of describing agile. With the additional room there it does better than the short article and a few quotes, but it's far from my favorite description. BTW: I've worked with Thoughtworks before and would again. We run our projects no matter where the bodies come from, so I have no fear of them "wringing the most they can" out of us. Are they more "desperate" than anybody else working for a living?
  8. Clarification[ Go to top ]

    Or what got you quite so ticked off? Wow.
    :) Thoughtworks does seem to have a polarizing effect - people either love 'em or hate 'em.
    "With agile processes, scope is negotiable whereas cost, time and quality are not." Can you cite chapter and verse on that? Our customer can renegotiate dates if he likes. Or scope if he doesn't.
    Just out of curiosity, Jim, are you asking me or Cedric if we can cite chapter & verse?
    Dave's web site does a decent job of describing agile.
    Thanks!
    ...but it's far from my favorite description.
    Yes, some of the material is dated. I'm in the (slow) process of updating it and making it more comprehensize. Dave Rooney Mayford Technologies
  9. Polarizing ... yup![ Go to top ]

    Just out of curiosity, Jim, are you asking me or Cedric if we can cite chapter & verse?
    Dave: the line before it was from your post, but I don't really mind who responds. I'll repeat, our customers adjust dates and/or scope as appropriate. No big deal is it? Oh, and I didn't give your pages on agile quite enough credit. They're better than mine ;) though mine are even older and a description of what we really did in 2002, not an ideal.
    To do that [deliver a product that meets users' needs and expectations], you must use an agile development methodology.
    And that was quoted from Thoughtworks? The other presenter? Or just the way the correspondent decided to hype the story? Even if it was a direct quote, I'm pretty forgiving of hype that "this is the only way." Every cursed advertisement on the planet says it. I'm able to skip it without shouting at the TV.
  10. Re: Nonsense[ Go to top ]

    From the article: To do that [deliver a product that meets users' needs and expectations], you must use an agile development methodology. The contrapositive is: If an agile development methodology is not used, the product will not meet users' needs and expectations. I've developed a lot of software and have never used an agile methodology (that I was aware of anyway). I guess I've never met users needs and expectations. Darn! My bubble has been burst....after 17 years in the biz I learn this. I guess I need to look for a new career.
  11. Re: Nonsense[ Go to top ]

    From the article:

    To do that [deliver a product that meets users' needs and expectations], you must use an agile development methodology.

    The contrapositive is:
    If an agile development methodology is not used, the product will not meet users' needs and expectations.
    I was pretty sure you needed to use SOA, ESB, MDA, EJB or Corba (depending on what year you are living in)... Dang it! I must be lagging behind!
  12. Hani and other People here, can you provide some alternatives to the agile process for the web application development? I am in the process to improve our company's development process. Thanks! -Hank www.imhaha.com A web-based messenger
  13. Hani and other People here, can you provide some alternatives to the agile process for the web application development? I am in the process to improve our company's development process.

    Thanks!

    -Hank
    www.imhaha.com
    A web-based messenger
    http://www2.umassd.edu/swpi/DOD/MIL-STD-498/498-STD.PDF Have fun!
  14. Hani and other People here, can you provide some alternatives to the agile process for the web application development? I am in the process to improve our company's development process.

    Thanks!

    -Hank
    www.imhaha.com
    A web-based messenger
    Common sense and hiring good developers. A lot of Agile practices and principles are very useful and definitely preferable over bureaucratic monstrosities created to kill rainforests by creating a mindless array of documents that no one will ever read. But.. No process will ever replace the need for actual brain work and skill. So use common sense, agile practices are a useful starting point, but common sense should always rule over religious dogma. Trust good people to get the job done. Get rid of useless people (no process in the world will make them any good). / Wille Blog:
  15. Common sense and hiring good developers.
    A lot of Agile practices and principles are very useful and definitely preferable over bureaucratic monstrosities created to kill rainforests by creating a mindless array of documents that no one will ever read.

    But.. No process will ever replace the need for actual brain work and skill. So use common sense, agile practices are a useful starting point, but common sense should always rule over religious dogma.
    Trust good people to get the job done. Get rid of useless people (no process in the world will make them any good).
    Well said, Wille. Agile methods actually assume that the developers are willing and capable of thinking! If the developers simply want to code from a detailed spec, then they'll struggle under Agile methods. From the opposite perspective, I've seen good developers "rescue" troubled waterfall projects by using essentially agile practices, i.e. just "getting it done". Conclusion? The people have a higher order effect than just the process. The ideas behind Agile are intended to amplify the positive effects of having good people. I've heard dozens of times that the XP practices are nothing new - they've been in the industry for a while. That's absolutely true! Indeed, Kent Beck makes no bones about the fact that when he came up with the practices, he looked back on what had worked for him and others on successful projects. His 'secret spice' was to take all of the practices to an extreme level, e.g. planning, testing, integration and code reviews. His intent was to maximize the value of the good people he had working for him, and that's the light in which people need to view Agile processes. Without good people, any process is crap. Good people will generally succeed, and good people using Agile practices will be even better. Dave Rooney Mayford Technologies
  16. The ideas behind Agile are intended to amplify the positive effects of having good people.
    The big problem the Agile movement is struggling with today is that it has become an industry and religious dogma, it has become the next silver-bullet for a lot of people with vested interests in flogging services and tools. The same thing has happened before with RUP, CMMI, Six Sigma to mention a few (although I'd argue that the first two where never particularly useful besides being money-makers for their respective inventors). When religious dogma takes over from common sense, you've got a problem. This is the reason for me these days trying to push a lot of the Agile practices without ever mentioning the words "Agile", "XP" or "Scrum", people get an aversion for religious fanatics and whatever they try to push on you. ..also, some fanatics might label me an "unbeliever" because I use whatever I find is useful to the context (usually 80-95%) rather than everything, which you apparently must do to be admitted in the paradise which is Agile-heaven. Once common sense gets lost, credibility will eventually loose out as well. / Wille Blog: Buzzword Bingo
  17. Common Sense vs. Dogma[ Go to top ]

    The big problem the Agile movement is struggling with today is that it has become an industry and religious dogma, it has become the next silver-bullet for a lot of people with vested interests in flogging services and tools.
    Dogma is a bad thing in this industry, and it's prevalent at many levels. I've seen people argue at length over the "braces at the end of the current line vs. braces on the next line" coding style. It's ridiculous! I can't speak for others in the "Agile movement", but I'd like to think that my approach is quite pragmatic. I do indeed have a vested interest in flogging agile training and coaching services, but I do not and never will say to a potential client, "Do this and all your problems will be solved". What I do say is, "I have been working in this industry for almost 20 years, and this group of principles and practices has worked very well for me, and for others as well. They help reduce risk and improve quality". I also tell people that 'going agile' is hard, and requires discipline. It's an investment that requires time to mature and show its results. I've seen the dark side of development, and I did not like it. Others have suffered through that crap as well, and didn't like it. Agile in general is to me one answer to a lot of the issues we've had in the software industry. Bear in mind as well that 'Agile' today is different than Agile in 1999 or 2003, and I'm sure it will evolve further by 2011. Look at object-oriented development - today it's considered normal and mainstream, whereas 15-20 years ago its proponents were considered religious fanatics. Sound familiar? :)
    The same thing has happened before with RUP, CMMI, Six Sigma to mention a few (although I'd argue that the first two where never particularly useful besides being money-makers for their respective inventors).
    A few years ago I met with some local people from Rational to talk about some sort of symbiosis with RUP and XP. Their whole (and I mean whole) focus of that meeting was selling tools. IMHO, the salespeople who wanted to sell overpriced tools have all but killed RUP. Meanwhile, Booch, Jacobsen and Philippe Kruchten are on the record as supporting Agile (Grady Booch is a founding member of the Agile Alliance!). These people believe in agility as much as any of us do, yet RUP has fallen out of favour from what I've seen.
    This is the reason for me these days trying to push a lot of the Agile practices without ever mentioning the words "Agile", "XP" or "Scrum", people get an aversion for religious fanatics and whatever they try to push on you.
    I use Agile instead of XP until I know that a person isn't put off by the term Extreme Programming.
    ..also, some fanatics might label me an "unbeliever" because I use whatever I find is useful to the context (usually 80-95%) rather than everything, which you apparently must do to be admitted in the paradise which is Agile-heaven.
    I wouldn't use "unbeliever", I'd use "pragmatic". There have been debates about whether a team could say it's using XP if it doesn't 'do' all of the practices. The initial cause for the debate stemmed from teams saying they had 'done XP and failed', when in fact they had simply dispensed with documentation and threw together code as quickly as possible. The natural reaction was, "They're not doing XP!" This evolved into a debate on what the threshold was for 'doing XP', and some zealots did claim that you had to do all of the practices. 100% is a laudable goal, but it isn't always achievable. I'm curious, when you say 80-95%, what do you typically leave out? Dave Rooney Mayford Technologies
  18. Re: Common Sense vs. Dogma[ Go to top ]

    I do indeed have a vested interest in flogging agile training and coaching services, but I do not and never will say to a potential client
    Well, there's a difference between having a commercial interest, and a "quick buck"-interest. Having a long term commercial interest in something means that you will do best by having your clients best interests at heart, not your own short term interests. But there's the opposite which I despise, the quick buck artists out to make money of a fad (hold on for "carbon offset consultants"!).
    I'm curious, when you say 80-95%, what do you typically leave out?
    Unsurprisingly, pair-programming is a hard sell most of the time. I appreciate the value of "real-time" code review and the avoidance of the temptation of writing quick and dirty shoddy code that never gets fixed, but nonetheless a lot of people aren't comfortable with pair-programming even if they are great developers and communicators. A lot of the time I feel once you know someones level, it is enough to just have a quick look at their CVS-commits (and the depth of that look depending on your trust in the person). Also, I'm quite adamant about TDD most of the time, BUT I am not dogmatic about "test-first". If you do a bit of coding, then a bit of unit-testing I don't mind which comes first as long as it comes together (in other words: no code in CVS without tests, unless it is getters and setters). / Wille Blog: Buzzword Bingo
  19. Re: Common Sense vs. Dogma[ Go to top ]

    Unsurprisingly, pair-programming is a hard sell most of the time. I appreciate the value of "real-time" code review and the avoidance of the temptation of writing quick and dirty shoddy code that never gets fixed, but nonetheless a lot of people aren't comfortable with pair-programming even if they are great developers and communicators.
    Sure, that's fine. On the first project on which I used XP back in 2001, there were only 3 developers and thus we couldn't pair all the time. We were successful, didn't lose our hair, and no Agile Inquisition came to burn us at the stake. ;) I like pairing, and I also like working alone, depending on what I'm doing. I believe that if a team can try pairing for more than a few days (i.e. a couple of iterations or one full release), they'll see some benefits. Having said that, it can indeed be a tough sell and to me it's not the end of the world if a team doesn't pair. Have a look, though, at this article from the U.S. Air Force's Crosstalk magazine in 1996. The section about 2-Person teams was based on research collected from 1975-95, and was performed prior to and completely oblivious to what the Chrysler C3 team were doing.
    A lot of the time I feel once you know someones level, it is enough to just have a quick look at their CVS-commits (and the depth of that look depending on your trust in the person).
    Trust and respect are fundamental values of Agile development. If you don't trust someone, it creates tension that affects the entire team and their productivity. That's not touchy-feely BS, I've watched it happen!
    Also, I'm quite adamant about TDD most of the time, BUT I am not dogmatic about "test-first". If you do a bit of coding, then a bit of unit-testing I don't mind which comes first as long as it comes together (in other words: no code in CVS without tests, unless it is getters and setters).
    Be carefuly not to confuse the intent of 'testing' vs. TDD. Testing is absolutely a good thing, and I do it all the time. However, when I'm in Test-Driven Development mode, I'm not testing, but rather designing. The Test-Code-Refactor cycle could be reworded as Spec-Code-Design, although that implies that there's no up-front thinking about how to build something. It's too bad that the word 'test' was used, and there is a growing Behaviour-Driven Development movement that is trying to rectify the idea that the tests are just tests. Regardless, Wille, based on what you are saying here and in your blog, you're as Agile as anyone I know! Dave Rooney Mayford Technologies
  20. Re: Common Sense vs. Dogma[ Go to top ]

    Trust and respect are fundamental values of Agile development. If you don't trust someone, it creates tension that affects the entire team and their productivity. That's not touchy-feely BS, I've watched it happen!
    Well, I'd say there are two contexts for trust: - Knowing the level of someones ability (a recent graduate may need a bit more hand-holding and oversight than a "guru" with 15 years of experience). - Trust, period. In the context of someone not wanting to be a team-player, obstructing progress or just being plain incompetent. If it is the first, you have to adjust the level of "hand-holding" to a persons skill (if someone is brilliant, it might be them who do most of the hand-holding. Most of the time it is a mutual affair: everyone learns something from everyone). If it is the latter, just boot them off if you can. I'm not much for "touchy-feely" stuff if it means a whole team and project will suffer to spare one person. Better to remove people quickly, like a band-aid, rather than let the infection spread. As for TDD: I understand what you are saying. To me the biggest realization when I started doing TDD about 4-5 years ago was how the design of my code actually improved dramatically. The fact that I produced "tests" for the code eventually turned out to be mostly a happy bi-product as far as I am concerned. / Wille Blog: Buzzword Bingo
  21. The same thing has happened before with RUP, CMMI, Six Sigma to mention a few (although I'd argue that the first two where never particularly useful besides being money-makers for their respective inventors).
    Used in an appropriate context I think RUP and CMMI are very valuable, and so are many of the tools that go along with RUP. What you have to remember is that neither RUP nor CMMI are processes. RUP is more of a process framework and CMMI is a graduated set of practices. Admittedly, RUP and CMMI define a lot of artifacts, and Agilistas would scream that it's all worthless documentation that's just going to sit on a shelf. But I think they exaggerate the requirements and miss the point.
  22. What you have to remember is that neither RUP nor CMMI are processes. RUP is more of a process framework and CMMI is a graduated set of practices.
    Yes.
    Admittedly, RUP and CMMI define a lot of artifacts, and Agilistas would scream that it's all worthless documentation that's just going to sit on a shelf. But I think they exaggerate the requirements and miss the point.
    I don't mind if documentation sits on a shelf if it still has value for the business. A system built in the context of a regulatory requirement for requirements traceability will need that documentation. That's fine. If you examine non-software artifacts based on the value they provide, then it's much easier to decide if an artifact is required. Over time, any team will have some turnover, and thus some form of documentation is required to assist new people in getting up to speed. Documentation in that sense can consist of actual documents, wiki pages, executable tests, or all of the above. From a business perspective, the stories and release plans absolutely have value. You also have to consider the temporal aspect. For example, a requirements document is obsolete the day after it's completed. It may not change much, but generally it does. Similarly, design specs are a snapshot of what we knew at a particular point in time. They do have value, but the cost to maintain them becomes prohibitive over time as a system grows. I prefer to have many mini-specs that have a very specific context and a point in time at which they were applied. I also like to have a higher-level overall picture of a system. Many other people who could be considered "Agilistas" feel the same. Nowhere will you find in Agile literature anything that says, "Don't create non-software artifacts". What you will find is that people say, "Software should be the primary artifact, and all other artifacts only serve to assist in developing the software". That doesn't mean that it isn't important to get requirements or do some design, but that they are only a means to an end. Dave Rooney Mayford Technologies
  23. I once got a kick out of writing a "Software Engineering Handbook in 500 words (or less)" that would get you to CMM level 3 if you followed it. Don't be intimidated by the number of pages of a standard or by the number of documents it suggests to create ... it's the spirit within that counts. Not managing requirements because they change is like giving up accounting because there is never enough money.
  24. The two largest Australian banks are adopting Agile. One has been using practices from Scrum and Continuous Integration (and CruiseControl) in a 100+ developers project for a while. The other is using ThoughtWorks consultants for some Web site development using XP and TDD.
  25. Reading articles like that makes my blood boil. It annoys me so much I'm actually posting a comment about it. First of all, your company might as well be fully loaded if that method of development is ever going to work (dont call it agile) - like those australian banks mentioned who dont really care about the costs because lets face it, its our money they are spending and they'll just find a way to recover it - from us customers. :-) Has this guy from Thoughtworst (no pun intended ;-)) ever heard of the word budget? Is he trying to justify funelling money out of companies who are incompetent in this area? Or is he willing to waive/reduce his consulting fee to deliver the right thing? I've had experience working with Thoughtworks developers and as far as development skills are concerned, they are ok - good bunch of people. But when it comes to communication? There's a lot to be desired there. Has anyone raised bugs and assigned it to themselves so they don't get allocated bugs to fix? Interesting practice.
  26. Re: That article there is full o' crap[ Go to top ]

    Reading articles like that makes my blood boil. It annoys me so much I'm actually posting a comment about it.
    The article wasn't written very well, that's for certain.
    Has this guy from Thoughtworst (no pun intended ;-)) ever heard of the word budget?
    The sad part about the content of the article (or lack thereof) is that it doesn't explain how agile methods actually do work quite well when you do have a limited budget. The planning process is done collaboratively, with the Customer/Product Manager/Stakeholders and the development team. Features are identified, broken down into portions small enough to estimate reasonably well by the development people, and they are prioritized by the Customer. If the Customer has, for example, a budget of $500K then you figure out how much the development team and infrastructure to support the product will cost per unit of time, e.g. per week or month. If the infrastructure costs are, say, $100K, that leaves $400K for development. If the team costs $50K per month, then you've got 8 months of 'runway' to work with. You then take the estimates and determine how many features will fit in that 8-month span. The features are chosen highest priority and highest techincal-risk first and scheduled in descending order. If there are too many features to fit within the budget, they are either dropped or the budget has to be revisited. The schedule is further broken down into iterations of 1-3 weeks. At the beginning of every iteration, the team (including the Customer) looks at how much was built during the previous iteration. That helps them determine their velocity, and is used to validate and/or correct their estimates. The entire plan is reviewed in that light to see if it needs to be adjusted. Again, if there are too many features for the time or budget, some may have to be dropped. I have also seen situations where features that were not originally scheduled were added since the team went faster than expected. What this process does is provide constant visibility for the Customer. They know on a weekly basis what's going on and how the product is progressing. It's their freakin' money, so they should know! The development team doesn't hide anything from them, in fact there are many teams that have their progress visible to anyone and everyone on a daily basis. The idea here is that, as Dwight Eisenhower said, "Planning is essential, but the plan is useless". Well, the plan isn't exactly useless, but it means that the planning process is more important. It provides the level of communication required to build the right thing and to build the thing right. With respect to bugs, this is an interesting issue. If you just do iterative, incremental development and delivery as I have described, you will likely slow down over time as the system and thus the testing effort gets larger. Bugs will become more difficult to trace and fix, and regressions will occur. Also, bugs are notoriously difficult to estimate, since "you don't know what you don't know" in most cases. As such, you need to introduce automated testing at the unit level at the very least right at the beginning of the process. Ideally, integration and acceptance testing are automated as well. They provide 'courage' (I actually prefer the term 'confidence') to keep moving forward, and to be able to quickly isolate and fix bugs as they occur and not just during a 'crunch-mode' at the end of development. Does that sound like a process that's trying to gouge Customers? It's actually a much more Customer-friendly process than telling them that the product is "feature-complete", and then spending 3-4 months trying to get all of the bugs out and deciding to ship something with known bugs that you'll fix in a later release... for more money. Dave Rooney Mayford Technologies
  27. If the infrastructure costs are, say, $100K, that leaves $400K for development. If the team costs $50K per month, then you've got 8 months of 'runway' to work with. You then take the estimates and determine how many features will fit in that 8-month span. The features are chosen highest priority and highest techincal-risk first and scheduled in descending order. If there are too many features to fit within the budget, they are either dropped or the budget has to be revisited.
    Are you assuming a level-loaded schedule for simplicity's sake or because you believe it is the best way to work? In the absence of a clearly defined problem with well understood objectives for alleviating the problem through automation, I would not level-load the project. For a $400k project I would probably keep initial staffing at one person (someone with good analytical and communications skills and decent tech skills, commonly known as a "Systems Analyst" or "Business Analyst") to get the problem defined. The analyst could flush out the problem any number of ways, from white boards to UML to mockups to limited prototypes, but the important thing is to ensure the problem to be solved is clearly defined. This all sounds pretty waterfallish, but notice I never used the word "requirements." There are lots of studies out there on how projects failed because of bad requirements, and lots of methodologies out there to address the problem of bad requirements - most of which start with the assumption that initial requirements will be inherently bad and but you won't know how until they start changing or you build something that gets rejected. I bought all this hype until I realized that requirements are bad because people often have no clue what problem they are trying to solve. They think "lack of a web-based workflow for foo process" is a problem. Maybe it isn't. Maybe a web-based workflow is the last thing the foo process needs. Or my personal favorite "we need to web application to give us visibility into bar data." Sounds great except 90% of the time they don't have visibility into bar data because bar data does not exist, and it does not exist because no one finds it useful enough to maintain. Anyway, I digress. The point is there should be some underlying reason why they want to automate foo process or see bar data. They want to reduce cycle time, effort, improve accuracy and/or precision, collect metrics for Six Sigma or some other analysis, capture the data for down-stream use a year after it is actually generated (and forgotten), etc. Once the problem is defined decent requirements usually fall into place. However, having 5 programmers in the room who just want something to code doesn't lead to better problem definition. It leads to partial requirements that may or may not be good and a high burn rate. The customer may be happy during the burn, because he feels tangible progress, but that doesn't make it cost effective. By all means, the details should be flushed out in an agile way. But it's all a waste of money if you don't know what problem you are trying to solve.
  28. Are you assuming a level-loaded schedule for simplicity's sake or because you believe it is the best way to work?

    In the absence of a clearly defined problem with well understood objectives for alleviating the problem through automation, I would not level-load the project.
    Absolutely, I agree. I was making the assumption that the initial high-level business planning activities that you describe had already been done, and was focusing on just the development effort. I was also using the simplest case for the example, where the development team's cost was constant. Dave Rooney Mayford Technologies
  29. I was making the assumption that the initial high-level business planning activities that you describe had already been done, and was focusing on just the development effort.
    When you have a new engagement with a customer, what percentage of the time would you say that these activities have been adequately completed? I would say about 10%. But I'm internal as opposed to a consultant/contractor so I'm involved earlier in the project cycle. The thing is as often as not I see strong resistance among business stakeholders to clearly defining the problem, and I see many projects happening around me where it is never defined.
  30. When you have a new engagement with a customer, what percentage of the time would you say that these activities have been adequately completed?

    I would say about 10%. But I'm internal as opposed to a consultant/contractor so I'm involved earlier in the project cycle.
    For me, probably closer to 50% of the time, since my involvement is typically at the development level, or as a coach to development.
    The thing is as often as not I see strong resistance among business stakeholders to clearly defining the problem, and I see many projects happening around me where it is never defined.
    Sure, I see this too (I've done a lot of work for the public sector :). It's in this environment of unclear definition that an agile approach shines when compared to a waterfall or waterfall-ish implementation of RUP. FWIW, I've also seen agile have its challenges, mainly because the Customer isn't as involved as they should be, or isn't really the right person for the job. To me, that's agile's Achilles heel... actually, it's an issue with any process because if the Customer isn't involved, you're pretty well screwed from the start. Dave Rooney Mayford Technologies
  31. April fools[ Go to top ]

    I think this article was supposed to be published on April 1, but somehow got out earlier. Thanks, Thomas
  32. Re: April fools[ Go to top ]

    I think this article was supposed to be published on April 1, but somehow got out earlier.

    Thanks,

    Thomas
    Darn DST changes!