Discussions

News: Agile Software Development: True Adoption or Just a Label?

  1. A recent Methods & Tools poll researched the agile software development practices adoption rate in organizations. The conclusion of the survey: "The importance of the agile approach is surely growing in the software development community. It remains to be determined, with an unbiased perspective, how this evolution will translate in the rate of software development project successes, because at the end, this is what matters the most." In other words, Agile is growing, but the effects are still unclear. The question asked was "At what stage is the agile approach (XP, Scrum, TDD, ...) adoption at your location?" A similar poll was already performed in 2005. Comparing the two sets of results, we could notice that the level of ignorance of the agile movement has decreased, as only 13% of the organizations are not aware of its existence. Full deployment numbers have doubled in the recent years to reach 17% and total rate of various adoption levels is now 56% compared to 41% in 2005.
    Comparing the 2008 and 2005 results, we could notice that the level of ignorance of the agile movement has decreased, as only 13% of the organizations are ignorant of it. Full deployment numbers have doubled in the recent years to reach 17% and total rate of various adoption levels is now 56% compared to 41% in 2005. This growing adoption rate has also been confirmed by other surveys on this topic. Some critics will naturally discuss the "scientific" nature of this kind of surveys, but I believe that they are useful to give us an idea of the evolution of the software development world. The increased popularity of agile is also visible on the Indeed job request trend. The recent improvement in agile software development process visibility and acceptance should however make us cautious with the current results on agile adoption surveys. When software development practices are more widely accepted, the number of adopting organizations increases, but the substance of valid usage of this practices decreases. The answers to surveys tend then to be biased towards what should be the correct answer instead of reflecting the reality of the software development context. The tendency of upper management to "push" new approaches to people who are more reluctant to change their old habits does usually not produce good results. This is even truer when projects will not be given additional resources to support the transition. We are therefore transitioning from a period where agile adoption level may have been underestimated to another where it could be overestimated. Previously, some developers would not define their practices openly as agile or extreme programming because manager would have considered it a "cowboy process." A 2006 Forrester's report (Editor's note: free with registration) found that agile adoption in the US and Europe was 17% according to a survey of 1078 IT decision-maker. They however precised that " because Agile processes are often adopted at the grassroots level, they frequently fly below the radar. This makes it unlikely that a single IT decision-maker knows what methodology every development team is using. For this reason, Forrester believes that Agile adoption is actually higher than reported in this study." Today, some companies will pretend that they are agile, but without implementing the essence of the approach. (Emphasis by editor.)
    Does your company use Agile practices? Would your company claim to use Agile practices if it's not doing so?

    Threaded Messages (89)

  2. Does your company use Agile practices?
    I work for a moderate sized university (14,000 students) and we are a Waterfall shop. We follow a strict process of writing a requirements document, receiving approval, writing a design document, receiving approval, writing a test document, receiving approval, and finally writing code, which gets peer reviewed. Ironically, the move to production is painless. We simply email an administrator with directions and it gets done. Any change to requirements (or slippage of schedule) results in a change to the requirements document, which contains the schedule, and going back through the approval process. Any change to the other documents, as a result of requirements changes, results in going through approval again for each document. Just to provide context, we do not write applications here. The head of the department has a strictly "buy don't build" philosophy. We write connectors between systems, e.g. export from one system to a file which gets imported to another system.
  3. What is Waterfall?[ Go to top ]

    I work for a moderate sized university (14,000 students) and we are a Waterfall shop.
    Did you know that Winston Royce's paper, considered the original definition of Waterfall, actually showed an iterative process? Dave Rooney Mayford Technologies
  4. Re: What is Waterfall?[ Go to top ]

    I work for a moderate sized university (14,000 students) and we are a Waterfall shop.

    Did you know that Winston Royce's paper, considered the original definition of Waterfall, actually showed an iterative process?

    Dave Rooney
    Mayford Technologies
    That's priceless!
  5. Re: What is Waterfall?[ Go to top ]

    <blockquoteThat's priceless!</blockquote> Hi Erik, I like your insights on various forums, the Scala mailing list, and your own blog. Would you mind expanding on this one a bit? If either of us mispoke or communicated poorly, I'd like to learn from it.
  6. Re: What is Waterfall?[ Go to top ]



    Hi Erik,

    I like your insights on various forums, the Scala mailing list, and your own blog. Would you mind expanding on this one a bit?

    If either of us mispoke or communicated poorly, I'd like to learn from it. No, no one misspoke here. I'd never seen the that paper before. On a number of occasions I've told people that no one has ever actually done "waterfall development" as the term is popularly used. Waterfall development was "invented" for large-scale man-critical systems. You simply can't build those pure sequentially. Where I think the Agile movement has succeeded is that it has conveyed principles advocated for decades by other methods in the form of intuitively appealing sound bites. The lesson here is that your message takes up more than one slide it is lost. Winston's paper is really an indictment of the popular definition of waterfall development, and that definition has stuck because if you scroll down in his paper to the first big graphic that's what you get. Stop there and you miss the fact that he says "and in reality this never happens" and has more graphics. It's too complex. Too long. So is the Rational Unified Process. I love RUP, but it's a process framework, not a process, and it's complex as all getout to understand. Agile (which is reall a process philosophy) is easy to understand, easy to explain, and easy to adapt. Applied correctly it accomplishes 90% of what RUP does, for 10% of the intellectual effort. Both are easy to misapply.
  7. Re: What is Waterfall?[ Go to top ]

    Thanks for the explanation Erik. When I speak of Waterfall, I'm only referring to Figure 2. of Dr. Royce's paper. It's inaccurate to call it Watefall but there is no other name for the process I'm aware of and Waterfall comes the closest. I don't believe it's impossible to implement true Waterfall, but an organization doing it must be fairly static in its business model. There's a pretty good analysis of the shortcomings of Waterfall by a project manager at the following link. http://www.techdarkside.com/?p=164
  8. Re: What is Waterfall?[ Go to top ]

    Thanks for the explanation Erik.

    When I speak of Waterfall, I'm only referring to Figure 2. of Dr. Royce's paper. It's inaccurate to call it Watefall but there is no other name for the process I'm aware of and Waterfall comes the closest.

    I don't believe it's impossible to implement true Waterfall, but an organization doing it must be fairly static in its business model.

    There's a pretty good analysis of the shortcomings of Waterfall by a project manager at the following link.

    http://www.techdarkside.com/?p=164
    I think the author failed to see past the archaic terminology, technology advancement, and the shifts economics caused by advances in technology and consequently misinterpretted Royce's paper. As an example, Royce advocated specifying tests up-front, prior to coding. In his day, computer time was expensive and tools were sparse. Remember, this paper was published prior to the advent of even C or Pascal. Today, given advanced tools and cheap computers, I'm pretty sure he would advocate something akin to TDD with automated tests. As another example, think about programming in assembly. When you program in assembly, you have to worry about things like calling conventions and no overwriting someone elses register and managing the stack and things like that. Now think about the need for up-front design in such an environment. Calling conventions, memory layout, register usage, etc was all essential. If people weren't coding to the same standards, the code would simply not work. What Royce was calling design is more akin to specifying interfaces or classes in Java than it is to the pile of UML people think of as design now. Today our programming languages capture and check the details that in 1970 had to be captured on paper and checked by people. I don't think Royce was advocating what today would be called an Agile process, but it does have many of the elements. It would be interesting to recast the paper in terms of modern technology. If I can find some time this weekend, maybe I'll do that...
  9. Re: What is Waterfall?[ Go to top ]

    I think the author failed to see past the archaic terminology, technology advancement, and the shifts economics caused by advances in technology and consequently misinterpretted Royce's paper.
    Yes. Consider for a moment how long it took for a simple syntax error to be caught in 1970 (assuming it made it as far as compilation). You had a deck of punch cards that had to be submitted, and it could take on the order of hours to find out that a program didn't compile. As such, you spent much more time reviewing your code prior to even creating the punch cards, and it was good to have at least one other pair of eyes to look over the code. Contrast that with modern IDE's such as Eclipse. There, you have the ability to determine how many milliseconds the IDE should wait before showing you the red squiggly line under a syntax error! I read a while back something from Royce's son, Walker. He said that his father wrote that paper in the context of the DoD contracting model and how the IBM Federal Systems division worked. Those influences had a significant impact on what he wrote, and it did bother the elder Royce how his work had been used to create what we came to know as Waterfall. Dave Rooney Mayford Technologies
  10. Re: What is Waterfall?[ Go to top ]

    I think the author failed to see past the archaic terminology, technology advancement, and the shifts economics caused by advances in technology and consequently misinterpretted Royce's paper.

    As an example, Royce advocated specifying tests up-front, prior to coding. In his day, computer time was expensive and tools were sparse. Remember, this paper was published prior to the advent of even C or Pascal.
    Actually, you make the author's point. Outside the context of what Dr. Royce developed and when he developed it, the Waterfall methodology makes no sense. I think we agree that Dr. Royce did seem to be aware that the highly controlled methodology presented in his paper would not present the users with a usable model in version 1; hence, his advice to throw it out and use lessons learned to develop the actual software. As I pointed out in an earlier reply, Waterfall can work in an organization with a largely static business model. Oddly, the one organization I worked for, who fit this "requirement", employed IID without calling it so. The single most important idea in the author's post was the following: "It creates a cost-change curve that is unacceptably expensive (you know, the cost of a change grows exponentially as the project progresses)...". What I saw in the few instances in which a project used Waterfall was a costly method of development that couldn't be sustained through the life of the project and COULD NOT POSSIBLY provide the users with what they wanted in the timeframe they needed it. An attack on Dr. Royce is, of course, not warranted. He wrote his observations of projects he worked on. So, if your post was meant to defend Dr. Royce's writing, then I applaud it. If you tried pointing out that the industry has largely misinterpreted his work, you have a valid argument. I'm not sure what Dr. Royce would advocate today. I think it a better idea to look at his advice in proper historical context and develop our own ideas based on our current context.
  11. Re: What is Waterfall?[ Go to top ]

    Did you know that Winston Royce's paper, considered the original definition of Waterfall, actually showed an iterative process?

    Dave Rooney
    Mayford Technologies
    Yes, I downloaded a copy of "Managing the Development of Large Software Systems" last week and read it. (Got tired of second hand accounts of what he wrote.) One perspective is that he advocated a lot of documentation of front, which is characteristic of Waterfall, so I can see in part where our current Waterfall methodology developed. However, he did say that a project team should be prepared to throw out the first model, which strikes me as iterative. Reading "Iterative and Incremental Development: A Brief History" by Craig Larman and Victor R. Basili, in IEEE's Computer magazine June 2003 issue, really changed my views. Iterative and incremental development(IID) dates back to the 1930's and was used in large defense-related software projects in the 1950's. Somehow a misreading of Dr. Royce's paper has caused us to go off course for a few decades. Hopefully, we'll start getting back on course with the various Agile methods out there.
  12. Re: What is Waterfall?[ Go to top ]

    Phillip Armour also pointed out in his book "The New Laws of Software Process" that waterfall has always had feedback. Waterfall didn't have the creative marketing that agile has, though.
  13. Re: What is Waterfall?[ Go to top ]

    Phillip Armour also pointed out in his book "The New Laws of Software Process" that waterfall has always had feedback.

    Waterfall didn't have the creative marketing that agile has, though.
    Thanks for mentioning the book. I'll have a read. Waterfall had the backing of the US Department of Defense at a time when a large percentage of software written was for Defense purposes. Marketing didn't promote it. However, having it as a required methodology for an organization who contributed large amounts of money to a fledgling software industry is certainly an implicit promotion in the least. By the way, I'm not putting an "Evil" label on Waterfall. My opinion is that it's inappropriate for any organization I worked for. To use it, an organization must be able to withstand delays as requirements come through - outside of the Design Phase - and ripple into other phases. Requirements changes are disturbing to design, coding, and testing, but they are made worse by having a committee approval process for acceptance of changes.
  14. Re: What is Waterfall?[ Go to top ]

    outside of the Design Phase
    Correction: Should have read, "outside of the requirements phase".
  15. I believe in interface first design and then coding. I know that depending on the side of the project some bureaucracy may be necessary, but once you have it, it's not a truly agile environment anymore! Eduardo Sasso http://openjobs.com.br
  16. I believe in interface first design and then coding.

    I know that depending on the side of the project some bureaucracy may be necessary, but once you have it, it's not a truly agile environment anymore!

    Eduardo Sasso
    http://openjobs.com.br
    If you have two or more applications that need to communicate (e.g. billing system and policy admin system) then I completely agree the integration points between the systems should be clearly defined as early as possible. Not only that but because of the high probablilty of problems, these parts should be built first. The earlier the interfaces are being used (even if the backend functuality is stubbed) the better. Rather than being unagile, this approach is perfect for agile, because agile projects are geared up for change. With the interfaces in place early they are bound to need re-work, and if the impact is 3 month delays, heaps of beauracracy and a big fat bill then people will either leave the interface definition as late as possible or introduce all sorts of nasty hacks to avoid changing them.
  17. More than just practices[ Go to top ]

    Does your company use Agile practices? Would your company claim to use Agile practices if it's not doing so?
    Agile is much more than just a set of practices. It's also how the team is structured and works together, how they work with the people for whom they are building the software, and a whole attitude towards achieving positive results over blindly following a process. I have seen, and continue to see, criticism that there's nothing new in 'Agile'. In many ways this is true - there have been countless teams that have worked using what would now be considered agile principles. I worked on a team like that back in the early 90's. What I do see, though, is that Scrum has made it OK for managers to work iteratively and loosen the leash on their teams, while XP has made testing sexy for developers and frequent communication with the Customer OK. Combine these without aspects the hype, rhetoric and egos involved, and you will indeed see overall improvement. Scott Ambler has written about this based on the surveys run at Dr. Dobbs. FWIW, the audience there is rather skewed towards preferring traditional processes. Dave Rooney Mayford Technologies
  18. Perhaps I missed it, but I don't see a description of their polling methodology. Was this a random sample, or a self-selected group of IT responders? Without a properly selected set of participants, the results are meaningless. Mark
  19. Agile = Use What Works[ Go to top ]

    What I have noticed is that not a single Agile process will fit any organization purfectly without modifications. We at GridGain took whatever works for us from various processes and use it on daily basis. For example, here are some of my favorites:
    • Status Meeting - The whole team briefly meets in the morning to go over status. We took it one step further and send status emails by the end of the day.
    • Short Iterations - keep it simple and expand as you go.
    • Continuous Integration - we have a very rich set of test suites that run on every commit on Atlassian Bamboo. We use our own Distributed Junit integration to execute JUnit tests in parallel on the grid and were able to speed up test runs from 1 hour to 17 minutes by running them on 3 servers concurrently (will move them to EC2 soon).
    • Minimal Documentation - to us, the best documentation is Javadoc and set of APIs.
    • Team Collaboration Tools - includes good project Wiki, filing Jira tickets on every little issue, etc...
    • Strict Coding Guidelines - all code must look like it was written by one developer as far as style, naming, spacing, etc...
    • Constant Code Reviews - we have team reviews for every line of code that ends up in production.
    Here are the concepts I never bought into:
    • Pair Programming - never understood 1 developer for a price of 2 concept.
    • TDD in pure form - we don't start from test cases, but we implement tests after about 10% of code is already written. Such approach minimizes the amount of test refactoring that would take place in early development when everything constantly changes.
    My suggestion is use whatever works and never religiously buy into any process. Best, Dmitriy Setrakyan GridGain - Grid Computing Made Simple
  20. Re: Agile = Use What Works[ Go to top ]

    what is this agile process anyway ? scrum meeting every day ?
  21. Agile != Use What Works[ Go to top ]

    Dmititry, I hear what you are saying, but I don't think that's Agile with a capital "A." However, it may be agile. -Erik
  22. A very practical approach[ Go to top ]

    Thanks Dmitriy, that is one of the most practical approaches to Agile I've seen, and I agree with you. An experienced developer can save time by outlining their code a little before they start writing the test. But I think the proponents of TDD want you to start coding your test first as a means of building discipline so that you don't start writing your test too late. Whenever there is a grey area, sometimes it's easiest and safest to gravitate to the nearest extreme. Likewise pair programming is a grey area for me too. It's beneficial in some situations, but not in others. It's a great way for a senior developer to mentor a junior developer. But Pair Programming advocates underestimate the human factor, especially on a widely diverse team. Having to sit one foot away from another human being for any significant portion of the day can really cause issues. We wonder why there aren't more women in Computer Science. Well, for one thing, I know a few female developers, and they are very opposed to pair programming! (And I don't blame them!)
  23. Re: A very practical approach[ Go to top ]

    An experienced developer can save time by outlining their code a little before they start writing the test
    Maybe this one's personal preference but I find after switching to TDD a few years back it's become harder to outline my code without thinking in terms of tests. When this approach fails it's usually an indication of a wider problem, such as unclear requirements, external dependencies etc. There are times when forgetting about the tests and timeboxed prototyping gives best results, but I always throw away the prototype and return to TDD once I'm satisfied I'm on the right track.
    It's [pair programming's] a great way for a senior developer to mentor a junior developer.
    One of the chief benefits of pair programming is to maintain quality - it's like having a continuous code review. You could argue that experienced devs don't need someone looking over their shoulder to write good code, but in my experience even the most skilled programmers sometimes need to be held in check, especially when trying to hit a deadline. Using pair programming to mentor juniors destroys this benefit since a junior programmer is far less likely to say things like "hang on - you're getting ahead of yourself you should really write a test before you go any further".
    that is one of the most practical approaches to Agile I've seen
    Dmitriy listed a set of practices, but that doesn't make him or the company he works for agile*. What makes an organisation, team or individual agile is their ability to apply, inspect and adapt. Technical practices help to achieve this, but are insignificant next to organisation culture, team dynamics and an individuals personality. *FTR I've never met Dmitriy or anyone else from GridGain and have no reason to believe they aren't a great example of an agile shop.
  24. Re: A very practical approach[ Go to top ]

    Maybe this one's personal preference but I find after switching to TDD a few years back it's become harder to outline my code without thinking in terms of tests. When this approach fails it's usually an indication of a wider problem, such as unclear requirements, external dependencies etc.
    I have never seen clear requirements (maybe that's why I am not a fan of TDD in its pure form). I think what's important is that your code has enough JUnit coverage. Who cares if you create your JUnits before, during, or after you are done coding?
    One of the chief benefits of pair programming is to maintain quality - it's like having a continuous code review.
    I like my coffee hot, but it does not mean that I have to constantly watch over the shoulder of Starbucks employee to make sure he got the temperature right (excuse the silly analogy).
    Dmitriy listed a set of practices, but that doesn't make him or the company he works for agile*.
    I don't care if GridGain fits the definition of "pure agile" or not. What's important to me is that that I find the process we have extremely productive (by far more productive than some pure Agile shops I have seen). Our process is the end (or ongoing) result of continuously trying out various things and tossing out whatever does not work.
    I've never met Dmitriy or anyone else from GridGain and have no reason to believe they aren't a great example of an agile shop.
    Well, maybe some day ;-) Best, Dmitriy Setrakyan GridGain - Grid Computing Made Simple
  25. Re: A very practical approach[ Go to top ]

    I have never seen clear requirements (maybe that's why I am not a fan of TDD in its pure form)
    So if you don't have enough info to assert what the code should be doing, how can you write the code?
    Who cares if you create your JUnits before, during, or after you are done coding?
    I'm quite willing to accept this is a personal thing, but I find I work much better test first. The primary reason is motivation. When starting off with a red bar, I'm motivated to move it to green, writing the test is like solving a problem - I find it fun. Before I learnt TDD I wrote my unit tests after the fact, but they always felt like a chore. I believe there are other advantages too; as per the name TDD is not just about testing but also design. Working backwards from an assertion and using your IDEs refactoring / code generation tools helps create clean interfaces purpose built for the job, which is not necessarily the same as what you thought it needed to do before hand. I'm not saying you can't write clean code without TDD, just that I (and others) consistently find their code quality is higher when they do.
    I don't care if GridGain fits the definition of "pure agile" or not. What's important to me is that that I find the process we have extremely productive (by far more productive than some pure Agile shops I have seen). Our process is the end (or ongoing) result of continuously trying out various things and tossing out whatever does not work.
    I tried writing a definition of agile once and gave up very quickly. I'd also be very dubious about organisations claiming to be "pure agile", I'd suspect it meant they'd rigorously adopted a set of someone else's practices and missed the point of agile completely. Practices alone don't cut it. You need to "apply, inspect and adapt", or in your words "continuously trying out various things and tossing out whatever does not work"
    I've never met Dmitriy or anyone else from GridGain and have no reason to believe they aren't a great example of an agile shop. Well, maybe some day ;-)
    Look forward to it! Steve
  26. Re: A very practical approach[ Go to top ]

    Yes, I agree completely. The degree to which TDD works for you is very subjective. I think for a certain range of personality types that are prevelant in the development world, Unit Testing just FEELS good to them. It makes these types of people very happy and very satisfied with their job when they can click the "Run Tests" button and get the "Green" bar telling them all is well. In fact, if you read any of Kent Beck's books, there is much emphasis on the red/green bar as a motivational device for developers. (Very much like rats performing tricks for food pellets). Having constant feedback and rewards is especially motivating for many people. It practically turns coding in a game of EverQuest. :) However, many other developers are not motivated by clicking buttons for reward pellets, and they find TDD very tedious, like they are having to code everything TWICE and refactor everything twice. It more than doubles effort. In theory, that could pay for itself in the long-run, especially for objects that are complex, highly reused, or prone to change. But an experienced developer can usually afford to pick and choose his or her battles, and decide that writing a full test for a simple getter method on a class that will likely never change is just not worth the trouble. We all need to remember that very successful applications were written for decades before TDD was ever invented. Having suffienct automated test coverage still ranks low on the list of "critical success factors" for any project. This is my opinion anyway. I know many will disagree. :)
  27. Re: A very practical approach[ Go to top ]

    ...But an experienced developer can usually afford to pick and choose his or her battles, and decide that writing a full test for a simple getter method on a class that will likely never change is just not worth the trouble...
    While this is true the problem is that there are way too many pretend to be experienced developers. Then the next problem is the experience: it means that the person solved the problem before, where is guarantee that the problem at hand is indeed the problem the developer have experienced before? TDD is good - it mainly gets negative reaction from people burned by BAD and UGLY test suites, or mistakingly thinking that they must test every little method or condition. I think about tests as definitions of 'done' - there might be as many or as few as project nature dictates.
  28. Re: A very practical approach[ Go to top ]

    But an experienced developer can usually afford to pick and choose his or her battles, and decide that writing a full test for a simple getter method on a class that will likely never change is just not worth the trouble.
    Experienced is a loaded term. I knew people with over 20 years of overall software development experience who were absolutely lost when they started using Java. The bulk of their experience was in COBOL on a mainframe. My original introduction to TDD was in the book XP Installed (read it before XP Explained). There, the guideline was that you needed to write tests for anything that could possibly break. A getter that returns a member variable quite likely doesn't fall into that category. Ironically, a while back another developer and I had the same argument about testing getters & setters. I couldn't really disagree with his assertion that the simple ones didn't need testing. At the same time, I was trying out an early tool that generated tests for the methods in a class, and had applied it to something this other developer had written. The class contained several getter/setter methods and some other stuff. The first time I ran the tests, the bar was red!! The cause was a couple of copy and paste errors when the getters and setters were written - the wrong member variables were being modified in a couple of cases and returned in others. So, is it really unnecessary to test them? ;) Dave Rooney Mayford Technologies
  29. Re: A very practical approach[ Go to top ]

    Ironically, a while back another developer and I had the same argument about testing getters & setters. I couldn't really disagree with his assertion that the simple ones didn't need testing. At the same time, I was trying out an early tool that generated tests for the methods in a class, and had applied it to something this other developer had written. The class contained several getter/setter methods and some other stuff. The first time I ran the tests, the bar was red!! The cause was a couple of copy and paste errors when the getters and setters were written - the wrong member variables were being modified in a couple of cases and returned in others.

    So, is it really unnecessary to test them? ;)

    Dave Rooney
    Mayford Technologies
    I'm actually looking at Agile Methodologies, and actually my problem is 'for which methods do you need to write tests?' Ironically, You could also write tests for your test cases, because you could also make copy/paste errors. Actually, automatic testing of Service and Data Access layers make sens, but for UI it's too complex to deal with! so human tests before a release may be a better solution! You may spend more time writing tests than code, while good design and conventions may keep you from some errors and mistakes.
  30. Re: A very practical approach[ Go to top ]

    Actually, automatic testing of Service and Data Access layers make sens, but for UI it's too complex to deal with! so human tests before a release may be a better solution!

    You may spend more time writing tests than code, while good design and conventions may keep you from some errors and mistakes.
    Yes, you need to be pragmatic. Even 100% unit test coverage does not guarantee that there will be no defects. You can write the UI test-first, but it's a departure from how most of us have built UI code. It's also quite difficult to apply unit tests to UI code after the fact. You can also make the UI so thin that it contains very little code. Then you can test-drive the code just below the UI. The less code you have in your UI, the less likely it is to contain business logic, either explicitly or implicitly. If it contains no business logic, then there is less chance that having no tests will be a problem. That's not a testing issue, though, but rather the implementation of proper system design. Sticking with the UI for a moment, something for which I wouldn't use tests is to verify that a control is in a particular position, etc. That's something that can be tested in seconds by a human being! Also, unit tests are precisely that - unit tests. You need integration and system level tests, as well as good ole exploratory testing by cunning and devious testers who will do things that no normal user would ever dream of doing to your application! :) In summary, unit tests are an excellent addition to your toolbox for writing better quality code. They should not be the only tool in your toolbox, though. Dave Rooney Mayford Technologies
  31. Re: Agile = Use What Works[ Go to top ]

    I agree that pair-programming is not for everyone and everyday. There is a book "The art of Agile Development" that gives some suggestion on how it can be done.
  32. Some points about Agile[ Go to top ]

    Some points about Agile: - It seems growing because it has become fashionable to say "Agile", especially for manager types, because it gives them an impression of speed. From the technical side people will cherrypick those aspects of it that match what they currently do and call it "Agile", this way they look trendy and satisfy their managers at the same time; - Agile itself doesn't work, because it is impossible to develop an application from tests. TDD is ludicrous. What people do is the same design they would do in other methods, but instead of documenting it they keep it informal. That's the only way Agile can work; - Agile as a whole look like Islam. It has a holy book where the prophet dictates the laws (TDD, pair programming, daily meetings, etc). If you follow them then you will be rewarded with a place in heaven while the infidels (the ones that didn't buy into TDD) will burn in hell. Is there any reason to believe so? No, but they just do. I love the part when believers are explaining the "beauty" of it, and the better software developers (at least if compared to the fanatic one) that happen to be around are usually thinking (check, WTF!, not good, check...). Then the believer will come up with some "Hello World" example of how TDD works to illustrate how it revolutionalizes development (at this point everybody remembers endless flamewars on Slashdot over which language is better, where the arguments are usually "how many keystrokes it takes for me to print Hello World to the console", while the more experienced developers recall a dozen cases where if some design upfront hadn't been done they would be screwed in future releases). Finally, after evangelizing others the fanatic checks what's the latest in the InfoPoo site. Oh boy, I wish I had chosen Mathematics when I went to college. Maybe it's not too late! IT is full of morons.
  33. Re: Some points about Agile[ Go to top ]

    Oh boy, I wish I had chosen Mathematics when I went to college. Maybe it's not too late! IT is full of morons.
    Who wants to chip in and help send Thiago back to school? :)
  34. Re: Some points about Agile[ Go to top ]

    Oh boy, I wish I had chosen Mathematics when I went to college. Maybe it's not too late! IT is full of morons.

    Who wants to chip in and help send Thiago back to school? :)
    Definitely not. It's good to have guys like him working for the competition.
  35. Re: Some points about Agile[ Go to top ]

    Oh boy, I wish I had chosen Mathematics when I went to college. Maybe it's not too late! IT is full of morons.

    Who wants to chip in and help send Thiago back to school? :)

    Definitely not. It's good to have guys like him working for the competition.
    If infer "Agile works". This is as logical as you can get. At least we can have a few laughs at you, please continue! It is entertaining.
  36. Haha[ Go to top ]

    TDD is to grope in the darkness until one finds the way out. The practioners of it are either willingly living in the darkness or, worse, are blind.
  37. Re: Haha[ Go to top ]

    TDD is to grope in the darkness until one finds the way out. The practioners of it are either willingly living in the darkness or, worse, are blind.
    One wonders who's groping (for what/for who/...)
  38. Agile is about Agile Manifesto[ Go to top ]

    A company is Agile if it follow principles of Agile Manifesto: customer satisfaction, changing requirements, working software etc. TDD, pair programming, Scrum meetings are just practices of mostly used Agile methods (XP and Scrum). People seem to forget that there are also many other Agile methods which are unfortunately often ignored when talking about Agile. Also, practices may vary in different methods: XP focuses on pair programming but FDD emphasizes inspections (and code ownership). Scrum itself does not offer coding practices at all. Companies may use Agile a marketing trick, but only companies following Agile principles truly will success. With or without individual practices such as TDD.
  39. Agile is about Agile Manifesto[ Go to top ]

    Tomi, I totally agree with you. You are the only impressive post I read in this thread. Regards
  40. Vote Agile for President in 2008![ Go to top ]

    A company is Agile if it follow principles of Agile Manifesto: customer satisfaction, changing requirements, working software etc.
    You forgot "curing cancer" .. Seriously, those are not "Agile principles", they are just common sense. Oops, I mean "Common Sense (tm) Manifesto principles" ;-) Peace, Cameron Purdy Oracle Coherence: Data Grid for Java and .NET
  41. Again[ Go to top ]

    + 1 for Cameron. This is my primary problem with these people : too much marketing about the brand name "agile" and nothing new to offer. It's not only that it is obnoxious. The confusion that results can make it more difficult to follow effective software processes - and harder than ever to discriminate experienced and skilled practitioners from marketeers. Waterfall worked fine. The banks most of us use built their deposit systems using COBOL and a waterfall process. If there's anything to take away from the last 50 years of practice, it's this : people and culture matter much more than process. Yeah, they are all important ... but with people committed to quality working with each other, many software development approaches will work. One of the ironies of Fragile marketing, for me, is that it started with this basic concept and is now being sold based on a set of specific techniques. We don't need to get hung up on this or that technique. There will always be salesmen, but there's no need to for the IT community to support this kind of nonsense.
  42. Re: Again[ Go to top ]

    If there's anything to take away from the last 50 years of practice, it's this : people and culture matter much more than process. Yeah, they are all important ... but with people committed to quality working with each other, many software development approaches will work. One of the ironies of Fragile marketing, for me, is that it started with this basic concept and is now being sold based on a set of specific techniques. We don't need to get hung up on this or that technique.

    There will always be salesmen, but there's no need to for the IT community to support this kind of nonsense.
    +1 You've said it perfectly.
  43. The Label is not the thing[ Go to top ]

    + 1 for Cameron.

    This is my primary problem with these people : too much marketing about the brand name "agile" and nothing new to offer.

    It's not only that it is obnoxious. The confusion that results can make it more difficult to follow effective software processes - and harder than ever to discriminate experienced and skilled practitioners from marketeers.

    Waterfall worked fine. The banks most of us use built their deposit systems using COBOL and a waterfall process.

    If there's anything to take away from the last 50 years of practice, it's this : people and culture matter much more than process. Yeah, they are all important ... but with people committed to quality working with each other, many software development approaches will work. One of the ironies of Fragile marketing, for me, is that it started with this basic concept and is now being sold based on a set of specific techniques. We don't need to get hung up on this or that technique.

    There will always be salesmen, but there's no need to for the IT community to support this kind of nonsense.
    Hi Cameron, I agree with everything you say. The simple truth is that marketing does count in our business. Everyone is looking for "The Silver Bullet" and very few are willing to accept that in the end success will comes down to a "few good men/women". If they were we would all be using Lisp and things like JSF would not see the light of day (I am only joking, just :^)) Kent Beck did a good job at marketing XP, but XP is not Agile it is just a bunch of practices. XP added technical practices to the ideas in Scrum, which in turn built on Japanese ideas for new product development and manufacturing. These root ideas were developed in Japan after WWII and inspired by the work of Deming and have been marketed in the West under several labels, such as JIT, TQM, Six Sigma, Lean etc. The thing to remember is that the label is not the thing. The map is not the territory. Agile is just a label, just like TQM is just a label. Sending your Management on a TQM course doesn't mean that you are ready to compete with Toyota. Here is a quote that sums it up for me:
    We will win and you will lose. You cannot do anything because your failure is an internal disease. Your companies are based on Taylor’s principles. Worse, your heads are Taylorized too. You firmly believe that sound management means executives on the one side and workers on the other, on the one side men who think and on the other side men who only work.” Konusuke Matsushita - Panasonic
    When "Agile" people say that you either get it or you don't this is what they mean. Unfortunately in an IT culture dominated by marketing messages such a statement as this is often misconstrued as yet more marketing :) Paul.
  44. Re: The Label is not the thing[ Go to top ]

    We will win and you will lose. You cannot do anything because your failure is an internal disease. Your companies are based on Taylor’s principles. Worse, your heads are Taylorized too. You firmly believe that sound management means executives on the one side and workers on the other, on the one side men who think and on the other side men who only work.”

    Konusuke Matsushita - Panasonic
    Nice, Paul. I think I'll have to steal that one! :) Dave Rooney Mayford Technologies
  45. Re: Again[ Go to top ]

    This is my primary problem with these people : too much marketing about the brand name "agile" and nothing new to offer.
    Anyone who tells you that the XP practices are new is full of it. They have been packaged differently in order to enhance one another, but the originators never said that they were new.
    Waterfall worked fine. The banks most of us use built their deposit systems using COBOL and a waterfall process.
    Yes, they did ship systems. Do you know why concepts such as the "glass wall" between users and what was then called MIS exist? Because to use such a process they had to strictly control any changes. The result was that when a system was delivered it was already 12-18 months out of date. Any enhancements took equally long times to implement. IT was more of a burden than a strategic advantage for companies. That's why PC's and PC-based software exploded in the 80's. Suddenly people were empowered and didn't have to bow at the IT altar in order to get something done. So, tell me again why Waterfall was so good! :)
    If there's anything to take away from the last 50 years of practice, it's this : people and culture matter much more than process.
    Yes... HELL yes!
    Yeah, they are all important ... but with people committed to quality working with each other, many software development approaches will work.
    Hell yes, again!
    One of the ironies of Fragile marketing, for me, is that it started with this basic concept and is now being sold based on a set of specific techniques. We don't need to get hung up on this or that technique.
    I don't disagree, but I have a problem with leaving everyone to pick and choose what they think will work for them. I'm not convinced, for example, that the majority of developers would simply ignore unit testing altogether, let alone TDD. If we don't explore different ways of building software, we'll never improve the craft. Dave Rooney Mayford Technologies
  46. Re: Again[ Go to top ]

    Waterfall worked fine. The banks most of us use built their deposit systems using COBOL and a waterfall process.
    Waterfall is "fine" at best. I've worked with COBOL mainframes that had fixed "minor" change windows 3 months apart. The major ones were 6 months apart. Often we found during testing that requirements captured 2-5 months ago had either changed or been missed but because development was so slow they couldn't be added in time for the change window. This impacted other projects developed with more flexible processes and tools and became the bottleneck of the whole program. As a result we had to add bastardise the roles of some of the other systems to compensate. Compare this to the last two agile projects I've worked on - one had weekly delivery to live, the other fortnightly. "Fine" isn't good enough - we should be striving for excellence.
  47. Re: Again[ Go to top ]

    Waterfall worked fine. The banks most of us use built their deposit systems using COBOL and a waterfall process.
    ... Compare this to the last two agile projects I've worked on - one had weekly delivery to live, the other fortnightly. "Fine" isn't good enough - we should be striving for excellence.
    Hi Steve, This is the problem. Low expectations. The way the Software Industry beats its own drum some one visiting from Mars would never know that we've been consistently failing our customers for decades. The consequence? The business doesn't trust us any more and would rather bet on "Snake Oil" from vendors. The worst of it is that we have low expectations of our developers and are always looking for ways to dumb down. After working as both a Manager and a Developer, I believe that the whole waterfall approach arose from a culture that says that some people should think and others should just code. Command and control, Taylor style. I don't believe that Royce's work was misconstrued by mistake. I'm just coming off a project now where the team was self organised and empowered, delivering real value to the customer on a regular basis. Everyone was happy except the IT Management. IT management didn't like the idea of the "team deciding for themselves". So despite happy customers the "Agile Bubble" has been popped and command and control restored. They prefer to go back to their past track record of failure, rather than re-evaluate their Taylorist principles. This is not uncommon and I know that you have experienced the same. Paul.
  48. Re: Again[ Go to top ]

    The worst of it is that we have low expectations of our developers and are always looking for ways to dumb down. After working as both a Manager and a Developer, I believe that the whole waterfall approach arose from a culture that says that some people should think and others should just code. Command and control, Taylor style.
    +1. The difference isn't about practices such as TDD, pair programming, continuous integration, etc. Those can be used on any kind of project - but they don't affect or reflect how the project is being managed and led. I think the difference of what we refer to as Waterfall and Agile is a style of management. It's an issue of how the leaders lead. In the software industry, for better or for worse, we have labels such as "Waterfall" and "Agile" to throw around, but this issue is in every industry and in every organization that has some concept of leadership. When you read the Agile Manifesto, note that it's not about practices, or languages, or technologies. It's about a management style, a style of leading an organization that is very different from the typical command and control, which is still frequently used, particularly in government contracting. The Lean Software Development books do a great job of explaining this. I think it really boils down to how contracts are defined. Things like TDD and continuous integration are just lower-level details.
  49. Re: Again[ Go to top ]

    Waterfall is "fine" at best. I've worked with COBOL mainframes that had fixed "minor" change windows 3 months apart. The major ones were 6 months apart. Often we found during testing that requirements captured 2-5 months ago had either changed or been missed but because development was so slow they couldn't be added in time for the change window. This impacted other projects developed with more flexible processes and tools and became the bottleneck of the whole program. As a result we had to add bastardise the roles of some of the other systems to compensate.
    Were the other projects operating in a similar technological environment, or were they using more modern technologies? Was your project dealing with mission critical components? Were the other, more agile projects? What was the cost of change associated with major changes for the business, excluding the cost of developing and deploying the software?
    Compare this to the last two agile projects I've worked on - one had weekly delivery to live, the other fortnightly. "Fine" isn't good enough - we should be striving for excellence.
    Were these agile projects dealing with the same type of software developed on the same type of technologies? Did they have an equivalently large base of legacy code?
  50. Re: Again[ Go to top ]

    It's true, I'm not comparing like for like, however that was never my intention. In Ethen's post he stated that
    Waterfall worked fine. The banks most of us use built their deposit systems using COBOL and a waterfall process.
    In my response I made reference to an application developed in COBOL and using a waterfall process that was anything but fine. It wasn't that the developers or tools who were to blame, it was the process and inability to handle change that caused the problems. Not every waterfall project will be this bad, but no reasonably sized waterfall project will ever be able to achieve sustained weekly releases. For well run agile projects (even established, mission critical ones) this is a reality.
  51. Re: Again[ Go to top ]

    Not every waterfall project will be this bad, but no reasonably sized waterfall project will ever be able to achieve sustained weekly releases.
    By "weekly releases" do you mean "something that 'works' and the customer can touch" or "production deployments?" There are many cases where weekly deployment of major changes would be highly undesirable for a business.
  52. Re: Again[ Go to top ]

    Not every waterfall project will be this bad, but no reasonably sized waterfall project will ever be able to achieve sustained weekly releases.


    By "weekly releases" do you mean "something that 'works' and the customer can touch" or "production deployments?"
    I mean deploying a new version of the application to live on weekly basis.
    There are many cases where weekly deployment of major changes would be highly undesirable for a business.
    I've worked on agile projects where we did this . We didn't always manage to get everything we'd planned into the week, and sometimes there were business reasons not to go live - Christmas production freeze, synchonrisation with advertising, etc. Rather than being 'highly undesirable' it's a massive de-risking factor to develop the high priority functionality first and actually see it working, as opposed to batching everything up into a three month, six month or even yearly releases and hoping that in the few weeks available for testing there's enough time to fix the important stuff. The ability to change tack on a whim can also be a huge advantage. My last client is a media organisation. Towards the tail end of last year there was a strong possibility of a the British PM calling a general election. Because they were capable of fortnightly releases, and the previously developed parts of the application were already in production, the business had the option of reacting. This wouldn't have been possible with a waterfall project because rather than running on a production server the code would still be sitting in source control, without UAT or integration testing with high priority functionality potentially still in development. Something else you said I also found interesting
    Why would I ramp up my expectations of my leadership by an entire order of magnitude when they aren't meeting my current expectations? Good leaders are really hard to find. It seems to me that any methodology that requires more out of leadership is doomed to fail.
    One of the nice things about agile projects is visibility. With waterfall you can usually expect software at best every three months. You will probably have weekly status meetings were everyone sits on a conference call hoping/pretending their part of the project is going to be ready on time, but secretly wishing for someone else to own up to slippage first and give them breathing space. I've worked on waterfall projects where it took until the week before go-live for the PM of one component to admit he was going to slip by a month. With all the agile projects I've worked on the product owner gets a demo of the software after every iteration (typically be every 1 to 4 weeks), making it much harder to hide problems until the last minute.
    One of my biggest qualms with Agile methodologies as they are often defined is that they seem to push responsibility onto those who are least able to meet it, such as the customers and project leaders.
    When done right Agile methodologies push responsibility where it belongs. Rather than a BA extracting requirements from several equally senior members of staff then having to negotiate their priority, it forces the customer to provide a "single wringable neck". New product owners will need coaching, but once up to speed having a single person empowered to make decisions strips out swathes of bureaucracy and waste. Technical decisions become the responsibility of the team building the application. The team has to be cross functional. It's no good just having seasoned developers, you need sys-admins, dbas etc too. This scares some people and often upsets architects and shared infrastructure teams (not to mention furniture police), but once again it's about empowerment (or wringable necks). An architect's job ends with a document. A shared infrastructure team are often too busy to give any one project the attention it deserves. It's better to give technical responsibility to the team doing the work and to make sure they have all the skills, experience and resources necessary.
  53. Re: Again[ Go to top ]

    I've worked on agile projects where we did this . We didn't always manage to get everything we'd planned into the week, and sometimes there were business reasons not to go live - Christmas production freeze, synchonrisation with advertising, etc. Rather than being 'highly undesirable' it's a massive de-risking factor to develop the high priority functionality first and actually see it working, as opposed to batching everything up into a three month, six month or even yearly releases and hoping that in the few weeks available for testing there's enough time to fix the important stuff.
    I'd like to point out that there is nothing inherently mutually exclusive between my statement and your statements. A common example is training. Even minor changes can cause huge amounts of training material to be reworked. Major changes require people to be retrained. This can be extremely expensive. Or consider resource scheduling. Let's say a manufacturer makes contractual commitments based on the schedules produced by its ERP system. Having a better scheduling algorithm could be a major competitive advantage for a variety of reasons, however having contractually committed delivery dates magically shuffle themselves one week can be hugely detrimental. These type of changes require an enormous amount of organizational coordination so that all the potential impacts of a change can be assessed and people can be prepared to deal with the change once it happens.
    When done right Agile methodologies push responsibility where it belongs. Rather than a BA extracting requirements from several equally senior members of staff then having to negotiate their priority, it forces the customer to provide a "single wringable neck". New product owners will need coaching, but once up to speed having a single person empowered to make decisions strips out swathes of bureaucracy and waste. Technical decisions become the responsibility of the team building the application. The team has to be cross functional. It's no good just having seasoned developers, you need sys-admins, dbas etc too.
    If it's important that technical decisions be made be a cross-functional technical team, why wouldn't it be equally important for the requirements decisions to be made by a cross-functional business team? I agree that there should be someone with the authority and reputation to cut the crap and make a decision. The problem is that relying on such a person from the business team is about as effective as relying on an architect-on-high to be the ultimate authority in technical decisions.
    This scares some people and often upsets architects and shared infrastructure teams (not to mention furniture police), but once again it's about empowerment (or wringable necks). An architect's job ends with a document.
    I wouldn't call the person an architect, but I hear you...
    A shared infrastructure team are often too busy to give any one project the attention it deserves. It's better to give technical responsibility to the team doing the work and to make sure they have all the skills, experience and resources necessary.
    This is a case of macro versus micro optimization. Project teams want to optimize their project, so they wanted dedicated team members working on dedicated equipment. CIOs want to reduce their data center and operational costs, so they want share services organizations on standardized hardware, and preferably shared, hardware. A good shared services organization can actually be a real boon for a agile (with a little "a") project. If they are technically skilled and concerned with customer service. Of course, that isn't always the case...
  54. Re: Again[ Go to top ]

    I'd like to point out that there is nothing inherently mutually exclusive between my statement and your statements.

    A common example is training. Even minor changes can cause huge amounts of training material to be reworked. Major changes require people to be retrained. This can be extremely expensive.

    Or consider resource scheduling. Let's say a manufacturer makes contractual commitments based on the schedules produced by its ERP system. Having a better scheduling algorithm could be a major competitive advantage for a variety of reasons, however having contractually committed delivery dates magically shuffle themselves one week can be hugely detrimental. These type of changes require an enormous amount of organizational coordination so that all the potential impacts of a change can be assessed and people can be prepared to deal with the change once it happens.
    In these scenarios I'd still expect an effective agile team to deploy each iterations work to a demo environment that mirrored production as closely as possible using the same automated deployment process. That way you'd still have a good level of risk mitigation and the benefit of early feedback without having to retrain everyone / break your contractual obligations.
    If it's important that technical decisions be made be a cross-functional technical team, why wouldn't it be equally important for the requirements decisions to be made by a cross-functional business team
    Two reasons. 1. Time to make decisions. Having a single product owner, who's co-located with the technical team means developers and QA's can get instant clarification of requirements and frequent feedback. They can ask questions like "this feature is likely to take 3 days to write, however with this compromise, I can do it in 1 day. Which would you prefer?". Unless there is a single product owner, any decision has to be put to committee. 2. The technical team have a single objective - to deliver valuable working software at the end of each iteration. The business team would be made up of people with different objectives (with financial reward for meeting them). Attempting to get this team to prioritise work for a release would be a nightmare.
    This is a case of macro versus micro optimization. Project teams want to optimize their project, so they wanted dedicated team members working on dedicated equipment. CIOs want to reduce their data center and operational costs, so they want share services organizations on standardized hardware, and preferably shared, hardware. A good shared services organization can actually be a real boon for a agile (with a little "a") project. If they are technically skilled and concerned with customer service. Of course, that isn't always the case...
    In practice (especially for large companies new to agile) there is a balance. At the start of the agile project, when the team has no credibility the balance is weighted towards the macro optimisation. As the team succeeds they gain trust and respect that can be used to shift the balance in favour of micro optimisation. Ultimately though if an external dependency isn't working it's up to the coach to find a solution. This is often one of the his/her biggest challenges, because major oganisational changes require backing by someone with serious political clout to go into bat. I've seen it make or break agile projects.
  55. Re: Again[ Go to top ]

    blockquote>If it's important that technical decisions be made be a cross-functional technical team, why wouldn't it be equally important for the requirements decisions to be made by a cross-functional business team

    Two reasons.

    1. Time to make decisions. Having a single product owner, who's co-located with the technical team means developers and QA's can get instant clarification of requirements and frequent feedback. They can ask questions like "this feature is likely to take 3 days to write, however with this compromise, I can do it in 1 day. Which would you prefer?". Unless there is a single product owner, any decision has to be put to committee.

    2. The technical team have a single objective - to deliver valuable working software at the end of each iteration. The business team would be made up of people with different objectives (with financial reward for meeting them). Attempting to get this team to prioritise work for a release would be a nightmare. [emphasis mine] I want you to think about the part of the statement that I bolded. I agree with it 100%. I think this is one of the most problematic aspects of business-focused IT projects, especially software development projects. Businesses build/buy software application in order to help them achieve one or more objectives. Those objectives drive requirements. If those objectives are unstable, the requirements will be unstable. If those objectives don't have business value, any applications implemented to achieve them will not have business value. That means that if the person from the customer team who is tasked with communicating those objectives and the requirements derived from them hasn't stablized those objectives in a manner that will produce business value, the project will flounder, or quite likely produce shelfware as the successfully implemented system has no real utility in the business. Basically what is being done in Agile, as you are desribing it, is the traditional business analyst role is being shifted from a technical role to a customer role. That's not a bad idea, although I think it forgoes some opportunities. In my experience it takes 3-12 months, with an average of about 6, to poke and prod stakeholders into articulating their objectives and then getting their buyin on a unified set. This also means commiting to the necessary business process changes necessary to achieve the objectives. When this is not done, or is done poorly, projects fail to deliver value even when they succeed at delivering working software. In my opinion, most projects don't fail because of poor or unstable requirements. They fail because of poor or unstable objectives. As far as I can tell, Agile methodologies circumvent this problem by defining limiting the responsibility of the implementation team to implementing what the customer requests. The customer is responsible for requesting the right functionality. Essentially it decouples the success of the implementation team from the success of the business. I find that decoupling very worrisome.
  56. Re: Again[ Go to top ]

    The customer is responsible for requesting the right functionality. Essentially it decouples the success of the implementation team from the success of the business.

    I find that decoupling very worrisome.
    I find that it places the responsibility where it belongs. IT is an investment by the business, if the business make poor IT investments then it will get poor returns. It is that simple. No different then poor capital investments into the wrong type of Plant etc. In my experience it works a lot better then IT trying to double guess what the business should be investing their money in. After all "The Business" should know their business better then us. First, the fast delivery and quick feedback of Agile teams allows the business to tell very quickly whether a project is delivering the value they expected. If you are delivering to live on a weekly basis it doesn't take the business long to realise that the app isn't helping as much as they first thought it would. At this point they can alter their vision and steer the project in a new direction (they own the backlog) or they can choose to cancel the project all together. It is their call as customer. As Steve as mentioned, the customer role is crucial and most customers require coaching, but they soon get into the swing of things and they like the idea of being directly in control, rather then delegating to IT. Incidentally the use of real world feedback can be taken even further. On a number of social networking websites today Agile teams are adding features before the customer requests them in a semi-speculatively manner. Features that users bite on and prove popular are developed further, others are allowed to wither and die. Again if you can deliver fast, you can use this type of real world feedback to drive the requirements of the system. In my experience such approaches are much more accurate then a six months paper exercise. After six months you are still taking a gamble on what to build, and you will not get any real world feedback until another six months in which time even if you guessed right, the world may have changed! Paul.
  57. Re: Again[ Go to top ]

    I find that it places the responsibility where it belongs. IT is an investment by the business, if the business make poor IT investments then it will get poor returns. It is that simple. No different then poor capital investments into the wrong type of Plant etc.
    That's correct.
    In my experience it works a lot better then IT trying to double guess what the business should be investing their money in. After all "The Business" should know their business better then us.
    True.
    First, the fast delivery and quick feedback of Agile teams allows the business to tell very quickly whether a project is delivering the value they expected.
    That assumes that the value is quickly measureable. It can take months to years to measure the return on a strategic investment.
    As Steve as mentioned, the customer role is crucial and most customers require coaching, but they soon get into the swing of things and they like the idea of being directly in control, rather then delegating to IT.
    My issue with Steve's statements wasn't that he expected the customer to get its act together. My issue is that he said that the technical team needs to be isolated from the diversity of objectives that exist within in the business, because there's no way to build software to all those conflicting objectives and priorities. I've seen millions of dollars burned this way, followed by millions more to address core issues that were disregarded in the initial implementation. That's on projects with rapid, incremental releases to a production environments.
    If you are delivering to live on a weekly basis it doesn't take the business long to realise that the app isn't helping as much as they first thought it would. At this point they can alter their vision and steer the project in a new direction (they own the backlog) or they can choose to cancel the project all together. It is their call as customer.
    Again, you are assuming that the application is addressing a problem where a tight feedback loop is possible. Many business processes operate on cycles that are a month or longer. That means it can take months to acquire a decent sampling of subjective feedback. Objective measures take even longer. Actual returns on an investment targeting processes at the early stage (e.g. R&D) of a product cycle may take years to appear, but that's when the results show up on the market. The bottom line is that your feedback mechanisms have to be in tune with what you are measuring. Feeding weekly changes into a system that operates on monthly (or longer)cycles simply ensures that there's too much noise to measure anything.
  58. Re: Again[ Go to top ]

    Again, you are assuming that the application is addressing a problem where a tight feedback loop is possible. Many business processes operate on cycles that are a month or longer. That means it can take months to acquire a decent sampling of subjective feedback. Objective measures take even longer. Actual returns on an investment targeting processes at the early stage (e.g. R&D) of a product cycle may take years to appear, but that's when the results show up on the market.

    The bottom line is that your feedback mechanisms have to be in tune with what you are measuring. Feeding weekly changes into a system that operates on monthly (or longer)cycles simply ensures that there's too much noise to measure anything.
    Yes I did assume. Feedback doesn't need to be quantitative, it could be qualitative, like the result of a survey asking the question "Are you more or less productive?" and "what would you change in the system ?" This could be collected relatively quickly. In the end you are right, Agile methods are suited to dealing with rapid change, if you are in an environment that changes very slowly then Agile approaches are less compelling. A lot of what Agile approaches offer though may still be attractive to you. You need to choose what works best for you. There is a lot to be said for the buzz and the energy of an Agile team. Empowering the team allows people to innovate in the way they solve technical problems and this tends to energise people. People seem to like being self directed rather than being told what to do. Customers love the idea of seeing what they are getting on a regular interval, rather then just ploughing money in and having to trust they will eventually get something in return, and this energises them too. You may need to heavily tailor an off the shelf Agile methodology to suite you or maybe go for something like DSDM or Feature Driven Design, but there is an intangible benefit to Agile values and principles, that is difficult to explain and which I only "got" once I experienced it. I would never go back. Paul.
  59. Envisioning the "System to be"[ Go to top ]

    The customer is responsible for requesting the right functionality. Essentially it decouples the success of the implementation team from the success of the business.
    Hi Eric, Your last point got me thinking. The business should be responsible for requesting the right functionality. I believe this to be correct thing, but how are they to know what is right and do they need help? This is where Agility must go beyond the software team and where the current crop of Agile methodologies do not offer much guidance IMO. I came across some interesting approaches to envisioning systems at XPDay one year. The problem seems to be that people don't really know what they want until they experience it. It is the Sony Walkman factor. Who would have guessed that walking around in public with headphones on your head would turn out to be a cool thing to do :). There are TQM/Six Sigma "process improvement" approaches to defining "systems to be" like QITs/PDCA and value stream mapping, but these are a bit dry and don't account for how people will react to the system when they get it. Will they like it? Will it make them enjoy their jobs more? Or will they end up using it in ways that the customer never even thought of? These "human factors" can't really be calculated in advance and may make the difference between success and failure. One approach is to use "Interaction Designers" who are expert in designing how the user will interact with the system, they could be used to assist the customer in formulating his backlog. Jim Highsmith as written a number of books on Envisioning systems and innovation. My view is that the Agile practices we have now solve the technical part of the problem "How to implement the system, provide feedback and react to business needs quickly", but I think you are right, this doesn't help the business envision the system they want in the first place. "Inspect and adapt" is one approach to getting to where you need to be, which the fast and frequent delivery of Agile teams facilitates, but an "inspect and adapt" approach wouldn't have resulted in the Sony Walkman or the iPhone, or would it? I believe this is where the cutting edge of Agility is moving next. It is an interesting area and is tied up with the whole idea of how do you innovate? In the past we never got to ask such questions, just delivering working software on time was an achievement in itself :^) Paul.
  60. Jim Highsmith as written a number of books on Envisioning systems and innovation. My view is that the Agile practices we have now solve the technical part of the problem "How to implement the system, provide feedback and react to business needs quickly", but I think you are right, this doesn't help the business envision the system they want in the first place.
    Yes!!!!!
    Jim Highsmith as written a number of books on Envisioning systems and innovation. My view is that the Agile practices we have now solve the technical part of the problem "How to implement the system, provide feedback and react to business needs quickly", but I think you are right, this doesn't help the business envision the system they want in the first place.
    I've added his book on agile project management to my Amazon wishlist. Too bad my reading backlog is so long.
    I believe this is where the cutting edge of Agility is moving next. It is an interesting area and is tied up with the whole idea of how do you innovate? In the past we never got to ask such questions, just delivering working software on time was an achievement in itself :^)
    We know how to deliver working software. The problem is that all too often we ignore that knowledge. I think innovation is critical. Not just because it extends the state-of-the-art, but because when you are pursueing something innovative the team is more likely to forget about their normal territorialism and strictly define bounds, because it is exciting!
  61. oops, my quotes were a little screwed up in that last message...
  62. Re: Again[ Go to top ]

    2. The technical team have a single objective - to deliver valuable working software at the end of each iteration. The business team would be made up of people with different objectives (with financial reward for meeting them). Attempting to get this team to prioritise work for a release would be a nightmare.
    I want you to think about the part of the statement that I bolded. I agree with it 100%. I think this is one of the most problematic aspects of business-focused IT projects, especially software development projects.
    Ok - I gave it a couple of days ;)
    In my opinion, most projects don't fail because of poor or unstable requirements. They fail because of poor or unstable objectives. As far as I can tell, Agile methodologies circumvent this problem by defining limiting the responsibility of the implementation team to implementing what the customer requests. The customer is responsible for requesting the right functionality. Essentially it decouples the success of the implementation team from the success of the business. I find that decoupling very worrisome.
    I think it is a practical separation of concerns.
    My issue with Steve's statements wasn't that he expected the customer to get its act together. My issue is that he said that the technical team needs to be isolated from the diversity of objectives that exist within in the business, because there's no way to build software to all those conflicting objectives and priorities.
    Objectives and priorities should to be determined before work is given to the technical team (that's not to say they can't change in subsequent iterations). If this is what you mean by decoupling then I don't understand why you find this worrying. What you may have meant (sorry If I'm putting words in your mouth) is that having the objectives set and prioritised by a single product owner rather than comittee increases the risk of the product being worthless. I've been lucky enough to work on agile projects that due to the nature of their business didn't have opposing objectives, and did have excellent, business savvy product owners. That said agile processes do have some mitigating steps to help prevent the software becoming a white elephant. 1. The coach doesn't just mentor the technical team, but also the product owner. Just because the product owner's word is final, it doesn't mean that the other stakeholders aren't involved in the decisions. If the other stakeholders feel that their objectives aren't being met by the story backlog the business need to find a way to resovle this. The coach should also help guide the product owner if he/she is overly biased in a particular area. 2. The application should be demonstrated to all the stakeholders after every iteration. It will clear to them if their needs aren't being met and they must be able to take some kind of action in this event. This is not necessarily the case for waterfall where the business are asked to sign off a thick and usually dry requirements document. The next time they get to see whether the application meets their needs is is six to nine months time. At this point it becomes a big bun fight as to whether the requirements were incorrectly captured or implemented. 3. It's sounds crazy but it's often easier to abort an agile project that's delivering software every week than a waterfall project that hasn't delivered anything in over a year. The reason is that the agile project has provided return on investment, where as the waterfall project is "just needs another six weeks" Sorry if this doesn't address the point you were trying to make. I'm still not sure I understood you correctly. Steve
  63. Re: Again[ Go to top ]

    Objectives and priorities should to be determined before work is given to the technical team (that's not to say they can't change in subsequent iterations). If this is what you mean by decoupling then I don't understand why you find this worrying.
    Because I think the setting of objectives and priorities is a fundamental part of a good software development process.
    What you may have meant (sorry If I'm putting words in your mouth) is that having the objectives set and prioritised by a single product owner rather than comittee increases the risk of the product being worthless.
    I don't like committees, either. I don't have a problem with the authority of the product owner, assuming he's accountable to the right stakeholders (big assumption). I have a problem with isolating the technical team from the volatility. Sometimes volatility around a requirement really means that the requirement is to make the application configurable. Other times it is merely an indication of how effort should be prioritized. It may represent a place where an application should be designed to be extensible, or possibly an area where only minimal investment should be applied until the requirement stablizes. Maybe some prototyping is in order instead of writing production-ready code is in order. Another issue I have, which I only just realized, is that I think postponing technical activities until after objectives have been established and prioritized increases risk and stifles innovation. For one, often times there are risky architectural pieces that can be proven out independently of the detailed requirements or stable priorities. More importantly, demonstrable software (as opposed to deployable) has a way of making intangible things tangible. This can be a huge benefit in flushing out objectives and priorities. Also, business teams often have a distorted sense of how difficult given pieces of functionality are to achieve in software. They will think that near impossible functionality is easy and easy functionality is near impossible. Having a technical person working with them can really help steer their objectives towards something achievable. Anyway, in my opinion most failures are caused by poor objectives (undefined, unstable, inappropriate, etc). They cause the downstream problems. Consequently, in my opinion, and process that assumes these are determined apriori and reasonably stable is not that different than a waterfall process.
  64. Re: Again[ Go to top ]

    Were the other projects operating in a similar technological environment, or were they using more modern technologies?

    Was your project dealing with mission critical components? Were the other, more agile projects?

    What was the cost of change associated with major changes for the business, excluding the cost of developing and deploying the software?



    Were these agile projects dealing with the same type of software developed on the same type of technologies? Did they have an equivalently large base of legacy code?
    Hi Erik, Your questions miss the point. Project success has very little to do with technology and tools. By far the most significant factor is leadership. Even when I worked on Waterfall projects, leadership was the most significant "success" factor. Agile is just explicit about this and ramps up leadership expectations ten fold. Even in "XP Explained" (first edition) Kent Becks stresses the need for a Coach as leader, someone who has done it before, and can convey Agile values and principles to the team. He says the team should self organise and decide their own process themselves guided by a number of values which he describes at length: Communication, Simplicity, Feedback, Courage. Even though XP provides a template, it is not prescriptive. BTW in the back of the book Kent identifies projects were he believes his suggested template (XP) may not be the most appropriate choice. The team must decide. An empowered team with the right values and principles will experiment and find good solutions to their own problems. Agile is not about tools or practices, the team decides these for themselves, Agile is about leadership, empowerment, values and principles. The point has already been made:
    When you read the Agile Manifesto, note that it's not about practices, or languages, or technologies. It's about a management style, a style of leading an organization that is very different from the typical command and control, which is still frequently used, particularly in government contracting. The Lean Software Development books do a great job of explaining this. I think it really boils down to how contracts are defined. Things like TDD and continuous integration are just lower-level details.
    People focus too much on tools, practices and technology and forget people. Take a look at Scrum or Crystal Clear or Lean Software development and you will see that at the core Agility is all about leadership and people not tools and practices. These focus solely on the software management process and people, even going as far as to address the importance of office layout when it comes to osmotic communication. They choose to say very little about specific technical practices on the assumption that such things have been adequately addressed elsewhere and are less important. Paul.
  65. Re: Again[ Go to top ]

    Paul,
    Project success has very little to do with technology and tools.
    Developing many enterprise applications in assembly these days? Think of it more like Maslow's Hierarchy of Needs, or in terms of the law of diminishing returns. Tools and technology cease to matter relative to other factors once they have reached a sufficient level. It is not a black and white situation.
    Even when I worked on Waterfall projects, leadership was the most significant "success" factor.
    We agree here. Project leadership is a critical success factor, regardless of the process or methodology in place.
    Agile is just explicit about this and ramps up leadership expectations ten fold.
    Why would I ramp up my expectations of my leadership by an entire order of magnitude when they aren't meeting my current expectations? Good leaders are really hard to find. It seems to me that any methodology that requires more out of leadership is doomed to fail. One of my biggest qualms with Agile methodologies as they are often defined is that they seem to push responsibility onto those who are least able to meet it, such as the customers and project leaders.
    Even in "XP Explained" (first edition) Kent Becks stresses the need for a Coach as leader, someone who has done it before, and can convey Agile values and principles to the team.
    What is "it?"
    An empowered team with the right values and principles will experiment and find good solutions to their own problems.
    What about the business's problems?
    They choose to say very little about specific technical practices on the assumption that such things have been adequately addressed elsewhere and are less important.
    "Addressed elsewhere" is different from "unimportant." All else being equal, a project that is required to use one set of tools due to external constraints will implement functionality significantly more slowly than one that has modern tools. That was the point of the questions I asked Steve. There are many different factors that affect they way a project progresses. Anecdotes where those factors are not made clear are of little practical value.
  66. Re: Again[ Go to top ]

    Paul,
    Project success has very little to do with technology and tools.


    Developing many enterprise applications in assembly these days?

    Think of it more like Maslow's Hierarchy of Needs, or in terms of the law of diminishing returns. Tools and technology cease to matter relative to other factors once they have reached a sufficient level. It is not a black and white situation.

    Even when I worked on Waterfall projects, leadership was the most significant "success" factor.


    We agree here. Project leadership is a critical success factor, regardless of the process or methodology in place.

    Agile is just explicit about this and ramps up leadership expectations ten fold.


    Why would I ramp up my expectations of my leadership by an entire order of magnitude when they aren't meeting my current expectations?

    Good leaders are really hard to find. It seems to me that any methodology that requires more out of leadership is doomed to fail. One of my biggest qualms with Agile methodologies as they are often defined is that they seem to push responsibility onto those who are least able to meet it, such as the customers and project leaders.

    Even in "XP Explained" (first edition) Kent Becks stresses the need for a Coach as leader, someone who has done it before, and can convey Agile values and principles to the team.


    What is "it?"

    An empowered team with the right values and principles will experiment and find good solutions to their own problems.


    What about the business's problems?

    They choose to say very little about specific technical practices on the assumption that such things have been adequately addressed elsewhere and are less important.


    "Addressed elsewhere" is different from "unimportant." All else being equal, a project that is required to use one set of tools due to external constraints will implement functionality significantly more slowly than one that has modern tools. That was the point of the questions I asked Steve. There are many different factors that affect they way a project progresses. Anecdotes where those factors are not made clear are of little practical value.
    Hi Erik, The problem is that you are looking at things as a science, when they are not. Anything to do with people and management is more of an art. Learning has three levels. Knowledge, understanding and skill. On a low bandwidth medium such as this we will only transfer knowledge. For understanding it takes a lot more. Hands on practical experience. Some things in life become clear by dissection, other things are only clear once you appreciate the whole. Like I said before, Agile people talk about you either getting it or not. My advice is to get on an Agile team and try it yourself. Or seek out the help of an experienced Coach. What I see in discussions such as this is that people are limited by their prior context. They want to fit the world into their existing framework of understanding. Ideas that challenge that framework are resisted until they can be reduced to something they already know. What I am saying is the limited framework of knowledge you are presenting is not the whole story. The scientific method of dissection has its boundaries. There is lots of reading you could do like the work of Edward Deming, the work of Fredrick Winslow Taylor. If you have any management experience this ideas will make some sense and you will have some understanding. Otherwise we will continue to talk past each other. Paul.
  67. Re: Again[ Go to top ]

    The problem is that you are looking at things as a science, when they are not.
    Not really. You could expect the same type of questions out of an accountant, lawyer, or pretty much any other professional.
    Anything to do with people and management is more of an art.
    I'm trying to decompose the problem so that I can understand the effects of certain techniques. Artists learn to do that, too.
    The scientific method of dissection has its boundaries.
    Yes, but we haven't even come close to them yet in this discussion.
  68. Good leaders are really hard to find. It seems to me that any methodology that requires more out of leadership is doomed to fail.
    Really? Have you looked? Here in London all you need to do is go along to the Extreme Tuesday Club and there are a bunch of Agile coaches available, waiting and willing. All with good track records. It is no different than looking for a good barrister. You go on recommendation, word of mouth and past clients. When I went to Atlanta I came across capable people/Coaches at the Atlanta Agile User Group. My view is that hands on mentoring by an experienced Coach is the only way. It is the way I learned, and it is the way that excellence is achieved in most professions. Paul.
  69. Good leaders are really hard to find. It seems to me that any methodology that requires more out of leadership is doomed to fail.


    Really? Have you looked? Here in London all you need to do is go along to the Extreme Tuesday Club and there are a bunch of Agile coaches available, waiting and willing. All with good track records.

    It is no different than looking for a good barrister. You go on recommendation, word of mouth and past clients. When I went to Atlanta I came across capable people/Coaches at the Atlanta Agile User Group.

    My view is that hands on mentoring by an experienced Coach is the only way. It is the way I learned, and it is the way that excellence is achieved in most professions.

    Paul.
    I think we're operating on different definitions of "good leadership."
  70. Good leaders are really hard to find. It seems to me that any methodology that requires more out of leadership is doomed to fail.


    Really? Have you looked? Here in London all you need to do is go along to the Extreme Tuesday Club and there are a bunch of Agile coaches available, waiting and willing. All with good track records.

    It is no different than looking for a good barrister. You go on recommendation, word of mouth and past clients. When I went to Atlanta I came across capable people/Coaches at the Atlanta Agile User Group.

    My view is that hands on mentoring by an experienced Coach is the only way. It is the way I learned, and it is the way that excellence is achieved in most professions.

    Paul.


    I think we're operating on different definitions of "good leadership."
    Agreed. In Agile projects the team is self managed and leads itself (with the help of a Coach/Scrum Master). This is very different from the way most organisations run their teams. Like I said before, differing prior context and differing values. Paul.
  71. Agreed. In Agile projects the team is self managed and leads itself (with the help of a Coach/Scrum Master).
    So you're saying leadership is important but individual leaders are unimportant? Or are you saying that the project leader should be intrinsic to the team rather than extrinsic? An intrinsic leader would be someone who is part of the core team, and is pretty much dedicated to the project. An extrinsic leader would be someone who mostly monitors the project, makes reports to management, and on an as-needed basis makes decisions, resolves conflicts, helps remove barriers, etc. Some would call this "drive by project management." In my experience a good extrinsic project manager who has official authority coupled with a good intrinsic leader who is part of the technical team works fairly well for small/medium sized projects. It's a similar concept to Brooks' surgical team, where it is important that the architect (the technical leader of the project) and the project manager be different people. Large projects need an intrinsic PM.
  72. Agreed. In Agile projects the team is self managed and leads itself (with the help of a Coach/Scrum Master).


    So you're saying leadership is important but individual leaders are unimportant?

    Or are you saying that the project leader should be intrinsic to the team rather than extrinsic?

    An intrinsic leader would be someone who is part of the core team, and is pretty much dedicated to the project.

    An extrinsic leader would be someone who mostly monitors the project, makes reports to management, and on an as-needed basis makes decisions, resolves conflicts, helps remove barriers, etc. Some would call this "drive by project management."

    In my experience a good extrinsic project manager who has official authority coupled with a good intrinsic leader who is part of the technical team works fairly well for small/medium sized projects. It's a similar concept to Brooks' surgical team, where it is important that the architect (the technical leader of the project) and the project manager be different people. Large projects need an intrinsic PM.
    There are three separate issues here. Project management, technical leadership, and Mentorship. In Scrum there are three entities, the team, external Management and the customer (product owner) . The team is responsible for managing software development (they manage themselves), the customer is responsible for managing and prioritising the backlog (unimplemented requirements) and the external Management responsible for removing blockers in the way of the team and providing oversight (similar to senior management oversight in CMM). All this stuff you can read for yourself. There are a number of good Scrum books out there. The point is that the team self manages and makes technology and development decisions for themselves. They do what ever they see fit to meet the commitments they make to the customer. Then there is technical leadership. As Steve as pointed out, Agile teams tend to be multi-skilled. The team will do everything necessary to release working code. There normally isn't a single technical lead. Common code ownership means that any pair of developers can make technical decisions at anytime. Over time you get to find out who is most knowledgeable in a given area and where to go for advice. Also over time through pair rotation, skills and knowledge spreads across the team. If the technical decision is significant, then the whole team can brake out and brainstorm options together and agree on a way forward. Then there is Mentorship and coaching. Often the team may be stuck on what to do. At times like this they look to their coach, just like a soccer team would. Also every now and then the team may need reminding of their values and their principles to ensure that the decisions they make are congruent. The coach helps here too. And at times when the team cannot decide or is ambivalent then the coach will lead. It is a different type of leadership where people are helped to solve problems themselves. Similar to how quality circles work in say Six Sigma. The whole point is that the team members are encouraged to think for themselves and be creative in solving their problems which they own as a team. The consequence is that the talents of the whole teams are fully utilised, everyone in the team is focused on a single goal, and amazing things are possible. Again as Steve as pointed out. BTW. When there are more than one Scrum team there is no Strategy or Architect group to coordinate things. Teams collaborate amongst themselves to share knowledge, practice, code etc. This is known as a Scrum-of-Scrums and works organically bottom up rather then being imposed top down. This is in keeping with the theme of empowering teams. Paul.
  73. A company is Agile if it follow principles of Agile Manifesto: customer satisfaction, changing requirements, working software etc.


    You forgot "curing cancer" ..

    Seriously, those are not "Agile principles", they are just common sense. Oops, I mean "Common Sense (tm) Manifesto principles"
    Well, the manifesto is quite utopian. It only names some guidelines for Agile methods and it's quite easy to build up a method of your own and call it Agile. And you are Agile, just as long as you do NOT: - do the waterfall - resist changes of requirements - strictly control teams outside - ignore face-to-face conversation + the rest (you know how to read, the manifesto is quite short) But for such a small set of principles, this has influenced quite remarkably on our business (software development). Sometimes you just need to spell the common sense out loud enough to make a difference.
  74. Re: Agile is about Agile Manifesto[ Go to top ]

    Companies may use Agile a marketing trick, but only companies following Agile principles truly will success. With or without individual practices such as TDD.
    +1... very nicely said. Dave Rooney Mayford Technologies
  75. Companies may use Agile a marketing trick, but only companies following Agile principles truly will success.
    You're joking, right? -- Cedric
  76. Companies may use Agile a marketing trick, but only companies following Agile principles truly will success.

    You're joking, right?

    --
    Cedric
    I'm not a deliberately funny person. Tomi
  77. i've contracted at dozens of shops over the last 10 years as a java programmer/designer. in my experience, the architect or lead dev or p.m. will say in the interview that they are an "Agile" shop. but the majority of the time, you find out as soon as you actually join the project that what they mean by "Agile" is their development process (if it can be called that) is an adhoc, free-for-all, clusterf**k. a lot of shops only pay lip service to Agile.
  78. 'agile' == 'green'[ Go to top ]

    the misuse of the term 'agile' is so rampant that the term no longer has any meaning everyone claims to be agile and nobody can agree on what it really is, especially if being agile means not doing what you want or doing what you dont want just like the misuse of the 'green' label by all the big polluting corporations every shop i've ever worked in is managed by people who are obsessed with the calendar and nothing else now they have another magic word to hide behind many of the comments in this post are thoughtful and insightful, but alas, moot
  79. in a lot of ways, this thread itself demonstrates what happens most of the time on "Agile" projects. you start off with a specific objective; in the case of this thread, the objective is to get answers to a specific question: "Agile Software Development: True Adoption or Just a Label?" it goes without saying what the point of a software development is. in both cases, you get the armchair "methodologists" who completely miss the point (again, the point in this case is to answer a very specific question). in the end, it just starts being about people "philosophizing" about being "Agile" simply because they like the sound of their own words. lip service!
  80. it goes without saying what the point of a software development is
    Unfortunately, the situation is more like the point of software development projects often goes without being said, usually because no one knows what it is.
  81. Chump nuts! You couldn't be more wrong - my chair doesn't even have arms ;)
  82. the objective is to get answers to a specific question: "Agile Software Development: True Adoption or Just a Label?"
    The answer is: It depends... If Agile requires weekly production releases, then I would say it "Agile" is just a label for the projects that I have participated in. If you relax that to "what makes sense for the business", then: If you count me as part of the technical team, then we've applied the label to waterfall projects. If you count me as part of the customer team, the we've applied the label to agile projects. These would be the same projects. Depending on how you define "agile," they could be waterfall or agile.
  83. These would be the same projects. Depending on how you define "agile," they could be waterfall or agile.
    People were doing Agile long before the word "Agile" was coined. The issue isn't how long each iteration is: 1 week, 2 weeks, 4 weeks etc. What makes a team "Agile" are their values and their principles. THIS IS THE DEFINITION (READ THE MANIFESTO)!!! If I haven't made this clear then I guess I've just been wasting my time :( Paul.
  84. These would be the same projects. Depending on how you define "agile," they could be waterfall or agile.


    People were doing Agile long before the word "Agile" was coined. The issue isn't how long each iteration is: 1 week, 2 weeks, 4 weeks etc. What makes a team "Agile" are their values and their principles. THIS IS THE DEFINITION (READ THE MANIFESTO)!!!

    If I haven't made this clear then I guess I've just been wasting my time :(


    Paul.
    In my opinion values and principles are necessary but not sufficient. You also need actions and results. I think that's what the question is all about. So if I say "We're going to have weekly builds, monthly demonstrations, and quarterly releases" and use the feedback from them to better adapt our software, then I intend to run a Agile project. However, if in practice I don't even do an integrated build until two months in and demonstrate what I intend to release at the end of the quarter, and refuse to incorporate feedback during the next cycle, then I haven't really ran an Agile project. So the question is: At what point does the label cease to apply?
  85. These would be the same projects. Depending on how you define "agile," they could be waterfall or agile.


    People were doing Agile long before the word "Agile" was coined. The issue isn't how long each iteration is: 1 week, 2 weeks, 4 weeks etc. What makes a team "Agile" are their values and their principles. THIS IS THE DEFINITION (READ THE MANIFESTO)!!!

    If I haven't made this clear then I guess I've just been wasting my time :(


    Paul.


    In my opinion values and principles are necessary but not sufficient. You also need actions and results. I think that's what the question is all about.

    So if I say "We're going to have weekly builds, monthly demonstrations, and quarterly releases" and use the feedback from them to better adapt our software, then I intend to run a Agile project. However, if in practice I don't even do an integrated build until two months in and demonstrate what I intend to release at the end of the quarter, and refuse to incorporate feedback during the next cycle, then I haven't really ran an Agile project.

    So the question is: At what point does the label cease to apply?
    The label no longer applies when you stop valuing X over Y. When X is stated in the Agile manifesto and Y is not. It really is that simple. Judgment takes skill. Skill requires understanding. Understanding takes knowledge and experience. Your coach will have all of these things, and all you need to do is take his/her lead until your gain them for yourself by example. Paul.
  86. In my opinion values and principles are necessary but not sufficient. You also need actions and results.
    So what "actions" would you prescribe? Should the "actions" for a 1 man month project be the same as for a 50 man man month project geographically spread across two continents? And if they where would they generate the same "results"? This is a nonsense statement. Everyone knows that you need to tailor your actions (process) to meet the needs of the project at hand. One size doesn't fit all. Now either you are very naive or you are being intentionally obtuse. I think I've had enough. Peace. Paul.
  87. In my opinion values and principles are necessary but not sufficient. You also need actions and results.


    So what "actions" would you prescribe? Should the "actions" for a 1 man month project be the same as for a 50 man man month project geographically spread across two continents? And if they where would they generate the same "results"? This is a nonsense statement. Everyone knows that you need to tailor your actions (process) to meet the needs of the project at hand. One size doesn't fit all. Now either you are very naive or you are being intentionally obtuse.

    I think I've had enough.

    Peace.

    Paul.
    I think I was unclear. I wasn't saying that the process or methodology has to explicitly define actions and results. I was saying that the project team has to act in ways consistent with the values and achieve results. In my experience, both professional and personal, people quite often hold values very passionately in words but quickly lose sight of them when it comes to acting or achieving results. Let's say an Agile project team has decided that at the end of every week all unit tests will pass. One week Friday rolls around and a bunch of tests aren't passing. 5:00PM hits, the tests still aren't passing, and everyone heads off to the pub and doesn't return until Monday. This is not an isolated occurrence and happens more often than not. This team says they value working software on a time-boxed schedule, but they will not act to make it work within that schedule. Do they really hold that value? Now consider the same team, only frequently they work overtime at the end of the week or over the weekend to make the tests pass (yes, I know overtime is not Agile and extended overtime is not a good idea). Sometimes it works, most of the time they back-out the failing code and associated tests from the code base and leave it until next week. They are acting to have "working software," but they are not really achieving the result, because they leave a pile of non-working software lying around at the end of each weak. Do they really value working software? For something different, consider a waterfall team. They say that they value complete and consistent requirements gathered by interviewing a myriad of stakeholders and then signed-off by key management personnel. The interviews turn out to be hard to schedule, and many never take place. Many requirements are left out because they don't fit with the others, and even those in the document are not consistent with each other. Most managers don't bother reading or signing the requirements, although every time they are asked they say "I'll get to it soon..." The project moves forward with incomplete and incoherent requirements. It may distress the team to no end that they don't have good requirements. They will lose sleep. They will scramble to fix them as design starts. But ultimately they will not hold up the schedule for them. Does the team really value complete and consistent requirements? It's easy to say you have a value. It's easy to feel that value. It's even easy to work hard to achieve that value. But when shit happens, and you are forced to make a hard choice, that's when you know if you really hold that value.


  88. I think I was unclear. I wasn't saying that the process or methodology has to explicitly define actions and results. I was saying that the project team has to act in ways consistent with the values and achieve results.

    In my experience, both professional and personal, people quite often hold values very passionately in words but quickly lose sight of them when it comes to acting or achieving results.

    Let's say an Agile project team has decided that at the end of every week all unit tests will pass. One week Friday rolls around and a bunch of tests aren't passing. 5:00PM hits, the tests still aren't passing, and everyone heads off to the pub and doesn't return until Monday. This is not an isolated occurrence and happens more often than not.

    This team says they value working software on a time-boxed schedule, but they will not act to make it work within that schedule. Do they really hold that value?

    Now consider the same team, only frequently they work overtime at the end of the week or over the weekend to make the tests pass (yes, I know overtime is not Agile and extended overtime is not a good idea). Sometimes it works, most of the time they back-out the failing code and associated tests from the code base and leave it until next week.

    They are acting to have "working software," but they are not really achieving the result, because they leave a pile of non-working software lying around at the end of each weak. Do they really value working software?

    For something different, consider a waterfall team. They say that they value complete and consistent requirements gathered by interviewing a myriad of stakeholders and then signed-off by key management personnel. The interviews turn out to be hard to schedule, and many never take place. Many requirements are left out because they don't fit with the others, and even those in the document are not consistent with each other. Most managers don't bother reading or signing the requirements, although every time they are asked they say "I'll get to it soon..." The project moves forward with incomplete and incoherent requirements.

    It may distress the team to no end that they don't have good requirements. They will lose sleep. They will scramble to fix them as design starts. But ultimately they will not hold up the schedule for them. Does the team really value complete and consistent requirements?

    It's easy to say you have a value. It's easy to feel that value. It's even easy to work hard to achieve that value. But when shit happens, and you are forced to make a hard choice, that's when you know if you really hold that value. that was put so well, it almost brought a tear to my eye.
  89. Dissapointed[ Go to top ]

    the objective is to get answers to a specific question: "Agile Software Development: True Adoption or Just a Label?"


    The answer is: It depends...

    If Agile requires weekly production releases, then I would say it "Agile" is just a label for the projects that I have participated in.

    If you relax that to "what makes sense for the business", then:

    If you count me as part of the technical team, then we've applied the label to waterfall projects.

    If you count me as part of the customer team, the we've applied the label to agile projects.

    These would be the same projects. Depending on how you define "agile," they could be waterfall or agile.
    Hi Erik, I must admit I'm disappointed. Your response here makes me question whether I should bother to contribute to such discussions like this at all. When I was on my first Agile team I was sceptical. Sceptisim is healthy IMO, it shows that you are willing to question new ideas. My coach conducted a number of "brown bag" training sessions over lunch in an attempt to convey Agile values, principles and practices to the team. The first thing he did was to place the following acronyms on the board: NIH IKIA Both of thes acronyms were written within a "no entry" sign. He said that before he continues we must all agree not to enter these two zones: NIH - Not Invented Here IKIA - I Know It Already I see discussions such as this as a great opportunity for us as a community to share knowledge. One thing I should be able to trust conversing with my peers is that they are sharing their information honestly without a commercial axe to grind. As a young developer I spent years learning new technologies on the assumption that their proponents where advocating them in good faith, only to find out years later that their sole intention was to make money. This is my reason for sharing my knowledge here. There is no other. In areas where I have no experience then I would hope that others would share their knowledge and experiences in the same vein. Instead what I tend to find is people taking pot shots at things they don't know and have no experience of. Much of what I have said here you could have read in a book for yourself. I could have easily berated your ignorance but I chose not to. I chose to assume that you were honestly seeking knowledge and truth. And I offered my experiences in good faith. Your summary here (plus other thing you've said) leads me to believe that you are more interested in sounding clever and smug and massaging your own ego. If I am wrong then I apologise, but if there is a single bit of truth in this then I hope this post gives your reason to pause and think. I'll try and keep out of these "debates" in the future. Regards, Paul.
  90. in a lot of ways, this thread itself demonstrates what happens most of the time on "Agile" projects. you start off with a specific objective; in the case of this thread, the objective is to get answers to a specific question: "Agile Software Development: True Adoption or Just a Label?"

    it goes without saying what the point of a software development is.

    in both cases, you get the armchair "methodologists" who completely miss the point (again, the point in this case is to answer a very specific question). in the end, it just starts being about people "philosophizing" about being "Agile" simply because they like the sound of their own words.

    lip service!
    The word "values" has been mentioned 48 times in this thread, and the word "principles" 27. There as also been numerous references to the Agile Manifesto which is a document that defines Agile values and principles pretty well. The answer to the question is for those who get Agile values and principles then Agile is a god send, and for those who don't it is just another label. In my experience people tend to fall into one camp or the other. Given the short attention span of most in our industry, the "label" camp who are just looking for something new to augment their resumes, tend to outstrip the "get it" camp by about 10 to 1. Paul.