Discussions

News: Tech Talk: Scott Ambler, on the Agile development process

  1. Scott Ambler, author of a number of books on Agile programming such as "Agile Modeling," "A Practical Guide to Enterprise Architecture," and "The Elements of UML Style", offers this tech talk on the use of the Agile method, such as what it is, why it works so well, and why you should use it instead of the traditional development methods. He also discusses the political implications of Agile programming, and how much people new to Agile programming should commit to it.

    View Tech Talk

    Threaded Messages (22)

  2. what parts work well?[ Go to top ]

    http://www.softwarereality.com/rumours/AgilitySolvesAll.jsp
    and this part specially:
    http://www.softwarereality.com/ExtremeProgramming.jsp

    What part talks about requirements spec., fixed bid or return on software investment.

    For consulting it's good, you double up billing in pairs, you have no requirements and you have verbal deliverable and make friends w/ client in pairs

    I agree more w/ software reality folks.


    .V
  3. what parts work well?[ Go to top ]

    From http://www.softwarereality.com/ExtremeProgramming.jsp
    Is XP really the panacea for our software development sins? Is Kent Beck really the new Messiah of software development?

    Not setting up a straw man there, are they?
  4. what parts work well?[ Go to top ]

    Vic, as your friend, I'm going to have to call bullshit on this one:

    >> For consulting it's good,
    >> you double up billing in pairs,

    We don't increase the size of the team for the sake of pairing. In fact, we typically prefer smaller teams. If anything, we just like even numbers.

    >> you have no requirements and

    Not true. We have the most fine grained requirements that are practical. A step by step description of exactly what a developer will do over the course of say two or three days (up to 5 days). This is versus the traditional BINDERS of information I used to receive on waterfall projects.

    The key is focus. I can focus on a story and a short set of developer tasks. A binder just gathers dust as I thrash away on a waterfall project for months at a time.

    >> you have verbal deliverable and

    This is crap too. Agile methods are all about visibility. Not only do we have very clear deliverables, but ANYONE can walk into the room and see exactly what those deliverables are, AND how much progress has been made.

    >> make friends w/ client in pairs

    Well, yes. This is true. We always like to make friends, and often do. ;-)

    Cheers bud.

    Clinton
  5. what parts work well?[ Go to top ]

    Vic, as your friend, I'm going to have to call bullshit on this one. ;-)Cheers bud.Clinton

    I hope I did not lose a fried....
    See http://www.softwarereality.com/lifecycle/xp/xp_audience.jsp

    I consider myself a student of productive development. I have another good friend who lived trough XP.
    He also agrees with this:
    http://www.softwarereality.com/lifecycle/xp/safety_net.jsp

    I do not consider XP the ultimate in producitity, and I just gave an url, where there are lots of case stories
    http://www.softwarereality.com/lifecycle/xp/forum1.jsp
    http://www.softwarereality.com/lifecycle/xp/forum1.jsp
    etc. form2, form3...

    Since some may not link, here is a cut/paste:
    "Imagine

    Imagine there's no requirements. It's easy if you try
    Just a bunch of coders, reachin for the sky
    Imagine all the people, coding for today

    Imagine there's no schedules. It isn't hard to do
    No silly project deadlines, no one supervising you
    Imagine all the people, coding hand in hand

    You may say I'm an extremer but I'm not the only one
    I hope someday you'll join us and make coding lots more fun.

    Imagine oral documentation. I wonder if you can
    No need for UML diagrams. Just words passed, man to man
    Imagine just refactoring, playing in the sand

    You may say I'm an extremer, but I'm not the only one
    I hope someday you'll join us and make coding lots more fun.
    "

    from http://www.softwarereality.com/lifecycle/xp/extremers.jsp

    If you say what's my alternative? "Scientific development" and key part is independently dupicable and repetable process, as per CMM levels of maturity.
    I just try A vs B and see which makes me faster. I mostly do fixed bid, and rely on mockups of the view and reports.
    Great book is "return on software", talks about ROI.

    .V
  6. what parts work well?[ Go to top ]

    oops:
    http://www.softwarereality.com/lifecycle/xp/forum.jsp

    .V
  7. what parts work well?[ Go to top ]

    The problem with the poem is that it doesn't actually reflect what happens on agile projects.

    There are requirements (otherwise there's nothing to build), there are schedules (we just might not waste our time creating big, useless MS project plans), there is modeling (see www.agilemodeling.com), and there is documentation (www.agilemodeling.com/essays/agileDocumentation.htm).

    Instead of quoting relatively ignorant and unsubstantiated claims, wouldn't it be better to discuss real issues based on actual experiences with agile processes? Nothing is perfect, and there is significant writings on the challenges with adopting and following agile approaches. My advice would be to focus on them.

    Also, as far as CMM/I goes, why is it that in all the years the SEI has been pushing it that they have NEVER done a study comparing the effectiveness of CMM/I level 3+ firms with organizations that are good at software development aren't interested in CMM/I? I think they haven't because they know what the answer will be.

    BTW, I'm the methodologist behind the OOSP, the first publicly published CMM level 5 process (when fully instantiated) for OO development. I've followed a wide range of processes, and I can tell you from experience that agile approaches seem to work a heck of a lot better than traditional approaches.

    Another thing to think about: why is the SEI now scrambling to claim that their stuff can be agile too? Gotta think that they see the writing on the wall.

    - Scott
    www.ambysoft.com/scottAmbler.html
  8. what parts work well?[ Go to top ]

    Don't believe everything you read at softwarereality.

    They do make some good and valid points: XP does have its issues. However, many of the points addressed by the softwarereality guys are no longer valid or pertinent, as the people shaping XP are continually improving it. And, as Mr Ambler suggested, the interpretations of what the softwarereality zealots understand XP to be are often broadly painted and even dead wrong.

    I've worked with numerous teams doing XP over the past 5 years. The "real" reality: It's sometimes a disaster, it's sometimes ok, and it's sometimes wonderful--all just like any other project using any other process. My experience has been that it's usually been ok to great more often than it's sucked. To condemn it by linking to a biased site with handful of failed case studies is closing your eyes to the fact that many places are making it work, and enjoying it to boot.

    -Jeff-
  9. Briefly skimed your anti-XP propoganda. You raise what to me seems to be an obvious point. Reading "XP explained" or all 20+ XP books won't gaurantee success.

    The truth is that there is no substitute for skill and experience, what ever process you choose/devise. Agile proponents are the first to highlight this fundamental truth.

    The strengths of XP (and the other Agile practices) IMHO is that they draw attention to the real bottle-necks in organisations through constant concrete feedback.

    The upshot of this is that organisations have the data to determine their real problems. Often these problems may not be in development, choice of technology etc, but in other areas such as organisational culture, management, inept marketing, or poor project conception.

    XP allows the programmer the possibility to take responsiblity for just programming, rather than being a convienient scape-goat for all an organisations ills.

    For this reason alone, if you are serious about exploiting technology for business benefit, XP is worth a look.
  10. Sounds good[ Go to top ]

    Sounds good to relieve developers from the weight of problems not related to the scope of their project.
    However, wouldn't an approach that relies more heavily on documentation be useful to set the boundaries of that scope ?
  11. Sounds good[ Go to top ]

    Yeah a valid point. This approach can work too but...

    How many customers do you know who are willing to read a 150+ page requirements document?

    If they do read it how many of them are sure what it is they are about to sign up to?

    Once they've signed, how many customers change their mind?

    How many businesses change so quickly that most documentation is quickly out of date?

    Buy customer I mean any stakeholder outside the development team. In most organisations these folks feel free to change the development contract at will, yet expect the deliver date to stay constant.

    In fact I've worked on several projects, where the only thing we knew for sure was the expected delivery date - despite loads of (useless) documentation. I'm sure this is a common experience.

    Paul.
  12. Re: Sounds good[ Go to top ]

    How many customers do you know who are willing to read a 150+ page requirements document?

    Hopefully, the requirements document (e.g Use Cases) is being elaborated together with the customer and not in a devloper's ivory tower. At least this should be the common practice, and IMHO it is in most projects (at least the ones I worked in).
    If they do read it how many of them are sure what it is they are about to sign up to?

    Huhh? I guess most of them can read. In fact, requirements specify what is to be developed in terms of business. So, who, if not the customer, understands the business. Especially, if the requirements were elaborated together with the customer's business departments (see above).
    Once they've signed, how many customers change their mind?

    Many, but that is not the point. When explicitly capturing requirements and making them a part of a contract, any change of requirement induced by the customer is a change request! Explicitly capturing requirements is the only way to protect you against late changes.
    In fact I've worked on several projects, where the only thing we knew for sure was the expected delivery date - despite loads of (useless) documentation. I'm sure this is a common experience.

    Well, from my experience, this is clearly not the case.

    Regards,
        Dirk
  13. Re: Sounds good[ Go to top ]

    How many customers do you know who are willing to read a 150+ page requirements document?
    Hopefully, the requirements document (e.g Use Cases) is being elaborated together with the customer and not in a devloper's ivory tower. At least this should be the common practice, and IMHO it is in most projects (at least the ones I worked in).
    If they do read it how many of them are sure what it is they are about to sign up to?
    Huhh? I guess most of them can read. In fact, requirements specify what is to be developed in terms of business. So, who, if not the customer, understands the business. Especially, if the requirements were elaborated together with the customer's business departments (see above).
    Once they've signed, how many customers change their mind?
    Many, but that is not the point. When explicitly capturing requirements and making them a part of a contract, any change of requirement induced by the customer is a change request! Explicitly capturing requirements is the only way to protect you against late changes.
    In fact I've worked on several projects, where the only thing we knew for sure was the expected delivery date - despite loads of (useless) documentation. I'm sure this is a common experience.
    Well, from my experience, this is clearly not the case.Regards,    Dirk

    This has been my experience. It is easy to say make it part of the contract, but in reality this is harder. This is my 10th year of working and as such I've been reflecting on the projects and customers.

    I've never had a customer that cared about "change requests". From govt. to telecome to credit card, they all want what they want. And when you explain to them that they signed off on the feature set and their new items are change requests, they all, without fail threaten to drop the thing if they don't get what they want.

    If you have a contract that is iron-clad enough to protect you from this, then give me the name of your contract lawyer. I can find PLENTY of work for him.

    The point is that customers can and do change their minds and they want what they want.

    Also, they don't read documents. Ever. I've had cases where we had to read the documents to them to get them to read. Perhaps your customers are smarter, the applications I've worked on over the years were made to help people do what I would consider drudge work do it faster and more efficiently. These guys, most of the time,didn't even know they could change the resolution on their computers or how to upgrade a browser. How many of them can understand even use case documents. Again, none.
  14. Points[ Go to top ]

    I agree with all comments. In my experience too, requirements change so often that documentation is always out of date.
    However, I do not think this would invalidate the need for thorough documentation. Take the "Vision" document from RUP, for example. It is a description of the problem and the proposed solution, in a language you and your customer can understand. I have seen at least one instance where this document was perfectly valid until the end of the project, and had to undergo only minor changes.
    As to the various use cases and the implementation specifics, they certainly change a lot. Maybe at this point XP would be a good alternative.
  15. Points[ Go to top ]

    I agree with all comments. In my experience too, requirements change so often that documentation is always out of date. However, I do not think this would invalidate the need for thorough documentation. Take the "Vision" document from RUP, for example. It is a description of the problem and the proposed solution, in a language you and your customer can understand. I have seen at least one instance where this document was perfectly valid until the end of the project, and had to undergo only minor changes.As to the various use cases and the implementation specifics, they certainly change a lot. Maybe at this point XP would be a good alternative.

    Agreed. I think a small, concise vision document is very important. What are we making? I'm certainly not saying documentation isn't important. But I don't think that documenation makes development as clean as what was implied in an earlier post.
  16. Points[ Go to top ]

    I agree with much of what has been said too. Perhaps I should not of implied that all documentation is useless.

    The undelying issues are communication, accountability and transparency. A document is just a means of communication and could be effective or ineffective. Customers may choose to honour their contract with development or they may not.

    Choose what works for you. If things are working than fine. If things aren't working then regular feedback to help determine what works and what doesn't must be a good thing.

    Peace.

    Paul.
  17. Re: Sounds good[ Go to top ]

    Hi David,

    indeed, it seems like we had totally different experiences, when realizing customer projects. In fact, I just rectnelty had a project, where more money was made by realizing change requests, than realizing the functionality of "actual" project. I also never heard a customer say "do it, or we will drop the project". Of course, there were situations, where customers said, that the effort for a change request was too high. But even in this cases, a solution could be found, satisfying both sides (i.e a compromise of making the change request cheaper, and putting less functionality into the change request).

    I wonder what the reasons for this different experiences in "customer behaviour" are. "cultural gap"? Project sizes? I don't know.

    Regards,
        Dirk
  18. Re: Sounds good[ Go to top ]

    Hi David,indeed, it seems like we had totally different experiences, when realizing customer projects. In fact, I just rectnelty had a project, where more money was made by realizing change requests, than realizing the functionality of "actual" project. I also never heard a customer say "do it, or we will drop the project". Of course, there were situations, where customers said, that the effort for a change request was too high. But even in this cases, a solution could be found, satisfying both sides (i.e a compromise of making the change request cheaper, and putting less functionality into the change request).I wonder what the reasons for this different experiences in "customer behaviour" are. "cultural gap"? Project sizes? I don't know. Regards,    Dirk

    Perhaps the size of the company? The customer doesn't come right out and say it, but I tend to front the development efforts and the implication is pretty clear. I tend to gravitate towards smaller companies and when you do a project for a big credit card company or a big wireless telecom, or a large govt agency, they tend to have a lot of sway over a company in the 30 - 150 person range.

    And they know it.

    We certainly have compromised:
    "Well, we could add these and the time shouldn't push out."
    "Well, we can add this but we'll need 3 more weeks."
    "Well, how about we trade this for that?"
    "Well, we just can't do it in the time allowed."

    It takes a strong person on our side to look a company that is the source of a large amount of your business for a year and say "No." Ultimately, we are all talking about our experiences and I'm sure they run the gamut, but I'm always amazed at how stubborn and nasty people can get when all you are trying to do is HELP them.

    A couple of weeks ago, I was pulled into a project and mentioned that we need to list out the requirements. The guy on the other side said that he just finished rolling out a $10 million system and all they had were 3 artifacts. One was a use case document, fercrissakes! I said that "strictly speaking, the requirements were in the use case documents." And for a design, he handed me a penciled sketch(unreadable) on the back of a piece of paper.

    The guy was acting like he took that sheet of paper, stapled on a $10 million dollar check, and they came back with this application!
  19. Hi David,

    Your experiences are pretty similar to my own, and I've been developing for 15+ years, for much of that time I was in management managing contracts with customers like the ones you describe.

    In fact such experiences lead me to get out of management completely. Now I'm a freelance consultant.

    Whilst I feel that different processes can work in different environments. I have also come to think that "contract based" development is fundamentally flawed. You can get it to work, but don't rely on the contract.

    The reason I say this, is that developmenet is not a defined process, and even if it was it would take a lot more detail then appears in most contracts/specs to precisely define cost, scope and project delivery date. As I've said previously, the only precise fact on a lot of projects is the delivery date. The scope nearly allways as some degree of uncertainty.

    It is like the Heisenberg's Uncertainty Principle, you can fix the delivey date or the scope but not both. In most projects, precise details of the scope are determined iteratively as the team discovers issues during design, implementation and even during test.

    This is why even with waterfall processes state that the pratices can not be applied in a defined way, and you must iterative through process steps as required. As a project manager I developed a good gut feeling for how much "iteration" would be needed, and added the required contingency to my plans.

    Agile development just makes this iteration explicit and a lot more transparent, resulting in a more open, honest and data driven relationship with your customers.

    In delivering true business value transparency and concrete feed back are really important (IMHO).

    Paul.
  20. Exactly. There's the concept of the iron triangle, you can't let all three of scope, cost, and schedule be fixed without negatively affecting quality.

    I walk away from projects when the managers are unable to accept this reality.

    I have an article on the subject at http://www.sdmagazine.com/documents/s=7839/sdm0303g/sdm0303g.htm if you're interested.

    - Scott
    www.ambysoft.com/scottAmbler.html
  21. what parts work well?[ Go to top ]

    Agile Programming/Modeling/Testing etc... may work for little projects or very large but less complex projects projects. But there is no way you can use it in huge and very complex projects where you thousands of business rules and constraints to deal with, and believe me pair programming wouldn't help you nor Junit (Test First in your parlance). Only a solid methodology adapted to the size and complexity of the project would work. This doesn't exclude the use of XP within small components of a huge mandate.

    Another thing, assessing developer's competence on using or not your approach would be a bit harsh and inappropriate.
  22. There is a good talk from Scott at IT Converations, "Are You Agile or Are You Fragile?". It's about two hours long, but a worthy listen. Get it here: http://www.itconversations.com/shows/detail355.html
  23. It isn't working...[ Go to top ]

    Am I the only "lucky" one or this link isn't working?