tag:blogger.com,1999:blog-36930149.post6039016151249912696..comments2023-10-11T02:59:45.752-07:00Comments on mosgot's World of Software Project Management: Waterfall or Agile? Neithermosgothttp://www.blogger.com/profile/01197862673904109978noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-36930149.post-38564884010004593692007-02-03T22:57:00.000-08:002007-02-03T22:57:00.000-08:00Hi there. Software development over documentation ...Hi there. Software development over documentation development any day!<br /><br /><a href='http://thebusinessanalyst.blogspot.com/2007/01/what-vs-how.html'>What vs How</a><br /><br />http://thebusinessanalyst.blogspot.comN from snjtechconsulting.com.auhttps://www.blogger.com/profile/13514697281305618703noreply@blogger.comtag:blogger.com,1999:blog-36930149.post-20898212285396834772007-01-23T23:20:00.000-08:002007-01-23T23:20:00.000-08:00Dave, thank you for the excellent and thoughtful c...Dave, thank you for the excellent and thoughtful comment. I dare say the comment is better than my own post :).<br /><br />I think the various items you point out are all very good. It will not provide any value-add if I respond to all of them. I will just make some general comments.<br /><br />Yes, there is some ambivalence in what I said. That is because there are indeed things that I like in agile techniques. My concerns always were with how people "in the field" interpreted them.<br /><br />For example, the documentation issue. I agree that we need to generate only valuable documents. But all too often I find Agilists (or, maybe agile wannabes) That interpret it as: "cool, finally we don't need to write those !@!? docs". I really experienced that... Too often do I meet engineers who think: agile = easy life. For many, waterfall means rigid, hard, regimented, whereas agile is complete freedom. don't need to do anything except write code. I was trying to move the pendulum a bit back. Agile is (and should be) as demanding and rigorous as waterfall.<br /><br />Regarding "welcome". The way you describe it - I have no problem. To me, it's the connotation. Welcome sounds positive, inviting. I don't feel that way about scope creep. Scope creep is not desirable, hence not welcome. My approach is that I prefer (if possible, of course) to lock the scope down and not change. If, instead of using the word "welcome", agile said something like "change should be expected and handled gracefully", I would feel much better. As I noted, I know that change is hard to avoid in a SW project and therefore it will be foolish to try to rigidly prevent it. This is one of the problems with waterfall - change is not tolarated. Team members (PMs) try to prevent it as hard as they can and fail. In summary, don't encourage change but be prepared to manage it wisely. To me this is a difference in mindset but maybe when it come down to the action in the field, there isn't much difference between the agile perspective and mine.<br /><br />Finally, regarding your last comment, you are very right. I did not mean too imply there's anything wrong if agile uses well-known things. Just pointed that out for all the enthusiasts who think everything in agile is a conceptual breakthrough. But you are right. Nothing wrong with adopting things that work well. Very smart actually.<br /><br />Thanks again for the very good comments.mosgothttps://www.blogger.com/profile/01197862673904109978noreply@blogger.comtag:blogger.com,1999:blog-36930149.post-10795849704824440852007-01-22T13:03:00.000-08:002007-01-22T13:03:00.000-08:00I came across a link to your blog on Glen Alleman'...I came across a link to your blog on Glen Alleman's site, of which I'm a regular reader. IMO you make some good comments.<br /><br />Is it the debate of the century? Maybe just the debate of the moment. At least, now that you have an opinion, you're respectable. Some of us are so full of opinions we're too respectable for our own good! ;-)<br /><br />I agree classical waterfall is not much of an issue anymore except maybe in the largest and stodgiest of companies. Their stodginess makes them infertile ground for positive change anyway, so in a sense they're not players. <br /><br />You say agile has some things you don't like, but based on your explanations it seems as if you actually agree with the principles. I say this because your follow-up arguments "against" actually amount to summaries of the true meaning of the agile principles in question. <br /><br />It's quite true that to be successful with agile methods the customer's direct and knowledgeable involvement is critical. When that happens, the results can be extremely good. When it doesn't happen, IMO it's smarter to fall back to some other methodology rather than to try to do agile without the customer's involvement. There are many variations of the iterative waterfall (something along the lines of RUP, for instance) that may yield acceptable results when the customer can't or won't participate directly. The results may not be as good as could have been achieved with properly-implemented agile methods, but in that case we have to settle for results that are as good as prevailing circumstances permit. "Make-believe agile" won't get us to a second-best outcome, but "real RUP" just might, and that's still much better than the traditional alternative.<br /><br />You say you have a problem with the idea of welcoming changes in requirements, including late in development. However, your follow-up explanation reads very much like the agilist's approach to managing scope creep. Maybe you don't disagree after all. Agile methods provide a rational and practical way to deal with scope creep and changing requirements, and it's entirely based on customer-defined value. Many other methods simply try to lock down documented requirements far in advance of the time when it's even possible to know the requirements in detail, or to discourage change by imposing draconian procedures for change control. For the types of projects to which agile methods apply, this is simply unrealistic. By the nature of those projects, the requirements are definitely going to change. Might as well adopt a methodology that handles change gracefully, then.<br /><br />Your criticism of the preference for face-to-face communication may be more a matter of misunderstanding than real disagreement, as well. In most conventional methodologies, a written statement of requirements is all the developers have to go on when building the software. All too often, the documented requirements are incorrect, incomplete, contradictory, out of date, or subject to misinterpretation. Face-to-face communication avoids all those problems. <br /><br />Agilists do not abhor documentation just because it's documentation. They insist that everything the project team creates must contribute to customer-defined value. Documentation that is desired by the customer meets that definition. Also, informal interim documentation that aids in design and development contributes to the project's goals, even if that documentation will never become a bona fide project deliverable. <br /><br />You agree that working software is the measure of success, provided the software does what the customer wants. Given a proper understanding of the agile mindset, this is not even a question. The very definition of "working" is that the customer sees and uses the software and declares it does what they want it to do. We do not consider a piece of work "done" unless and until the customer approves it. <br /><br />Regarding the statement, "The best architectures, requirements, and designs emerge from self-organizing teams," I might point out that this is not one of the four basic principles enumerated in the Agile Manifesto, although it is a statement commonly associated with agile thinking. Like you, I'm unconvinced that a direct cause-and-effect relationship has been established between self-organizing teams and good design. On a more general level, self-organizing teams tend to do better work than teams that are subject to a command-and-control management style. (See, for example, the book Peopleware by Lister and DeMarco, or any of the relevant material published by proponents of "lean" development). That is not a statement about design quality specifically, though.<br /><br />If anything, anecdotal evidence suggests teams (whether self-organizing or not) don't create the "best" designs. Consider two of the most popular open source projects - Linux and Ruby on Rails. While both projects now have many contributors, and while the open source mode of work surely exemplifies the concept of the self-organizing team in action, both products were originally designed by single individuals. The coherence and consistency of their design philosophies and implementations derive from the fact they were conceived by individuals, not by committees, teams, or published reference architectures. It may be that to achieve the best possible design, we need to ask a single individual to do it. Once he/she has laid the groundwork, a self-organizing team (such as an open source project or an agile project team) may well be the most effective way to drive the product forward, but there's no proof that such a team could have arrived at an equally consistent and coherent design. Seems to me there's a fair chance we'd end up with a product reeking of design-by-committee.<br /><br />While I think your disagreements with agile principles boil down to misunderstandings (based on the fact your explanations actually state the agile case rather than an argument against it), I do disagree with one aspect of your criticism on principle. At several points you mention that this or that is not "unique" to agile. I would go farther and say absolutely none of the ideas embodied in agile thinking is completely original or unique. The question is, "So what?" The reason agile methods work so well is that they comprise practices that many people have found useful over many projects. They are a compilation and synthesis of field-proven ideas and techniques, and not an attempt to create something totally new out of whole cloth. It is therefore not a valid criticism to say that any given idea is not "unique" to agile. I might ask, to which methodology are any of these ideas unique?Anonymousnoreply@blogger.com