Doing Agile? Maybe so, maybe not.

Home

News: Doing Agile? Maybe so, maybe not.

  1. Doing Agile? Maybe so, maybe not. (56 messages)

    Hani Suleiman recently "biled" Agile practices recently, which managed to bring out a lot of people defending the methodology. Most pointed out that Agile was a collection of ideas that were to be applied as appropriate, and not commandments. But what, then, makes Agile "Agile?" Let's look at the Rational Unified Process as a contrast. RUP says you've got lots of iterations, tons of artifacts, many different processes to go through, and even software requirements just to use it - or at least that's the general impression of it. However, RUP is a set of possible processes, not a mandated process, where users are supposed to pick and choose what aspects of RUP are appropriate for them.
    If the users of RUP do not understand that RUP is a process framework, they may perceive it as a weighty and expensive process. RUP was not intended, not envisioned and not promoted to be used straight "out of the box".
    So, from actually looking at what RUP does advocate, a pick-and-choose approach to various possible processes - you can see that RUP can be just as "agile" as "Agile," and it's just as strict about what you have to use. Do I defend RUP? Not really. But just as it's a bad idea to dismiss Agile as "cowboy coding," it's wrong to compare it to RUP based on how structured RUP is compared to Agile. Both say you should pick and choose what practices you need. The problem is that people who push the methodologies seem to be trying to be more extreme than they need to be, to show how into their chosen practices they are. As a result, they end up being extremists and fringe leaders rather than real leaders, and they lose the ability to really identify with the masses. Neither Agile nor RUP are bad ideas, except when applied blindly, and that's where the haters and pushers all go wrong.

    Threaded Messages (56)

  2. Re: Doing Agile? Maybe so, maybe not.[ Go to top ]

    I wrote a blog-post on this very subject in the last 24h. However, in short, I think there are a couple of main problems with the whole debate: - Agile has been hijacked by a bunch of religious fanatics and snake-oil salesmen ("Agile consultancies"), selling it as the next Silver Bullet(tm). - Critics of Agile methodologies (in part rightly) attack the notion of Agile being a silver bullet and the religious fervour arround the practices as portrayed by the fanatics, but erroneously believe that it is actually supposed to be a silver bullet as mandated by the religious fanatics, and critisize the whole thing for that particular reason. No methodology is a silver bullet, and no process or methodology should be adhered to with religious fervour if it is not appropriate for the circumstances of the project. Furthermore, no methodology or process will magically make human brain-activity superfluous. At the end of the day, it's what people achieve that counts, not what a particular method or process mandated.
  3. Re: Doing Agile? Maybe so, maybe not.[ Go to top ]

    The problem if you don't have these "extremists" who try to push and sell the methodology, then you won't have the discipline to implement a truly revolutionary process. If you take a "pick and choose", casual approach, you most likely will not have the discipline to make it successful. For example, I wouldn't have tried pair programming, unless it was forced on me. The notion seemed ridiculous. But now I'm very glad we've done it - the sharing of knowledge is well worth it, and everything they say about it being productive is true.
  4. Re: Doing Agile? Maybe so, maybe not.[ Go to top ]

    The problem if you don't have these "extremists" who try to push and sell the methodology, then you won't have the discipline to implement a truly revolutionary process.
    "Agile" methodologies aren't exactly revolutionary. Their common-sensical, and have been around for almost 40 years. The only thing that has happened in recent years is that they have become more formalized under one umbrella through the Agile manifesto etc.
    If you take a "pick and choose", casual approach, you most likely will not have the discipline to make it successful.
    There's a definite difference between doing casual "pick and choose", as opposed to being disciplined, but doing what works under the circumstances. That's one of the problems with the "extremists": they can't differentiate between those two concepts. It's all or nothing, all the time, otherwise you are being "undisciplined and casual".
  5. Re: Doing Agile? Maybe so, maybe not.[ Go to top ]

    The problem if you don't have these "extremists" who try to push and sell the methodology, then you won't have the discipline to implement a truly revolutionary process.
    You know, this kind of statement is exactly what makes people wary about agile. Why is it revolutionary? Just because people say so? So far, Agile, as described in the manifesto, has completely failed to prove that it even works, much less works better than what we had before. Instead, what I see around me is people cherry-picking some of the ideas and applying them to their project in ways that make sense: Emphasis on testing? Yes. Test-driven design? Sometimes. Pair-programming? No. Not only does *this* approach make sense to me, it strikes me as being much more agile than anything that the agile thought leaders are trying to push down our throats. -- Cedric
  6. So far, Agile, as described in the manifesto, has completely failed to prove that it even works, much less works better than what we had before.
    Interestingly enough, I was attending an ITMPI conference yesterday and David Garmus, from the David Consulting Group, showed some numbers about productivity improvements from traditional waterfall models and agile models. Here are the numbers (copyright David Consulting Group) for small projects (<200 FP if I recall properly), in h/FP: MainFrame 8.1 h/FP traditional, 7.0 h/FP agile Web (grab & display) 4.8 - 3.2 e-Business (web trans.) 6.6 - 5.8 Their database has over 8000 projects (IIRC) and around 10% were implemented with agile methodologies (again, IIRC). Not to say that this is gospel, obviously, but I thought there were interesting numbers.
  7. Re: Doing Agile? Maybe so, maybe not.[ Go to top ]

    Instead, what I see around me is people cherry-picking some of the ideas and applying them to their project in ways that make sense: Emphasis on testing? Yes. Test-driven design? Sometimes. Pair-programming? No.

    Not only does *this* approach make sense to me, it strikes me as being much more agile than anything that the agile thought leaders are trying to push down our throats.

    --
    Cedric
    I thought this was what agile was all about. If you have no choice over the matter, by definition, it is no longer agile. Pick what works for you, your team, your client, your organization. I never agreed with pair programming either, but I was not overly concerned if someone used it anyway - it might suit them, but not me.
  8. Re: Doing Agile? Maybe so, maybe not.[ Go to top ]

    Instead, what I see around me is people cherry-picking some of the ideas and applying them to their project in ways that make sense: Emphasis on testing? Yes. Test-driven design? Sometimes. Pair-programming? No.

    Not only does *this* approach make sense to me, it strikes me as being much more agile than anything that the agile thought leaders are trying to push down our throats.

    --
    Cedric


    I thought this was what agile was all about. If you have no choice over the matter, by definition, it is no longer agile. Pick what works for you, your team, your client, your organization. I never agreed with pair programming either, but I was not overly concerned if someone used it anyway - it might suit them, but not me.
    You would think that, but then go on comp.software.extreme-programming (which I assume encompasses Agile), and you'll see how dogmatic some of these people are. But I guess that just goes to the general notion of people getting pissed because you're not drinking the kool-aid their offering.
  9. Re: Doing Agile? Maybe so, maybe not.[ Go to top ]

    Why is it revolutionary? Just because people say so?

    So far, Agile, as described in the manifesto, has completely failed to prove that it even works, much less works better than what we had before.
    Cedric, that's absolute crap. If it weren't working, why are companies such as Google jumping aboard? Anyone who has bothered to do 5 minutes of research knows that Agile, XP in particular, is based on practices that have worked since the dawn of computer programming. The difference is how they are being used together. You also can't just "do the practices" - there's an entire mind-set involved with Agile. This is what Kent Beck described as the Values of XP, and what the Agile Manifesto put into words. Let me ask you this... would TestNG have any following at all if it weren't for the renewed focus on testing that began with XP? Dave Rooney
  10. Why is it revolutionary? Just because people say so?

    So far, Agile, as described in the manifesto, has completely failed to prove that it even works, much less works better than what we had before.


    Cedric, that's absolute crap. If it weren't working, why are companies such as Google jumping aboard?

    Anyone who has bothered to do 5 minutes of research knows that Agile, XP in particular, is based on practices that have worked since the dawn of computer programming. The difference is how they are being used together. You also can't just "do the practices" - there's an entire mind-set involved with Agile. This is what Kent Beck described as the Values of XP, and what the Agile Manifesto put into words.

    Let me ask you this... would TestNG have any following at all if it weren't for the renewed focus on testing that began with XP?

    Dave Rooney
    Hi Dave, I'm an Agile advocate, and I think that there is substance to the backlash currently occurring against Agile. Like you say, in XP Kent Beck says that you should be guided by the XP values, and when in doubt inspect and adapt (extend/replace) the XP practices to meet your specific needs. In practice though, XP is often "sold" as an all or nothing bag. You need to use all the XP practices as they reinforce each other. Yet in XP explained Edition II Kent goes on to add a bunch of new practices. So what happened to the original "all-or-nothing" set? Certain "Agile" consultancies have gone on to perpetuate the idea that there is "ONE TRUTH" by imposing practices upon organisations irrespective of the incumbent corporate culture and whether these practices are appropriate. So you end up with alien practices in a culture void of the required values. I really feel we need to move away from the idea that “we” (the Agile Community) have all the answers. Manifestly we do not. Perception is important and I believe we are getting honest and open feedback. IMO the perception amongst many unfamiliar with the roots of Agile Software Development is that Agile is about the religious adherence to a set of specific development practices, and this is what they see as the Agile "mind-set" you speak of. What is a useful discussion IMO is how this perception has come about, and what can be done to correct it? Paul.
  11. Hi Dave,

    I'm an Agile advocate, and I think that there is substance to the backlash currently occurring against Agile. Like you say, in XP Kent Beck says that you should be guided by the XP values, and when in doubt inspect and adapt (extend/replace) the XP practices to meet your specific needs.

    In practice though, XP is often "sold" as an all or nothing bag.
    Hi Paul, Even in XP Explained 1st Edition, Beck spoke of how to introduce XP practices piecemeal if you can't introduce them all at once. The caveat is given that it's best to use all of the practices. As for the backlash, I'm all for constructive criticism. If Cedric and others didn't say things such as "there's no proof that it works", I'd be a hell of a lot more likely to listen. Perhaps if they said that 5 years ago, but not now. Who is 'selling' agile as all or nothing? I want to know so that I can work to correct that impression at the source. The RUP as defined and practiced by people such as Philippe Kruchten, Grady Booch and Ivar Jacobsen can be as agile as any process. What happened, IME, is that the salespeople were selling the toolset rather than the process. As a result, they gave the impression that all of the artifacts were required, as supported by their tools, and the result is that I hear very little demand for people with RUP experience these days. If companies are doing that to Agile, I want to know who. Can you give me any examples?
    I really feel we need to move away from the idea that “we” (the Agile Community) have all the answers. Manifestly we do not.
    I couldn't agree more!! Agile development, even XP is considerably different from what I first found and experienced in late 2000. It has evolved somewhat as people have gained more experience using the process. I believe it has improved.
    Perception is important and I believe we are getting honest and open feedback. IMO the perception amongst many unfamiliar with the roots of Agile Software Development is that Agile is about the religious adherence to a set of specific development practices, and this is what they see as the Agile "mind-set" you speak of. What is a useful discussion IMO is how this perception has come about, and what can be done to correct it?
    Honestly, I've been fighting for 5 years with the perception that XP is all about Pair Programming. As someone on the XP Yahoo Group said, we must be making progress because people now attribute both Pair Programming and TDD to XP. :) Am I a zealot, fanatically hanging to the XP practices? Absolutely not. I'll use what I can when I can, but the more practices that I can use the better. I will, however, explain why each of the practices are good and why they work together. With Pair Programming and TDD, I'm essentially trying to undo 60 years of how people have been taught to develop software. The message I'm trying to impart, though, is XP/Agile is the best way in 18 years of professional experience that I have experienced for delivering high-quality software at a predictable and visible pace. That isn't a silver bullet, but it may just be chrome plated. Dave Rooney
  12. Hi Dave,
    Who is 'selling' agile as all or nothing? I want to know so that I can work to correct that impression at the source.
    Well I've come across several "Thoughworks" XP installations where the client was sold XP, and where I see very little evidence of an understanding of what Agile development is all about.
    The message I'm trying to impart, though, is XP/Agile is the best way in 18 years of professional experience that I have experienced for delivering high-quality software at a predictable and visible pace.
    I'm trying to convey the same message, yet the perception I described exists and is wide spread. I believe that we need to work on our presentation. In truth, where XP or Agile is successful, the success is mainly due to the skills and ingenuity of the people involved, likewise over the many years that I delivered "Waterfall" projects our successes (they did happen) where also mainly due the skills and ingenuity of the people involved. Waterfall can be successful, and in truth most experienced developers already iterate to some degree informally anyway. So "Agile" development in various home grown forms as been around a lot longer than XP. We need to be very careful how we use language and the power we associate with labels. Agile is great as a marketing term, Consultancies like Thoughtworks have used it to great success, but in the long term no one is going to be fooled by a label, what will count is results (or the lack of results). In the words of Hayawaka : The label is not the thing. The Map is not the Territory, and Agile is not (necessarilly) successful Software Development. Paul.
  13. With Pair Programming and TDD, I'm essentially trying to undo 60 years of how people have been taught to develop software.
    Good luck with that. Based on my own real-life experiences where I saw many attempts (to do what you're describing above) fail,I would personnally question the following ideas: - Pair Programming is actually effective - You need to do TDD to be "agile" - the more XP practices you implement the better it is In many cases, doing iterative development along with SOME testing (80/20 rule) is "good enough"... ..That is, if being "agile" still means being able to respond to change more effectively. And in real life, if you can be successful only in implementing those little changes I just described, you're really a lucky guy.
  14. With Pair Programming and TDD, I'm essentially trying to undo 60 years of how people have been taught to develop software.


    Good luck with that.

    Based on my own real-life experiences where I saw many attempts (to do what you're describing above) fail,I would personnally question the following ideas:

    - Pair Programming is actually effective
    - You need to do TDD to be "agile"
    - the more XP practices you implement the better it is

    In many cases, doing iterative development along with SOME testing (80/20 rule) is "good enough"...

    ..That is, if being "agile" still means being able to respond to change more effectively.

    And in real life, if you can be successful only in implementing those little changes I just described, you're really a lucky guy.
    +1 This is what I've been trying to say, but more elequently put. <href="http: alistair.cockburn.us="" ndex.php="" ain_pagealistair"=""> Cockburn calls it doing enough to get into the "Safety Zone" (success zone). In my experience, proper iterations with good communication between the business and developers and a shared understanding of what it means to inspect and adapt. And continuous process improvement through effective retrospectives is good enough for most. If teams could learn to do just these two things well then they stand to gain massive improvements IMO. My view is that the enthusiasm of some of the XP crowd is partly responsible for the negative perception of Agile that exists amongst some. You can introduce a bunch of shiny new technical practices in a very short period of time, but deep understanding and cultural change can take a lot longer. It is like buying a new sports car and attaching L (Learner) plates. You may fine out that perhaps you would have been better off if you had bought yourself a Mini instead :^). Paul.</href="http:>
  15. Fixed link:
    With Pair Programming and TDD, I'm essentially trying to undo 60 years of how people have been taught to develop software.


    Good luck with that.

    Based on my own real-life experiences where I saw many attempts (to do what you're describing above) fail,I would personnally question the following ideas:

    - Pair Programming is actually effective
    - You need to do TDD to be "agile"
    - the more XP practices you implement the better it is

    In many cases, doing iterative development along with SOME testing (80/20 rule) is "good enough"...

    ..That is, if being "agile" still means being able to respond to change more effectively.

    And in real life, if you can be successful only in implementing those little changes I just described, you're really a lucky guy.
    +1 This is what I've been trying to say, but more elequently put. Alistair Cockburn calls it doing enough to get into the "Safety Zone" (success zone). In my experience, proper iterations with good communication between the business and developers and a shared understanding of what it means to inspect and adapt. And continuous process improvement through effective retrospectives is good enough for most. If teams could learn to do just these two things well then they stand to gain massive improvements IMO. My view is that the enthusiasm of some of the XP crowd is partly responsible for the negative perception of Agile that exists amongst some. You can introduce a bunch of shiny new technical practices in a very short period of time, but deep understanding and cultural change can take a lot longer. It is like buying a new sports car and attaching L (Learner) plates. You may fine out that perhaps you would have been better off if you had bought yourself a Mini instead :^). Paul.
  16. In my experience, proper iterations with good communication between the business and developers and a shared understanding of what it means to inspect and adapt.
    If by proper iterations you mean time-boxed with fixed scope within the iteration but variable scope within the release, I agree wholeheartedly. One of the "that could never work" complaints I've heard is about variable scope. "That will lead to churn!" I would agree with that if the scope within an iteration is allowed to change. However, if you keep the iterations short (1-3 weeks, preferably 1), then it's easy to keep the scope fixed. If the Customer wants a change, it's easy to say (and they are quite willing to accept) that if it's a high enough priority you'll get to it next iteration. You then ask what they'd like to bump out of that iteration to make room. If the Customer isn't willing to do that, then subscribe to the xp-jobs Yahoo Group and have a look at the ever-growing list of jobs that specifically require people with skills in Agile processes! :) Actually, good, continuous communication between the business and the developers would improve any process! Agile just makes it a first order requirement.
    And continuous process improvement through effective retrospectives is good enough for most.

    If teams could learn to do just these two things well then they stand to gain massive improvements IMO.
    Yes. You have to be willing to look at what you do well and what you need to improve in order to actually improve!
    My view is that the enthusiasm of some of the XP crowd is partly responsible for the negative perception of Agile that exists amongst some. You can introduce a bunch of shiny new technical practices in a very short period of time, but deep understanding and cultural change can take a lot longer.
    Fair enough, with regards to culture. However, the practices aren't shiny and new. Iterative, test-driven development was used in 1958 in the Mercury Space Program! I don't know who is saying that the practices are new... no one I know in the Agile movement is saying that. What we're saying is that these recognized good practices are combined and turned up to 11.
    It is like buying a new sports car and attaching L (Learner) plates. You may fine out that perhaps you would have been better off if you had bought yourself a Mini instead :^).

    Paul.
    :) Though I've seen some people drive the new Mini Cooper's as if they were sports cars! Dave Rooney
  17. Fair enough, with regards to culture. However, the practices aren't shiny and new. Iterative, test-driven development was used in 1958 in the Mercury Space Program! I don't know who is saying that the practices are new... no one I know in the Agile movement is saying that. What we're saying is that these recognized good practices are combined and turned up to 11.
    Hi Dave, This is exactly the problem. Many of theXP practices are totally new to many teams, although like you say most of them have been used by others for years. The other problem IMO is always turning the volume up to 11. Why? There is a people element to all of this and different teams can absorb change at different rtes. XP with the volume turned right up, may work well for Kent Beck, Ron Jefferies and the C2 project team, but that doesn't mean that is is going to work well for everyone else. Each teams has it's one unique mix of experience, skills, preferences, etc, and of course every organisation and project is unique. I think it is the implicit assumption that what works best for Kent Beck should work best for everyone else is what puts peoples backs up I think, and can come across as being arrogant. This is why I much prefer Alistairs Cockburns tone when it comes to detailed technical practices and his idea of allowing teams to take on board just enough change to ensure project success. I also agree with Alistairs' idea that the practices need to be habitable for the people involved (e.g. side-by-side programming versus pair-programming, etc). Paul.
  18. I think it is the implicit assumption that what works best for Kent Beck should work best for everyone else is what puts peoples backs up I think, and can come across as being arrogant.
    It's perfectly understandable. Kent is a brilliant guy; he and his brilliant friends don't want to have to jump through the hoops of formal processes ("projects for dummies"), and they are brilliant enough to not have to. I am willing to accept (on faith!) that Agile works for Kent and other brilliant people like him. I am [personally] more curious how well agile works in "brilliant" teams versus how well it works in "good", "mediocre" and "pathetic" teams. Most teams, assuming Bell drew his curves correctly, fall into the mediocre category. Peace, Cameron Purdy Tangosol Coherence: Clustered Shared Memory for Java
  19. Hi Guys,
    It's perfectly understandable. Kent is a brilliant guy; he and his brilliant friends don't want to have to jump through the hoops of formal processes ("projects for dummies"), and they are brilliant enough to not have to. I am willing to accept (on faith!) that Agile works for Kent and other brilliant people like him.
    We seem to be using references to XP and Agile interchangeably. When most people talk of Agile what they really mean is XP. Agile is much wider then XP, what about Scrum, Crystal Clear, Crystal Orange, Adaptive Software Development, DSDM, FDD, Lean Software Development and permitations of all the proceeding? As an Agile Advocate I have my difficulties with some parts of the XP community to, but I also realise that XP and extremism doesn't represent the entire Agile community. In a sense XP stands quite unique from the majority of Agile Metholdogoes which tend to stress management practices more than development practices. Kent Beck with XP, has been very succesful at Marketing, but we should not let it skew the debate. I think the reason why it often does is because Agility tends to be introduced bottom-up, first being introduced to programmers who latch on to developer practices and often miss the bigger picture. People with managment experience tend to see Scrum as more important and fundamental then the XP developer practices. In fact most of the Agile writing (Alistair Cockburn, Mary/Tom Poppendiek, Jim Highsmith, Ken Schwaber etc) are non-specific and provide the reader with a toolkit of practices to choose from. Cedric, What issue do you have with the Agile Manifesto? Looking at it today, I can conceed that it could probably do with re-drafting, mostly due to improvements in our understanding since it was first written, but the values and principles within it still seem sound and relevent to me. Paul.
  20. I am willing to accept (on faith!) that Agile works for Kent and other brilliant people like him.
    As I recall, the "Chrysler Comprehensive Compensation" (C3) project, guided by Kent Beck, Ron Jeffries, and Fowler, which was supposed to make XP prove itself, was a failure. AFAIK, only 1/3 of the project was completed in 4 years, and it was finally cancelled. So much for "brillant" people trying their concepts in the real world. Of course, the XPers claimed that it was the customer's fault, not the methodology. Hence to this date the XP cult lives on.
  21. I think it is the implicit assumption that what works best for Kent Beck should work best for everyone else is what puts peoples backs up I think, and can come across as being arrogant.


    It's perfectly understandable. Kent is a brilliant guy; he and his brilliant friends don't want to have to jump through the hoops of formal processes ("projects for dummies"), and they are brilliant enough to not have to. I am willing to accept (on faith!) that Agile works for Kent and other brilliant people like him.

    I am [personally] more curious how well agile works in "brilliant" teams versus how well it works in "good", "mediocre" and "pathetic" teams. Most teams, assuming Bell drew his curves correctly, fall into the mediocre category.

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
    Fantastic discussion - kudos to all One aspect that maybe gets ignored (IMHO) is consistency of implementations. Despite all the tooling and assistive technologies (checkstyle, patterns ;-), reference architectures etc...), in "normal" large teams, the "bell" curve is unavoidable. So, I believe, the fundamental aim is 2 fold 1 - shift that curve to the right (assuming right is good) !! (use whatever metric you like (Fp/hour, lines/Fp, bug rate etc) 2 - narrow that curve. The more narrow the bell curve, the more predictable are the characteristics of the implementation. I'm not sure whether the more "agile" methodologies allow for a "wider" curve, and whether the more proscriptive approaches work to narrowing that curve. Of course, ultimately in comes down to people and organisational culture.
  22. Re: Doing Agile? Maybe so, maybe not.[ Go to top ]

    Dave, Let's take the debate toward a more constructive direction. Here is a simple scenario: imagine you are brought in as an Agile consultant in a company with a team of ten developers, and after you have explained what the Agile philosophy is, seven of them tell you "Fine, but I don't want to do pair programming". What would you do? Then five of them tell you "I agree with the emphasis on testing, but I don't see the point in testing first, so I'll just write my code first, like I've always done. I'll be writing tests, don't worry, but they'll come second". Again, what would you do? And then, the team lead comes to you and tells you "I understand the value of code coverage, but honestly, I don't see the point in having 100% coverage, so we'll just shoot for 70-80%". How would you react to that? -- Cedric curious
  23. Re: Doing Agile? Maybe so, maybe not.[ Go to top ]

    Dave,

    Let's take the debate toward a more constructive direction.
    OK, this I can work with.
    Here is a simple scenario: imagine you are brought in as an Agile consultant in a company with a team of ten developers, and after you have explained what the Agile philosophy is, seven of them tell you "Fine, but I don't want to do pair programming".

    What would you do?
    I'd have them burned at the stake for heresy. (Just kidding.) That's fine. I'd want to know what their objections are and why, and come to a common understanding. I'd point out to them that there are risks involved with not pairing, as well as risks that you incur when you do indeed pair. If, after weighing the risks, the team's consensus is to not pair then fine. So be it. I would further recommend that they use some form of peer review, such as an open-source model or simple peer committing after a quick review.
    Then five of them tell you "I agree with the emphasis on testing, but I don't see the point in testing first, so I'll just write my code first, like I've always done. I'll be writing tests, don't worry, but they'll come second". Again, what would you do?
    Are the tests written before the code is committed? If not, then I'd say that's a huge risk. If they are written after the code, but before committing I could live with it. Similarly, is Refactoring performed after the code is written? If the answer again is yes, then I'm happy that they have tested, refactored code that is clean before it hits the repository. However, I'd ask them to review code written test-first and test-after side-by-side after a couple of iterations. There would likely be a significant difference in terms of the simplicity of the design of the code written the two ways (at least my experience has been that the difference is like night and day).
    And then, the team lead comes to you and tells you "I understand the value of code coverage, but honestly, I don't see the point in having 100% coverage, so we'll just shoot for 70-80%".

    How would you react to that?
    I'd first ask what their current level of test coverage is. If it's below 70-80%, then I'd be quite happy with getting the team to that level. Cedric, I agree that there are places where it's practically impossible to get to 100% coverage in an efficient manner. It's also practically impossible to bring existing code without tests to 100% coverage. A better way of saying that is that it isn't necessarily cost-effective to do so. However, I have experienced that it's a slippery slope when people are given the choice to test or not to test. They fall off the wagon very quickly when they encounter something they perceive as difficult to test. In a large majority of cases that I've encountered, things are difficult to test because they were built without tests and thus weren't a very clean, cohesive, decoupled design. Things such as multiple threads, database interaction, EJB's, HTTP or other network calls, etc. are difficult or expensive to test. To me, that's a given. However, it's not that difficult to isolate the places in a system where those difficult-to-test interactions are taking place. That isn't TDD or Agile... that's just good O-O design. So, to sum all of this up, from the questions you asked me I think that we're actually not as far apart as we may think on what constitutes good development practices. XP has worked well for me, although I've had to adapt at times to situations where the Customer isn't co-located, we didn't have a common team room, and we weren't pairing all the time. I have never said that "you have to do those practices". What I have said is "these practices are good, and you should try them". There's a big difference there. In the end, my goal is to reduce the obscene amount of money wasted on software development projects. Right now, XP in particular and Agile methods in general are the best way I know of to do that. That isn't to say that in 5 years something will come along that will be better, in fact something probably will. I suspect that it will borrow heavily from what's currently known as Agile. Dave Rooney
  24. Hi Dave,
    In the end, my goal is to reduce the obscene amount of money wasted on software development projects. Right now, XP in particular and Agile methods in general are the best way I know of to do that. That isn't to say that in 5 years something will come along that will be better, in fact something probably will. I suspect that it will borrow heavily from what's currently known as Agile. Dave Rooney
    +1 Well said. Infact your whole post was well reasoned and well argued. This just proves that this labelling: "Agile", "non-Agile" is just plain stupid. What matters is the skill and ability of the practioners, you obviously have ample amounts of each. Paul.
  25. Not sure how many posts are from hapless developers who are trying to balance their professional and personal lives. The 'Agile' process seems to be a very sensible way to us who work 80 hours a week. We really need a coach and short iterations. We need to do only what we can in a day. The agile process respects the developers and treats them as humans. Mohan
  26. Not sure how many posts are from hapless developers who are trying to balance their professional and personal lives. The 'Agile' process seems to be a very sensible way to us who work 80 hours a week.

    We really need a coach and short iterations. We need to do only what we can in a day. The agile process respects the developers and treats them as humans.

    Mohan
    Hi Mohan, I've tried to accept the feedback from those with issues with Agile as "open honest feedback", but I'm becomming of the opnion that it just boils down to people not wanting to be told. Agile (especially XP) does do a lot of telling. But if you are to learn, then you do need to suspend judgement for a while and listen. With time, and patience you could learn something! Dave Roomeys' recent post reminded me, that there are reasons why skilled practioners like Kent Beck do what they do. As you point out, no one should have to work an 80 hour week, yet the debate about Agile never seems to address the values and principles. Instead we never seem to get past "pair_programming is evil". I guess some people just can't be helped. Paul.
  27. Agile (especially XP) does do a lot of telling. But if you are to learn, then you do need to suspend judgement for a while and listen. With time, and patience you could learn something!
    Hi Paul, I like your notion of suspending disbelief. Here's a story: I found out about XP when I was working on the framework for what was to be a big-honking Java application back in late 2000. I had been on a semi-death march project as a Sr. PowerBuilder developer for 2.5 years, and was looking for a change. I was interviewed for a contract, and it wasn't until about 1/2 way through the interview that I realized that it was for a Java developer/designer! I told the manager interviewing me that I had only played with Java for about 6 months at the time and really wasn't ready to be working as a Java consultant. Her response was that they were more interested in my OO skills, and that I could learn Java as I went along. Being a rather pragmatic sort, I wasn't about to balk at the chance to actually get paid to learn the language! I figure that their attitude was partly owing to the boom of the time, when high-tech companies were hiring anyone who could drink Java and fog a mirror. Also, I would be working with another consultant who had about 3 years Java experience, which was quite substantial at the time. We started working on some of the core services that the framework would provide. We did some design work in Rose on his workstation, then decided to write some code to validate the design. Since I was still a relative Java newbie, I asked to do the driving while my colleague guided me to make sure I didn't screw up. We did that for an hour or so, and the code we wrote told us that we needed to refine the design somewhat. So, we switched back to his machine and did some more design. We then updated the code to the design. My colleague then said, "Hey, this is like that Extreme Programming thing I heard about." I had visions of Mountain Dew-swilling snowboarders with laptops, but a quick internet search yielded some intriguing results. We went to a bookstore that day at lunch - he purchased XP Explained by Beck, and I got XP Installed by Jeffries, Hendrickson and Anderson. After reading for a very short time, we both agreed that this was the way we wanted to build software from now on. The practices, to us, just made sense. After all, we had used almost all of them before at various times in our careers. The only really new practice was Pair Programming. However, we were actually doing it at the time we found out about it! I have often wondered if I would have been as receptive to Pair Programming if I hadn't been already doing it. I'm really not sure. The point of all this is that most of the XP practices seemed like common sense. Pair programming had already worked well for my colleague and I, so we didn't need to suspend disbelief in order to see its benefits. Moving from writing tests to true TDD took a bit of time, but I have found it to be far more effective than working in the debugger, or writing tests after the fact. It was somewhat counterintuitive at first, but I did suspend disbelief in that case. Dave Rooney
  28. hi Dave,
    The point of all this is that most of the XP practices seemed like common sense. Pair programming had already worked well for my colleague and I, so we didn't need to suspend disbelief in order to see its benefits. Moving from writing tests to true TDD took a bit of time, but I have found it to be far more effective than working in the debugger, or writing tests after the fact. It was somewhat counterintuitive at first, but I did suspend disbelief in that case.
    Your experience mirrors mine, it's uncanny. I was orignally very sceptical. We had what you could call a "dead fish" project, you know loads still left to do, and no time and the management brought in ThoughtWorks to save the day! Well I knew that the day couldn't be saved, and was skeptical of anyone who suggested it could. I had done some XP practices, but I had never seen it work the whole XP process, live, end-to-end. Rweading through the book made sense to me to. It mirrored much of what I had picked up through practical experience over the years. The bit that was new though was the "no design". What do you mean you can just code? I could imediately see the power of TDD even though it took me a good 6 months to get use to it, but initially I couldn't see how refactoring and TDD could solve designining in the large. Our Agile coach was well qualified (Ivan Moore, you probably know him), and we all suspended judgement as Ivan the teacher taught us. In a short space of time Ivan had convinced me that we were learning something special, but I still had my doubts over design. Ivan suggested that I read Domain Driven Design by Evans - I did, but I still didn't get it. I suspended dis-belief and just kept going. Ivan was replaced later by Rachel Davies (how lucky can a guy be :^))and over time it dawned on me that the architecture and the macro design was emerging. Also it was better than anything we could have done up front because it implicitly met the requirements, and was void of complexities introduced becuase we felt we needed it (YAGNI). I, like you often wonder whether I would ever have been convinced that emergent design could ever be better then big up front UML design. I'm sure that without Ivan and Rachel and that experience, I would be on the other side of this debate. BTW the project was still finally cancelled, scope too large, buget too small. But even though I knew this all along, XP allowed the team to present a data driven argument before management. Something we could never do before. I still keep in touch with many on that team, with most going on to apply XP successfully themselves. I've become and Agile Coach! Paul.
  29. Dave,

    Let's take the debate toward a more constructive direction.

    Here is a simple scenario: imagine you are brought in as an Agile consultant in a company with a team of ten developers, and after you have explained what the Agile philosophy is, seven of them tell you "Fine, but I don't want to do pair programming".

    What would you do?

    Then five of them tell you "I agree with the emphasis on testing, but I don't see the point in testing first, so I'll just write my code first, like I've always done. I'll be writing tests, don't worry, but they'll come second".

    Again, what would you do?

    And then, the team lead comes to you and tells you "I understand the value of code coverage, but honestly, I don't see the point in having 100% coverage, so we'll just shoot for 70-80%".

    How would you react to that?

    --
    Cedric
    curious
    Let´s imagine yet another simple scenario. You go to a doctor because you feel sick. He tells you that, after years of heavy boozing, your liver is similar to a hamburger with pickles on top and you need either a transplant or a coffin. You say: "Well, doc, I don't want a new liver. I am scared of operations, just give me some medicine.". What should be the doctor's reaction? 1) "Ok, customer! Looks like the transplant is just not for you. I will figure something else and don't worry, you will be fine!" OR 2) "You need a transplant or you have an 90% chance of dying in less than 2 months. If you want (and that´s pretty normal), you can look for a second oppinion."
  30. Re: Doing Agile? Maybe so, maybe not.[ Go to top ]

    Hi Dave,
    I'm all for constructive criticism. If Cedric and others didn't say things such as "there's no proof that it works", I'd be a hell of a lot more likely to listen.
    Well, a good start would be to show projects that have followed the Manifesto to the letter and succeeded. Until I see that, I stand by what I said, which is: projects should cherry pick some of the ideas that they think will work best for them, and Agilists should stop getting red in the face when such a thing happens. As for constructive criticism, I think I have done my share of documenting everything that I thought needed to be removed, fixed or altered in the Agile philosophy in many places (one of them being here). You know, I'm a simple guy, really. I don't have any financial interest in the success or failure of Agile (as opposed to most of its proponents, by the way). I don't hate or love things just based on their name or who authored them. I look at them, and if they make sense, are pragmatic and can be applied in the real world, I'll be the first one to come to the front line and defend them. And so far, Agile *as described in the Manifesto* has failed to prove itself. It hasn't been embraced from a grassroot standpoint, so we're now seeing seminars, coaches and highly-paid consultants trying to convince you to hire them so they can "educate" you. And frankly, it scares me.
    Who is 'selling' agile as all or nothing? I want to know so that I can work to correct that impression at the source.
    Just subscribe to the extremeprogramming, junit and tdd mailing-lists and you'll see for yourself.
    I really feel we need to move away from the idea that “we” (the Agile Community) have all the answers. Manifestly we do not.
    couldn't agree more!! Agile development, even XP is considerably different from what I first found and experienced in late 2000. It has evolved somewhat as people have gained more experience using the process. I believe it has improved.
    Then why is it so hard for you to accept that maybe, just maybe, some of the points emphasized in the Agile manifesto just don't work? Or only work in certain specific situations?
    The message I'm trying to impart, though, is XP/Agile is the best way in 18 years of professional experience that I have experienced for delivering high-quality software at a predictable and visible pace.
    And now you're back with the religious rhetoric... Do you see why such statements make so many people immediately skeptical? -- Cedric TestNG
  31. Well, a good start would be to show projects that have followed the Manifesto to the letter and succeeded.
    I guess you passed up on the numbers I posted above.
  32. Give a highly motivated, clever team, with experience any methodology, and you will get working software which can be proved to be working. Remove the motivation, or the cleverness, or the experience and you are going to (probably) fail. Hiring in well paid coaches/mentors/managers/coders will increase the : motivation, cleverness, experience. Each new wave of methodologies is good, as it forces people to pay attention to their chosen craft again. I do not believe Agile is anything new or special, it is an amorphous collection of thoughts and behaviours - in exactly the same way that RUP is (still hate rose though). Even Booch, schlear mellor, rumbough etc had iterations and feed back. If you look hard enough you can see pretty much the same stuff in every methodology, after all they all want the software to work. Make sure the users want what you write, can be shown progress and can feed changes back into the process <=Does any of that need a methodological tag line? But thick, demotivated teams who have never done it before will still fail. Jonathan
  33. Re: Doing Agile? Maybe so, maybe not.[ Go to top ]

    If you take a "pick and choose", casual approach, you most likely will not have the discipline to make it successful.
    So I guess the important question is whether Agile works if we "pick and choose" or do we need to use all the methodologies to reap the benifits. I agree with Cedric on that people don't really use each and every practice much of the time. Atleast, I haven't done this and haven't seen anyone do it either. And yet, I am pretty confident that by using Agile selectively, I have gained significantly. Would be interesting to learn about the experiences of people who employ every agile practice in their company.
  34. Re: Doing Agile? Maybe so, maybe not.[ Go to top ]

    ..I agree with Cedric on that people don't really use each and every practice much of the time. Atleast, I haven't done this and haven't seen anyone do it either. And yet, I am pretty confident that by using Agile selectively, I have gained significantly.

    Would be interesting to learn about the experiences of people who employ every agile practice in their company.
    That brings up another interesting issue, what do you get when you "pick and choose" portions of Agile? Because Agile is just an umbrella for software practices that have existed for a long time already, if you don't use each and every one of the things it contains then the fact that Agile is a bs phrase starts to become more evident. How about I start a new manifesto called "Write good software" ? Does that mean I get to claim credit for any good software being written ? ;)
  35. Re: Doing Agile? Maybe so, maybe not.[ Go to top ]

    ..I agree with Cedric on that people don't really use each and every practice much of the time. Atleast, I haven't done this and haven't seen anyone do it either. And yet, I am pretty confident that by using Agile selectively, I have gained significantly.

    Would be interesting to learn about the experiences of people who employ every agile practice in their company.


    That brings up another interesting issue, what do you get when you "pick and choose" portions of Agile? Because Agile is just an umbrella for software practices that have existed for a long time already, if you don't use each and every one of the things it contains then the fact that Agile is a bs phrase starts to become more evident.

    How about I start a new manifesto called "Write good software" ? Does that mean I get to claim credit for any good software being written ? ;)
    Interestingly, Agile itself emphasises sticking to requirements(YAGNI etc.). Shouldn't this also be applicable to Agile practices. I mean, if I am working with a fellow coder on a simple application in which there is no real "requirement" for sharing knowledge through pair programming, should we still pair program just to stay "Agile"?
  36. Re: Doing Agile? Maybe so, maybe not.[ Go to top ]

    The problem if you don't have these "extremists" who try to push and sell the methodology, then you won't have the discipline to implement a truly revolutionary process.

    If you take a "pick and choose", casual approach, you most likely will not have the discipline to make it successful.

    For example, I wouldn't have tried pair programming, unless it was forced on me. The notion seemed ridiculous. But now I'm very glad we've done it - the sharing of knowledge is well worth it, and everything they say about it being productive is true.
    That's the whole problem. When the religious fanatics decide that you have to buy the whole enchilada, then you know something is fishy.
  37. Re: Doing Agile? Maybe so, maybe not.[ Go to top ]

    I wrote a blog-post on this very subject in the last 24h.

    However, in short, I think there are a couple of main problems with the whole debate:
    - Agile has been hijacked by a bunch of religious fanatics and snake-oil salesmen ("Agile consultancies"), selling it as the next Silver Bullet(tm).
    - Critics of Agile methodologies (in part rightly) attack the notion of Agile being a silver bullet and the religious fervour arround the practices as portrayed by the fanatics, but erroneously believe that it is actually supposed to be a silver bullet as mandated by the religious fanatics, and critisize the whole thing for that particular reason.

    No methodology is a silver bullet, and no process or methodology should be adhered to with religious fervour if it is not appropriate for the circumstances of the project.

    Furthermore, no methodology or process will magically make human brain-activity superfluous.
    At the end of the day, it's what people achieve that counts, not what a particular method or process mandated.
    Imo, the real problem is people buying it in the first place. People are trying to sell you stuff every single minute of the day. Just say no when you disagree.
  38. Re: Doing Agile? Maybe so, maybe not.[ Go to top ]

    >Imo, the real problem is people buying it in the first place. People are trying to sell you stuff every single minute of the day. Just say no when you disagree.
    Well, stupid big organizations have always dreamt of the magic process which will make all human brain-activity unecessary. Therefore you will always find an ample amount of potential buyers if you try to sell the next silver bullet or snake-oil process..
  39. Re: Doing Agile? Maybe so, maybe not.[ Go to top ]

    >Imo, the real problem is people buying it in the first place. People are trying to sell you stuff every single minute of the day. Just say no when you disagree.


    Well, stupid big organizations have always dreamt of the magic process which will make all human brain-activity unecessary. Therefore you will always find an ample amount of potential buyers if you try to sell the next silver bullet or snake-oil process..
    Yup. Just like hair lotions that are supposed to fight hair loss :)
  40. Another good article on agile[ Go to top ]

    http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile_27.html
  41. Re: Another good article on agile[ Go to top ]

    http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile_27.html
    So Agile is generally bad unless it's used at Google? Come on. Where's the data? Where's the point to point argument to demonstrate agile does not work?
  42. Re: Another good article on agile[ Go to top ]

    Where's the point to point argument to demonstrate agile does not work?
    That's an interesting angle. Shouldn't the burden of proof be on the people who are trying to introduce something new? -- Cedric
  43. Re: Another good article on agile[ Go to top ]

    Where's the point to point argument to demonstrate agile does not work?

    That's an interesting angle. Shouldn't the burden of proof be on the people who are trying to introduce something new?

    --
    Cedric
    Hi Cedric, I've seen your anti-Agile stance before, and I wondered why? Now I understand. I don't like to be sold too either. Agile is nothing new. It is just a manifestation of Japanese inspired Management and development practices borrowed from Japanese manufactures like Toyota and applied to Software: Take a look at this video by Dr. Jeff Sutherland, the father of Scrum (which incidentally was around long before XP): http://www.infoq.com/presentations/The-Roots-of-Scrum The advantages Japanese motor manufacturers had over their US and European peers in the 1970’s came down to corporate values. From these values they derived practices that helped them out perform the world. The problem with "Agile" as sold today is that often the focus is on the practices or a group of practices (the worst seem to be the XP crowd). But we all know that off the shelf methodologies (snake oil) will never solve all our problems, and there is no silver bullet, so we backlash. This backlash is possibly a good thing, as it may move the discussion away from "Agile" practices and, back on to where the focus should be which IMO is corporate values and principles. Incidentally, the label "Agile" was stumbled upon because the original signatories to the Agile Manifesto didn't like the term "light-weight methodologies" which is what they where collectively known as at the time. Agile is just a marketing label, much like Java or Duke. Personally I would have preferred "Lean" Methodologies (Mary Popendiek) which emphasises the "elimination of waste" or "Adaptive" Methodologies (Jim Highsmith), which emphasises adapting to events and not sticking to a plan, but they chose "Agile" so we are stuck with it. So I think this backlash is a good thing, especially if it gets people thinking about "Lean/Adaptive/Agile" values and principles for themselves. My concern though is that we don't end up throwing out the baby with the bath water. Paul.
  44. Re: Another good article on agile[ Go to top ]

    I agree. Please provide the proof that the methodology you currently use is the most effective.
  45. Where's the point to point argument to demonstrate agile does not work?

    That's an interesting angle. Shouldn't the burden of proof be on the people who are trying to introduce something new?

    --
    Cedric
    Of course. There are some nice books out there, covering all apsects of this topic.
  46. To me Agile is something which is proposed by people who write software, compared to those who manage software projects (and engineers). If I am a project manager, I am more interested in health of the project and so defined processes and a predefined flow with each stage producing measurable output seems very much needed. However, most often, the documents generated too early end up adding cost during implementation. Software developers, in practice, have always written code, unit tested and then turn them into design/interface documents. This works best for people who write softwares. If you see, Agile methodologies takes this view point and tries to make life easier for developers, and emphaisizes on the fact that working, bug-free code is the only meaninful deliverable. Pair programming and other practices aid in knowledge retention within the team. Where does RUP fit in? I believe it still fits in Agile, however, you gotta apply it in now at smaller scale, say at user stories level. One has to still go through design, coding and testing cylces but with Agile, the user stories are manageable, they are small, sufficiently fine grained and help in building the whole software in a piece-meal fashion.
  47. I feel very strongly that managers who don't also write code have no place managing people that do. That's just stupid.
    To me Agile is something which is proposed by people who write software, compared to those who manage software projects (and engineers). If I am a project manager, I am more interested in health of the project and so defined processes and a predefined flow with each stage producing measurable output seems very much needed. However, most often, the documents generated too early end up adding cost during implementation.

    Software developers, in practice, have always written code, unit tested and then turn them into design/interface documents. This works best for people who write softwares. If you see, Agile methodologies takes this view point and tries to make life easier for developers, and emphaisizes on the fact that working, bug-free code is the only meaninful deliverable. Pair programming and other practices aid in knowledge retention within the team.

    Where does RUP fit in? I believe it still fits in Agile, however, you gotta apply it in now at smaller scale, say at user stories level. One has to still go through design, coding and testing cylces but with Agile, the user stories are manageable, they are small, sufficiently fine grained and help in building the whole software in a piece-meal fashion.
  48. I feel very strongly that managers who don't also write code have no place managing people that do. That's just stupid.

    Thats the point which I was making too. Managers who sees software projects as just another deliverable may not realize the true potential of Agile Methodologies. Because they see Agile as another majical way of getting to that milestone quicker, selectively picking agile methodologies inefficiently. For example: Without customer involvment and they buying-into agile and concept of iterative development with short development cylces of user stories, one would just end up with another mixture of orthodox process oriented methodology with mis-understood agile steps. To truly follow Agile, the whole team (including every developer on team) should embrace the methodology and only then it can be success.
  49. I feel very strongly that managers who don't also write code have no place managing people that do. That's just stupid.
    I hope it is OK if I point out the recursive nature of the suggestion. We tried that here, and our CEO is now coding ;-) Peace, Cameron Purdy Tangosol Coherence: Clustered Shared Memory for Java
  50. Yeah, that's actually perfect. The only company I've worked at personally that was anything close to what it sounds like google had was where the CEO was himself a coder. Maybe agile was born for all of these "managers" and other people that are trying to get their heads around a process that they can't understand/measure because they aren't coders. They say "we need tools" to measure blah blah, and to that I say the tools are years of experience, tons of education, and a general passion for software development. If you don't have those then trying to measure this process is always going to be flawed. If you're a good team lead you understand the difference between someone cranking out 100 lines of code and someone who wrote 20 lines of code over three days that just eliminated the need for the other guy to write those 100 lines. I wonder if the biotech or any other "science" type fields has the same problems? Do they have the equivalent of agile coaches sitting in these labs trying to tell people how to do their job ? I seriously doubt it. For some reason the engineering groups in certain organizations seem to be most widely abused when the CEO is your typical "sales" guy or other poor mis-informed souls trying as hard as they can to apply their MBA's to a process that has nothing to do with normal corporate operations... Fooey.
    I feel very strongly that managers who don't also write code have no place managing people that do. That's just stupid.


    I hope it is OK if I point out the recursive nature of the suggestion. We tried that here, and our CEO is now coding ;-)

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  51. I feel very strongly that managers who don't also write code have no place managing people that do. That's just stupid.


    I hope it is OK if I point out the recursive nature of the suggestion. We tried that here, and our CEO is now coding ;-)
    We all do that in Australia too. Now our prime minister spends more time coding than he does in parliament. ;)
  52. I feel very strongly that managers who don't also write code have no place managing people that do. That's just stupid.
    AFAIC, this is 19th century management.
  53. I was attracted to agile because so many of its practices (unit testing, small iterations, coding more to known requirements than making them up) aligned so well with what I was already doing. I also liked agile's view of requirements... since this is maybe the most important part of getting any project right. This is also the source of most of 'agiles' agility. 1. Coding to known requirements and not embellishing designs to support made up requirements of things that might be necessary. 2. Having customers specify requirements as tests, forcing them to resolve many of the ambiguities in advance. I still believe in unit testing, small iterations, daily scrum/stand-up meetings. I also believe that well commented code that captures assumptions and design choices in comments is better than large UML design docs, but here's what I didn't like about agile. 1. It's very open to interpretation, and many cowboys seem attracted to it so they can just avoid stuff they don't like doing (crafting quality code). This might be what I like the least about agile. 2. It's very hard to get business analysts to write tests. I even went to the mat on this and was told by the CTO that our analysts where paid too much money to write tests, so I had to live with QA interpreting requirements in writing tests, negating one of the main benefits of agile. This basically translated into continuing with a schedule with little requirements gathering/design time, without actually getting the test cases that allow the dev team to move quickly. 3. Nobody likes on going scheduling. The business has a right to say when certain work will be done and to make commitments to customers, this is essentially impossible if requirements are changing all the time because you didn't at least attempt to gather the core requirements up front, then manage changes via a more formalized change-request process. Bryant
  54. Methodologies aren't created to help competent developers develop. Really good developers already know what to do. Methodologies exist to support management, communications and to a lesser extent, learning. Methodologies start with a vocabulary that defines sequences of steps to do and artifacts to create during the development process. This provides a level set. The experienced technical folks pick the steps and artifacts that make sense for the project and refine their definitions. Less experienced developers and managers can follow what is being done because the methodology's documentation has helped them understand the language. The methodology's defined steps and associated artifacts give managers something tangible they can associate with progress. If managers don't have something defined by the methodology as "progress" then they tend to invent their own - which always seems to be code - lines, screens, etc. This encourages managers to give short shrift to requirements, design and even testing and instead insist that everyone start typing code immediately. It’s a major reason for why so many projects fail. Methodologies also helps less experienced developers learn to be better developers because it gives them a framework for development. Of course their more experienced mentors still need to explain a lot of the "whys" because as has been pointed out in other posts, methodologies do not come from God. They are not to be taken too literally.
  55. I'm reminded of a quote a colleague gave me a while back: "A process is what you need when all your good people have left". Effective software development demands flexibility since every project is different. Flexibility in development approach and process is essential. That doesn't mean unconstrained chaos - it means choosing the practices that suit the project at hand and its constraints. Each new project needs a process tailored to its needs. Experienced people know how to do this and wouldn't dream of following a formal process blindly or to the letter. For the inexperienced, the discipline and experience of this can help. So you need experienced people defining the project process and writing it up for the inexperienced. Those espousing processes that must be followed to the letter are chasing the dream of a silver bullet. Fred Brooks showed us the folly of this a long time ago. The only valid measure of the success of a process or technique is: does it work for you? If it doesn't, don't use it. If it does, more power to you. Remember: People and projects are different and YMMV. That's no bad thing as life would be dull if there was only one true way.
  56. Post agile methodology[ Go to top ]

    Done the agile thing - seen it burn 80- million on a death march, seen it deliver as well. BUT, given it's basically a marketing tag so we can all improve CV's and get more money what comes next? I first came up with Stiff - but couldn't really define what it was, except a general feeling that we had all stretched a bit too much with the agile thing. But just last week I got a better one: Amorphous. If you are chatting about agile, change the word agile to 'amorphous'. It's fun. It's like XML feeds. Change the word XML to 'crap ascii'. Change refactoring to 'fixing a hack'. Suddenly we sound real (man): "On our agile iteration we are refactoring the xml feed for performance" becomes: "On our amorphous iteration we are fixing a hack to the crap ascii feed for performance" Hey ho, not constructive, but you have to admit the second version is closer to the truth. Jonathan
  57. Howdy All, I get annoyed when "agile developers" compare agile development to the "waterfall approach." I don't think any contemporary development process would advocate the waterfall approach. "Iterative and incremental" has been a major part of most processes for quite some time now. Similarly, a lot of this talk about "my process is better than yours" is meaningless without real measurements. I say an organisation should create a simple process of their own (based on others) and then measure, make changes to improve, and measure again (i.e. continuous improvement). The PSP and TSP out of the SEI take this approach and I think it is the only real way to get "definitive" statements about the quality of different processes, and to really improve the processes (whether they include light-weight or more heavy-weight aspects). Cheers, Ashley. PS I use the term "process" here in the most general sense, and assume a "methodology" (again in the most general sense) includes a process and notation (which itself can range from informal text and drawings to formal UML diagrams). -- Ashley Aitken Perth, Western Australia mrhatken at mac dot com