Discussions

News: Tech Talk: Scott Ambler on Agile Modeling and Development

  1. In this interview, Scott Ambler talks about Agile Modeling and the Agile Development techniques. He addresses the need to lessen the existing divide in projects between DBA's, Developers, and Enterprise folks, compares traditional development approaches to the Agile approach and points out some of the problems with Model Driven Development (MDA).

    Watch Scott Ambler's Interview

    Threaded Messages (21)

  2. Isn't it about time to push 'agile' into the hackneyed column?
  3. Isn't it about time to push 'agile' into the hackneyed column?
    Agreed...I sure won't be running out to get his latest book.
  4. Isn't it about time to push 'agile' into the hackneyed column?
    Agreed...I sure won't be running out to get his latest book.
    Well, "talk is cheap" ;-)
  5. Well, "talk is cheap" ;-)
    I guess that's why Scott has written 15 books.
  6. 'ecosystem', 'community', 'orthogonal', 'affinity', etc...

    Push it!!!
  7. race condition: 'ecosystem', 'community', 'orthogonal', 'affinity', etc...

    Race, I'm getting worried about you. You've been much more negative than usual lately. Is there anything that we can do to help?
  8. I'm afraid I may have corrupted him. My sincerest apologies.
  9. Harsh?[ Go to top ]

    Guys -

    This is a little harsh. Sure, maybe the word "agile" is used a lot these days. But how many people are even practicing it? This is still new stuff from what I see in practice.

    I personally really liked his book.

    Dion
  10. Harsh?[ Go to top ]

    But how many people are even practicing it?
    I'm not.
  11. So?[ Go to top ]

    But how many people are even practicing it?
    I'm not.
    Congratulations! Do you want a cookie?
  12. Break down those barriers[ Go to top ]

    Well I quite like the idea. You dont have to go in head first into Agile but it has some advantages.
    Problem is getting people to SHARE their ideas and be willing to LISTEN
  13. Break down those barriers[ Go to top ]

    Perhaps, you're right, should I start with just the newest book, or go back and read the last four or five?
  14. Harsh?[ Go to top ]

    Guys -This is a little harsh. Sure, maybe the word "agile" is used a lot these days. But how many people are even practicing it? This is still new stuff from what I see in practice.I personally really liked his book.Dion
    The problem with most agile 'XYZ' techniques are that they are a little too academic and they don't scale from a management perspective outside of stovepipe implementations. I wish that it wasn't so but agile is dependent on "peace, love and harmony" among all the players in a software project. It's failure is that it isn't as agile as advertised.

    Larger software projects are notoriously territorial, from a management perspective, which don't lend themselves to open and iterative processes that are put forth by agile techniques.

    I think the harshness you're seeing is that if people disagree with the agile methodology, or at a mininum raise concerns and try to have open discource, they are swooped upon by the "Thought Police" and branded as less-than. For the most part, this stuff looks great on paper and that's about it.
  15. The problem with most agile 'XYZ' techniques are that they are a little too academic and they don't scale from a management perspective outside of stovepipe implementations. I wish that it wasn't so but agile is dependent on "peace, love and harmony" among all the players in a software project. It's failure is that it isn't as agile as advertised. Larger software projects are notoriously territorial, from a management perspective, which don't lend themselves to open and iterative processes that are put forth by agile techniques. I think the harshness you're seeing is that if people disagree with the agile methodology, or at a mininum raise concerns and try to have open discource, they are swooped upon by the "Thought Police" and branded as less-than. For the most part, this stuff looks great on paper and that's about it.
    I agree that people, whatever their point of view, often tend to shut out others' disagreement if they feel that they've heard "all those complaints" before, or are just so hell bent on believing in their point of view that any evidence to the contrary is threatening to them, and that's unfortunate. The best practitioners of agile (or any methodology) are empirical and open to and understanding of the weaknesses and tradeoffs. And those humble agile practitioners do exist.

    I also agree that discussions of agile often don't talk much about organizational politics, and basically pretend that you've already dealt with all that, and now you're ready to sit down to work in an open and honest environment.

    However, I don't think it follows that you can't do agile in a territorial management environment. Certainly the territoriality presents an impediment, but it presents an impediment to any approach, agile or otherwise. The most obvious areas affected by territoriality and counter-implementation are requirements analysis and user acceptance. If you can't get your users to agree to a prioritized list of functionality, or you can't get them to agree that the release functionality has been built, well, no process is going to force them to do so. You can make people sign off on documents that they haven't read and/or view as entirely provisional, necessary evils, only to have them disagree later, or you can work with them directly to try to come to a consensus, which again may be entirely provisional and non-committal. Either way you're in for some pain down the road.

    It's important for any project manager, or anyone involved with software development, to appreciate the political realities of working with groups of people, and to work with management to make sure that the change brought about by new software is accepted and incorporated by the organization as a whole. One good thing about at least the philosophy of agile in this regard is that it encourages you to avoid hiding behind documentation and a CYA mentality and push yourself to go out and work with people directly ("Customer collaboration over contract negotiation" [http://agilemanifesto.org]).

    Finally, we should all remember what some teachers of agile have said: that the practices are really etudes, exercises designed to make you learn something. If anything rings true to me, it is this. My own efforts to understand how to manage projects better have been a series of trial efforts, exercises, from which I'm continually learning and refining my understanding of what makes for a successful project. I think there are definitely things that one can learn from putting one's effort into implementing agile practices. You don't have to use them all all the time, but the lessons you've learned really will help you style your own approach.
  16. I am familiar with Scott's work for the last 5-6 years, I've read dozens of his articles and a couple of his books and you guys do not know what you are talking about. Scott is one of the brightest minds in the software industry.

    Btw, he explicitly says that 'agile' is not a fit for all and that it should be combined with some traditional front planning approaches like RUP when needed and that he personaly do that quite often.
    Don't have time to defend Scott properly (although he do not need any defense) but please read the interview carefully.

    MC
  17. To the transcriber...[ Go to top ]

    It's IBM AD/Cycle, not IBM 80-cycle. Only an old fart like me would know that, but it's worth correcting.
  18. To the transcriber...[ Go to top ]

    It's IBM AD/Cycle, not IBM 80-cycle. Only an old fart like me would know that, but it's worth correcting.
    That is funny, and you are not the only old fart to appreciate it.
  19. ...points out some of the problems with Model Driven Development (MDA).
    Scott made some notable complaints about MDA, all of which are manageable (perhaps fleeting in an evolutionary sense):

    1) Unskilled application developers.

    2) Immature tools and vendor turnover.

    3) Rival tools can't integrate and share models.

    He also recognizes that CORBA is a failure.
  20. CORBA a "failure"[ Go to top ]

    "He also recognizes that CORBA is a failure. "

    Well I guess it failed as an attempt to become "universal" middleware it was originally touted as but it is alive and well today as a practical and effecient cross platform invocation mechanism and is heavily used in telecomms and investment banking industries for this very reason. Also there are simply no real compatibility issues between vendors these days, I personally have implemented several multi-vendor corba systems with no compatibility issues. Comparing CORBA and MDA is bit odd to say the least.

    Oh and I have to say the quality of the interview transcription truely sucks - loads of typos, grammar errors and even one whole scentence repeated twice.
  21. Book "Extreme Programming Refactored - The Case Against XP" by Stevens and Rosenberg. While I think Scott's interview was very good (especially the business reading - I do Business Week and then the others mentioned)- and the Ronin International site is also very good (recently redone, it appears, looks nice!) . . . for the Other Side of Agile this is a text worth reading. It has a detailed analysis of Agile you will not find anywhere else - very thought-provoking. Part of the book are sometimes irritating, but if you are NOT an Agile extremo you will spend a good bit of time ROTFL - if you ARE you'll hate it. BE SURE to go look it up at Amazon and read ALL the (21 or so)reviews - they're also interesting - there are at least 3 reviewers whose names are well known . .

    Cheeers - gh
  22. I agree with Scott Ambler in all things which he said in the interview.

    We have a territorial team structure. One developer does the requirement analysis, another one makes the UML design, another one implements the server side of that design and yet another one makes the GUI implementation afterwards.

    In our 8 man team we have 4 senior developers who don't code because they don't like it or because they are not good enough in it.

    As Scott Ambler said, this leads to the fact that the "real" develpers don't respect the developers who don't code. They speak in different languages, have different opinions and so on. Furthermore this Taylorism is unproductive in software developement. And it is NO team work like assembly line working is no team work too.

    Maybe some people are too old to be open minded for Agile methodology. But I think there is a bigger obstacle: Some developers are simply not "Agile" by nature, no matter how young they are or if their first methodology was Agile or not. Its like someone likes Pop music and hates Country music, another one hates Country music and likes Pop music. You need band which likes the same kind of music. So you need a development team where eveyone is Agile by nature. I hope this analogy is self explaining. But in the same way, if you want to use traditional methodology you need a team of traditionalists. A develper who is Agile by nature will not be happy in such a team.

    Its just a matter of evolution. Agile projects are more productive I believe. Maybe we need a new generation of competent IT managers to realize this. But maybe we never will get such good IT managers because even if they are really bad mangers, if they sell their failure as a success or manage to put the blame on others, they will keep their job. Its much about rhetorics and connections in such high spheres.