Is Agile just a justification for bad business practices?
-
Yes! Yes! YES! Agile is also a way bad engineers can hide. I personally don't know a single successful project that used Agile development. Not one. Yet, I know many that have failed. In one, the astonishing thing is that the manager, engineer and designer responsible for the fiasco were rewarded while everyone else either quit or was fired (for questioning the Gods.) I figure that in their twisted little brains the triad convinced the management fools that had everyone else didn't really do the Agile method properly; that's why it failed (not because they sucked at management, engineering and design and were just making crap up as they went along.)
Joe Woodbury wrote:
I personally don't know a single successful project that used Agile development.
Some of the core concepts of agile (e.g. iterative development with staged releases) are an evolution of traditional methods, so it's no surprise they work. Others (such as a solid suite of automated tests behind the code and continuous integration) just make sense. Pairing isn't for everyone, but it's not a core concept of agile - only of one particular form of it (XP). That said, the XP concept of velocity measurement and adjustment of iteration scope is excellent. FWIW we switched our projects from a traditional process to an agile derived one (customised slightly for our small team size) nearly 3 years ago and since then we have had far fewer issues in our development than previously. Each iteration is about 2 weeks effort and capped in scope, and our tests and CI build warn us if anything goes wrong long before the code goes anywhere near a customer. Does that make them successful projects? I've no idea, but it certainly seems to work for us. Talking to some of the ACCU guys who specialise in rescuing failing projects (e.g. Kevlin Henney and Pete Goodliffe) they're pretty convinced of its efficacy too. It's all about how you go about it, and how willing the team and organisation are to adapt to change. If the organisation or the team are too wedded to their old waterfall-esque ways (or indeed are engaged in "playing" at agile, as the team you describe seem to have being), any new process is likely to be doomed. Training, skills and leadership are as important with agile processes as any other, of course.
Anna :rose: Having a bad bug day? Tech Blog | Anna's Place | Tears and Laughter "If mushy peas are the food of the devil, the stotty cake is the frisbee of God"
-
SSDD Blueprints! Blueprints! We don't need no stinkin blueprints! Start building all three stories. Now. We can dig the foundation later. I'll be back tomorrow to see how it's coming along... Flash forward 3 weeks: Ok. We want to make the 2nd bedroom on the third floor bigger by 25 sq ft without altering the size of the ground floor. And can you change that roof. Client doesn't like gray shingles. Forward 3 more weeks: We don't want a second floor any more. Take it out. ...what? I don't care that it's got plumbing and wiring going to the third floor. Make it happen! Forward 6 months after 1000 more "adjustments": Looks great from the outside, but I gotta tell ya, the inside REALLY sucks... There are rooms with no door, stairs that lead nowhere, and what's with that bay window in the shower? Why is this taking so long? Forward 3 months: Client pulled the plug. They bought someone else's house. Way to go. You're an idiot. --------------------------------- Good. Quick. Cheap. Pick any two!
Cheers, Mike Fidler
In software terms, the only document detailed enough to act as a blueprint is the source code. Any other form of documentation (e.g. design docs) can only express a broad intention - the more detailed they are, the less likely they are to be accurate. A true implementation of an agile process doesn't shun traditional documentation, but doesn't elevate it beyond its station (as Waterfall and other forms of BUFD do) either.
Anna :rose: Having a bad bug day? Tech Blog | Anna's Place | Tears and Laughter "If mushy peas are the food of the devil, the stotty cake is the frisbee of God"
-
Joe Woodbury wrote:
I personally don't know a single successful project that used Agile development.
Some of the core concepts of agile (e.g. iterative development with staged releases) are an evolution of traditional methods, so it's no surprise they work. Others (such as a solid suite of automated tests behind the code and continuous integration) just make sense. Pairing isn't for everyone, but it's not a core concept of agile - only of one particular form of it (XP). That said, the XP concept of velocity measurement and adjustment of iteration scope is excellent. FWIW we switched our projects from a traditional process to an agile derived one (customised slightly for our small team size) nearly 3 years ago and since then we have had far fewer issues in our development than previously. Each iteration is about 2 weeks effort and capped in scope, and our tests and CI build warn us if anything goes wrong long before the code goes anywhere near a customer. Does that make them successful projects? I've no idea, but it certainly seems to work for us. Talking to some of the ACCU guys who specialise in rescuing failing projects (e.g. Kevlin Henney and Pete Goodliffe) they're pretty convinced of its efficacy too. It's all about how you go about it, and how willing the team and organisation are to adapt to change. If the organisation or the team are too wedded to their old waterfall-esque ways (or indeed are engaged in "playing" at agile, as the team you describe seem to have being), any new process is likely to be doomed. Training, skills and leadership are as important with agile processes as any other, of course.
Anna :rose: Having a bad bug day? Tech Blog | Anna's Place | Tears and Laughter "If mushy peas are the food of the devil, the stotty cake is the frisbee of God"
I've made it fairly clear that Agile development borrowed existing concepts and called them their own. (For example, Agile did not invent iterative development and staged releases whatsoever.) My broader point I've been making is that simply using parts of Agile methodologies is NOT doing Agile development. By this definition, I've been doing Agile development for all 39 years I've been programming. If you aren't using the Agile process in its entirety, then you aren't doing Agile development. (Likewise, if you claim to do to XP programming "except the pair stuff" then you simply aren't doing XP programming and to claim so is being extremely disingenuous.) A big problem with arguing this is that the vast, vast majority of engineers who talk about Agile development, don't actually know what it actually insists on. They've long picked and chosen those portions which work for them and then make their claims.
Anna-Jayne Metcalfe wrote:
or indeed are engaged in "playing" at agile, as the team you describe seem to have being
This is the standard line proponents of every hair brained scheme claim. Ironically, you openly admitted that you don't use all of Agile development, so why claim those that have are the ones "playing" and thus their negative results are invalid?
-
I was reading Simon's post[^] about how his boss told him to "release early and often" but wanted a bottom line number on when the project would be done, and it got me thinking. Every so often there's a new darling design methodology of the day, which becomes the gospel for the religious for however many years it takes for some ivory tower sort to come up with the next one. I've been through many in my career, from waterfall to structured A/D to the fragmented camps of OOA/D, ad nauseum. Of course, no shop I've ever seen does the analysis & design 100% by the book, performing every recommended step in the process, because management never wants to allocate time to analysis & design. The typical business mentality is that if you're not coding, you're not making progress, and so any attempt to take the amount of time that's really necessary to figure out the what and the how is squelched by the pressure of arbitrary deadlines. "How long will this take?" is usually asked after "This is when we're planning on releasing the product." In other words, the loudest voice against doing a thorough analysis and design up front is not the developer who thinks it's a bad idea, but the businessman who simply doesn't want to take the time. That's the way it's always been, at least in my 20 years in the industry. From waterfall to OOA/D, the problem was never that they were bad methodologies, but simply that they took more time to perform than the businesspeople wanted to allow. ("How long will it take to build this log cabin?" "Well, first we have to cut down the trees..." "We don't have time to cut down the trees. Just build the darned thing!"). Fortunately, Agile comes to the rescue by telling businesspeople exactly what they want to hear. You don't have to do all that pesky thinking up front. Just come up with a half baked idea, slap it together and you'll have a release. Crappy quality or not what you wanted? No problem. Agile anticipates this, allowing you to repeat this cycle as often as you like and feel good about the fact that you're using an Official Design Methodology. It seems to me that before you can build something, you have to know what it is and how you're going to go about building it. However, nobody wants to hear that, so we've come up with a design methodology based not on the sensible solution of thinking b
I've been writing code without specs for 10 years. My user's never ask me how long it will take because it never takes longer they think it should. The only problem i run into is that the folks that beleive in a more rigid process around app dev want to kill me. The bottom line is that coding isn't hard relative to the businesss problems the code solves. This our failure as a group. We think every project is about IT when it never is about IT. It's about the business. How can you ask them what they want? Most times they don't know specifically. Give them a rough app in two or three days, see what they think and go from there for a few months until it stabalizes then lock it down and document it. Like I said it's been working for me for almost ten years and the y only complaining I hear is from peers.
-
Agile like so many other things is simply a method to commoditize development and turn us developers into cogs in a machine which are easily replaceable or outsourced. Why developers continue to embrace this stuff that is a) stupid and b) directly antithetical to having a stable and well paying career as a software developer will remain one of the great mysteries of the universe. The dirty secret I believe is that it doesn't matter which methodology you follow as long as you have one be it "official" or whatever you know works for you.
"Creating your own blog is about as easy as creating your own urine, and you're about as likely to find someone else interested in it." -- Lore Sjöberg
I am suprised to hear you say that. Maybe you're in an environmemt where agile is be applied differntly than the way I use it. Where I work Agile means work closely with business to develop soultions through iteration. This allows me to serve in many roles. I do my own BA and Architect work as well as writing the code and devoping the data model.
-
I was reading Simon's post[^] about how his boss told him to "release early and often" but wanted a bottom line number on when the project would be done, and it got me thinking. Every so often there's a new darling design methodology of the day, which becomes the gospel for the religious for however many years it takes for some ivory tower sort to come up with the next one. I've been through many in my career, from waterfall to structured A/D to the fragmented camps of OOA/D, ad nauseum. Of course, no shop I've ever seen does the analysis & design 100% by the book, performing every recommended step in the process, because management never wants to allocate time to analysis & design. The typical business mentality is that if you're not coding, you're not making progress, and so any attempt to take the amount of time that's really necessary to figure out the what and the how is squelched by the pressure of arbitrary deadlines. "How long will this take?" is usually asked after "This is when we're planning on releasing the product." In other words, the loudest voice against doing a thorough analysis and design up front is not the developer who thinks it's a bad idea, but the businessman who simply doesn't want to take the time. That's the way it's always been, at least in my 20 years in the industry. From waterfall to OOA/D, the problem was never that they were bad methodologies, but simply that they took more time to perform than the businesspeople wanted to allow. ("How long will it take to build this log cabin?" "Well, first we have to cut down the trees..." "We don't have time to cut down the trees. Just build the darned thing!"). Fortunately, Agile comes to the rescue by telling businesspeople exactly what they want to hear. You don't have to do all that pesky thinking up front. Just come up with a half baked idea, slap it together and you'll have a release. Crappy quality or not what you wanted? No problem. Agile anticipates this, allowing you to repeat this cycle as often as you like and feel good about the fact that you're using an Official Design Methodology. It seems to me that before you can build something, you have to know what it is and how you're going to go about building it. However, nobody wants to hear that, so we've come up with a design methodology based not on the sensible solution of thinking b
I'm puzzled by this whole discussion. In my experience, agile programming causes: - communication daily, to ensure there's no surprises or silly delays - developers and management communicate - management to prioritize. They can't have everything in a month. - developers to provide reasonable rough estimates for features. After a few months where you actually work on what you say you're going to work on instead of lots of interrupts, you learn how long things really take - developers have control: we don't deliver X because that's not on this sprint backlog. We don't deliver Y and Z this sprint because the estimate says 50 man weeks and we only have 20 man weeks this sprint. Agile programming keeps management from saying a product is ready when its not, keeps management from asking for unreasonable deadlines, and enables developers to clearly communicate what needs to be done. In short, it allows for developing a product in stages and maintaining a product. If your experience equates "agile" with "rush the design" then I question whether the R&D team was properly playing its role in the process. The R&D team should say, No you can't have this feature this sprint because it depends on this exploratory work. But that feature can go in next sprint if you put the exploratory work as a goal this sprint. If you don't want the exploratory work this sprint, you can't have the feature next sprint either. It's up to management to decide what goals it wants, but Agile empowers the developers to insist on realistic timeframes. In my limited experience. Obviously your mileage differs. Stuart
-
Agile like so many other things is simply a method to commoditize development and turn us developers into cogs in a machine which are easily replaceable or outsourced. Why developers continue to embrace this stuff that is a) stupid and b) directly antithetical to having a stable and well paying career as a software developer will remain one of the great mysteries of the universe. The dirty secret I believe is that it doesn't matter which methodology you follow as long as you have one be it "official" or whatever you know works for you.
"Creating your own blog is about as easy as creating your own urine, and you're about as likely to find someone else interested in it." -- Lore Sjöberg
Actually having one architect (or a group) act like god, design everything up front and hand it off to mindless programmers sounds like turning developers into cogs. Actually it sounds kind of like CMMI 5 and waterfall. My experience is that many of the agile principles are useful, not because they are called agile, but because when we practiced them 20 years ago they worked well. Our highest priority is to satisfy the customer. Deliver working software frequently. Build projects around motivated individuals. Face-to-face communication is best. Working software is the primary measure of progress. Continuous attention to technical excellence and good design. Simplicity (maximizing the amount of work not done) is essential. I don't care whether you call those principles agile or poop, they work when I use them.
SS => Qualified in Submarines "We sleep soundly in our beds because rough men stand ready in the night to visit violence on those who would do us harm". Winston Churchill "Real programmers can write FORTRAN in any language". Unknown
-
I've made it fairly clear that Agile development borrowed existing concepts and called them their own. (For example, Agile did not invent iterative development and staged releases whatsoever.) My broader point I've been making is that simply using parts of Agile methodologies is NOT doing Agile development. By this definition, I've been doing Agile development for all 39 years I've been programming. If you aren't using the Agile process in its entirety, then you aren't doing Agile development. (Likewise, if you claim to do to XP programming "except the pair stuff" then you simply aren't doing XP programming and to claim so is being extremely disingenuous.) A big problem with arguing this is that the vast, vast majority of engineers who talk about Agile development, don't actually know what it actually insists on. They've long picked and chosen those portions which work for them and then make their claims.
Anna-Jayne Metcalfe wrote:
or indeed are engaged in "playing" at agile, as the team you describe seem to have being
This is the standard line proponents of every hair brained scheme claim. Ironically, you openly admitted that you don't use all of Agile development, so why claim those that have are the ones "playing" and thus their negative results are invalid?
Joe Woodbury wrote:
I've made it fairly clear that Agile development borrowed existing concepts and called them their own. (For example, Agile did not invent iterative development and staged releases whatsoever.) My broader point I've been making is that simply using parts of Agile methodologies is NOT doing Agile development. By this definition, I've been doing Agile development for all 39 years I've been programming. If you aren't using the Agile process in its entirety, then you aren't doing Agile development. (Likewise, if you claim to do to XP programming "except the pair stuff" then you simply aren't doing XP programming and to claim so is being extremely disingenuous.) A big problem with arguing this is that the vast, vast majority of engineers who talk about Agile development, don't actually know what it actually insists on. They've long picked and chosen those portions which work for them and then make their claims.
First of all Agile itself isn't really a process - it is a set of principles. Scrum, XP, Lean etc. are all agile processes simply because they adopt those principles, but each implement them in a different way (XP has pairing, Scrum has stand up meetings etc.). Each stands on its own merits and has its own strengths and weaknesses (as does the process we use, of course). None are definitive (e.g. Scrum has recently been criticised because it doesn't focus sufficiently on technical quality, something which XP does rather well), but all are evolving over time. If you ever meet any of big names in quality and process (e.g. Tom Gilb, Niels Malotaux, Tom and Mary Poppendieck etc.), you will find that virtually all of them are singing from the same hymnsheet (it's all agile principles and PDCA - Plan-Do-Check-Act). That in itself is remarkable enough, given the history our industry has of failed software projects. Arguably, learning enough to evolve your own process from core principles is healthier than following a fixed process blindly without understanding it. Hence I'd contend that it doesn't really matter which bits of which processes you pick, so long as you do so in an informed fashion, and are prepared to change how you do things as you gain experience. The fact that the principles we follow are agile is because we've learnt they work. If BUFD had worked out, no doubt we'd be doing a customised version of that instead (but it didn't, did it...?). If you're not convinced, come along to the
-
Christopher Duncan wrote:
Fortunately, Agile comes to the rescue by telling businesspeople exactly what they want to hear. You don't have to do all that pesky thinking up front.
I think the root of the problem is not a development process (agile or not) but the fact that in many organizations people with no background in software development somehow think they can manage software projects. I am not sure what is it about software development that make everybody think it is easy to manage. I know I would not dare to manage a hospital, for instance, or a bank.
Nemanja Trifunovic wrote:
I think the root of the problem is not a development process (agile or not) but the fact that in many organizations people with no background in software development somehow think they can manage software projects. I am not sure what is it about software development that make everybody think it is easy to manage. I know I would not dare to manage a hospital, for instance, or a bank.
I wouldn't expect a nurse to manage a hospital nor a teller to manage a bank. I would expect someone with experience managing people and projects (both) could very well do better than someone with no experience at either even if that latter person works in the industry. But far as I can recall I have never seen anyone managing a software project at the detail level that didn't have experience in the industry. At some level going up there is eventually going to be someone asking when it is going to be done who doesn't code. I say that because with very, very few exceptions I wouldn't want any software developers that I have worked with to be responsible for insuring that sales happen. And at the end of the day I would rather get paid then deliver the latest project on time.
-
There is nothing wrong with Agile. Most people don't implement Agile, they (and we do this where I work) use their own *cough* process (code and fix) based on all the wrong things and claim to be following Agile. The fault is with the people (like always), not Agile.
led mike wrote:
There is nothing wrong with Agile. Most people don't implement Agile, they (and we do this where I work) use their own *cough* process (code and fix) based on all the wrong things and claim to be following Agile. The fault is with the people (like always), not Agile.
That however can be said about many of the methodologies.
-
Yes! Yes! YES! Agile is also a way bad engineers can hide. I personally don't know a single successful project that used Agile development. Not one. Yet, I know many that have failed. In one, the astonishing thing is that the manager, engineer and designer responsible for the fiasco were rewarded while everyone else either quit or was fired (for questioning the Gods.) I figure that in their twisted little brains the triad convinced the management fools that had everyone else didn't really do the Agile method properly; that's why it failed (not because they sucked at management, engineering and design and were just making crap up as they went along.)
Joe Woodbury wrote:
Agile is also a way bad engineers can hide. I personally don't know a single successful project that used Agile development. Not one. Yet, I know many that have failed. In one, the astonishing thing is that the manager, engineer and designer responsible for the fiasco were rewarded while everyone else either quit or was fired (for questioning the Gods.) I figure that in their twisted little brains the triad convinced the management fools that had everyone else didn't really do the Agile method properly; that's why it failed (not because they sucked at management, engineering and design and were just making crap up as they went along.)
I know of projects that failed due to many reasons using various methodologies. And there are many reasons for rationalizing failure. And little evidence that success of a project depends on methodologies unless it is followed rigorously There is also evidence that projects, of all sorts, have a better chance at succeeding when the programmers are better. I seriously doubt that particular result doesn't apply to most human endevours.
-
Jim (SS) wrote:
Designing the whole product completely often results in lots of redesign or unused design, once you realize what the customer really wants after a few iterations of showing the product.
I disagree. There is a huge penalty in wasted man hours when a project is *not* designed as much as possible completely in advance. We are a very small shop and we get big things done because we can't afford to fart around with each crappy new ideology that comes down the pipe. I think your perception is muddied by the amount of resources that can be thrown at it. What you are describing is actually committing code based on early customer feedback, that is completely unnecessary in this day and age, an entire app can be mocked up with all the important bits and in fact there are far too many lazy development teams that don't take the vital step of transforming what the customer wants into what the customer actually *needs*. A good architect can take the customers wants and turn out and app that is half or less the size of what a lazy shop can turn out. In turn that smaller app is more intuitive to the end user, accomplishes more with less effort and saves them big $$$. The rush to market and risk averse attitude that is prevalent today is what is resulting in so much crappy software despite every over thought design methodology in the world now at our fingertips.
"Creating your own blog is about as easy as creating your own urine, and you're about as likely to find someone else interested in it." -- Lore Sjöberg
John C wrote:
I disagree. There is a huge penalty in wasted man hours when a project is *not* designed as much as possible completely in advance. We are a very small shop and we get big things done because we can't afford to fart around with each crappy new ideology that comes down the pipe. I think your perception is muddied by the amount of resources that can be thrown at it. ... A good architect can take the customers wants and turn out and app that is half or less the size of what a lazy shop can turn out. In turn that smaller app is more intuitive to the end user, accomplishes more with less effort and saves them big $$$.
If I need brain surgery I believe that I would prefer the good brain doctor versus the one that is so-so. Doesn't matter what technique each doctor uses. The same applies to what you said. If you have a small group of good practitioners the fact that you are successful is much more likely based on the fact that you are good rather than due to the particular processes that you use.
-
I'm puzzled by this whole discussion. In my experience, agile programming causes: - communication daily, to ensure there's no surprises or silly delays - developers and management communicate - management to prioritize. They can't have everything in a month. - developers to provide reasonable rough estimates for features. After a few months where you actually work on what you say you're going to work on instead of lots of interrupts, you learn how long things really take - developers have control: we don't deliver X because that's not on this sprint backlog. We don't deliver Y and Z this sprint because the estimate says 50 man weeks and we only have 20 man weeks this sprint. Agile programming keeps management from saying a product is ready when its not, keeps management from asking for unreasonable deadlines, and enables developers to clearly communicate what needs to be done. In short, it allows for developing a product in stages and maintaining a product. If your experience equates "agile" with "rush the design" then I question whether the R&D team was properly playing its role in the process. The R&D team should say, No you can't have this feature this sprint because it depends on this exploratory work. But that feature can go in next sprint if you put the exploratory work as a goal this sprint. If you don't want the exploratory work this sprint, you can't have the feature next sprint either. It's up to management to decide what goals it wants, but Agile empowers the developers to insist on realistic timeframes. In my limited experience. Obviously your mileage differs. Stuart
smacmartin wrote:
I'm puzzled by this whole discussion. In my experience, agile programming causes: - communication daily, to ensure there's no surprises or silly delays - developers and management communicate - management to prioritize. They can't have everything in a month. - developers to provide reasonable rough estimates for features. After a few months where you actually work on what you say you're going to work on instead of lots of interrupts, you learn how long things really take - developers have control: we don't deliver X because that's not on this sprint backlog. We don't deliver Y and Z this sprint because the estimate says 50 man weeks and we only have 20 man weeks this sprint. Agile programming keeps management from saying a product is ready when its not, keeps management from asking for unreasonable deadlines, and enables developers to clearly communicate what needs to be done. In short, it allows for developing a product in stages and maintaining a product. If your experience equates "agile" with "rush the design" then I question whether the R&D team was properly playing its role in the process. The R&D team should say, No you can't have this feature this sprint because it depends on this exploratory work. But that feature can go in next sprint if you put the exploratory work as a goal this sprint. If you don't want the exploratory work this sprint, you can't have the feature next sprint either. It's up to management to decide what goals it wants, but Agile empowers the developers to insist on realistic timeframes.
I don't see anything in that that doesn't apply to any correctly implemented methodology.
-
Actually having one architect (or a group) act like god, design everything up front and hand it off to mindless programmers sounds like turning developers into cogs. Actually it sounds kind of like CMMI 5 and waterfall. My experience is that many of the agile principles are useful, not because they are called agile, but because when we practiced them 20 years ago they worked well. Our highest priority is to satisfy the customer. Deliver working software frequently. Build projects around motivated individuals. Face-to-face communication is best. Working software is the primary measure of progress. Continuous attention to technical excellence and good design. Simplicity (maximizing the amount of work not done) is essential. I don't care whether you call those principles agile or poop, they work when I use them.
SS => Qualified in Submarines "We sleep soundly in our beds because rough men stand ready in the night to visit violence on those who would do us harm". Winston Churchill "Real programmers can write FORTRAN in any language". Unknown
All of your points with the exception of "deliver working software frequently" and "build projects around motivated individuals" (which is just wishy washy "newspeak" because surely no organization is going to be stupid enough to carry unmotivated individuals are they?) fall firmly into the GOES WITHOUT SAYING category, at least in this shop. I firmly disagree with building any application of any consequence or import piecemeal. All that accomplishes is crappily designed software that makes the gray men in suits happy because it fits the costs into nice quarterly budgets. It's clearly going to be far more expensive to produce and it encourages lazy design. Obviously no big application is ever done so there is always a need to roll out changes but in my world you better have every last bit nailed down on new projects before a line of code is ever written. Then again in my current world we can't pass on the costs to the unsuspecting customer since we sell our software commercially and don't do any contract programming for single customers.
"Creating your own blog is about as easy as creating your own urine, and you're about as likely to find someone else interested in it." -- Lore Sjöberg
-
All of your points with the exception of "deliver working software frequently" and "build projects around motivated individuals" (which is just wishy washy "newspeak" because surely no organization is going to be stupid enough to carry unmotivated individuals are they?) fall firmly into the GOES WITHOUT SAYING category, at least in this shop. I firmly disagree with building any application of any consequence or import piecemeal. All that accomplishes is crappily designed software that makes the gray men in suits happy because it fits the costs into nice quarterly budgets. It's clearly going to be far more expensive to produce and it encourages lazy design. Obviously no big application is ever done so there is always a need to roll out changes but in my world you better have every last bit nailed down on new projects before a line of code is ever written. Then again in my current world we can't pass on the costs to the unsuspecting customer since we sell our software commercially and don't do any contract programming for single customers.
"Creating your own blog is about as easy as creating your own urine, and you're about as likely to find someone else interested in it." -- Lore Sjöberg
So by your own admission, most of the agile principles are valid. The reality is that there are considerable numbers of "programmers" that are only doing it for the money, and don't care about customers interests/needs the way you do. The "deliver working software frequently" may be just another way of saying "nightly builds", or getting software to testers early so they are not getting dumped on with the whole package two weeks before it is due. In my industries the customers minds change so often that if you built to the original requirements they would never accept it. If I can nail them down to accepting one piece at a time, I get a lot less surprises and a much happier customer.
SS => Qualified in Submarines "We sleep soundly in our beds because rough men stand ready in the night to visit violence on those who would do us harm". Winston Churchill "Real programmers can write FORTRAN in any language". Unknown
-
I was reading Simon's post[^] about how his boss told him to "release early and often" but wanted a bottom line number on when the project would be done, and it got me thinking. Every so often there's a new darling design methodology of the day, which becomes the gospel for the religious for however many years it takes for some ivory tower sort to come up with the next one. I've been through many in my career, from waterfall to structured A/D to the fragmented camps of OOA/D, ad nauseum. Of course, no shop I've ever seen does the analysis & design 100% by the book, performing every recommended step in the process, because management never wants to allocate time to analysis & design. The typical business mentality is that if you're not coding, you're not making progress, and so any attempt to take the amount of time that's really necessary to figure out the what and the how is squelched by the pressure of arbitrary deadlines. "How long will this take?" is usually asked after "This is when we're planning on releasing the product." In other words, the loudest voice against doing a thorough analysis and design up front is not the developer who thinks it's a bad idea, but the businessman who simply doesn't want to take the time. That's the way it's always been, at least in my 20 years in the industry. From waterfall to OOA/D, the problem was never that they were bad methodologies, but simply that they took more time to perform than the businesspeople wanted to allow. ("How long will it take to build this log cabin?" "Well, first we have to cut down the trees..." "We don't have time to cut down the trees. Just build the darned thing!"). Fortunately, Agile comes to the rescue by telling businesspeople exactly what they want to hear. You don't have to do all that pesky thinking up front. Just come up with a half baked idea, slap it together and you'll have a release. Crappy quality or not what you wanted? No problem. Agile anticipates this, allowing you to repeat this cycle as often as you like and feel good about the fact that you're using an Official Design Methodology. It seems to me that before you can build something, you have to know what it is and how you're going to go about building it. However, nobody wants to hear that, so we've come up with a design methodology based not on the sensible solution of thinking b
This "we don't need no education" manifesto was born by dot-com boom, when fresh graduates flooded start-ups, with the only "business plan" just to do something, which could be sold later. Later it clicked with management for all the wrong reasons, which you well described in your rhetoric question. ;P
-
This "we don't need no education" manifesto was born by dot-com boom, when fresh graduates flooded start-ups, with the only "business plan" just to do something, which could be sold later. Later it clicked with management for all the wrong reasons, which you well described in your rhetoric question. ;P
dmitri_sps wrote:
This "we don't need no education" manifesto was born by dot-com boom, when fresh graduates flooded start-ups, with the only "business plan" just to do something, which could be sold later. Later it clicked with management for all the wrong reasons, which you well described in your rhetoric question
Although that might be true, I can only note that the other formal methodologies are almost universally not followed as well. Most companies either do nothing or do so little that no one realistically suggests that they are following any methodology. Other companies claim adherence and yet examination shows that they are in fact not following the methodogies - they implement some of the easiest practices in a ship-shod fashion and completely ignore the harder ones (which actually produce the most bang for the buck.) There are of course some companies that do implement some formal methodology correctly. But the number is so low compared to total developement numbers that it is effectively zero.
-
Yes. There's the short answer. :)
Christopher Duncan wrote:
It seems to me that before you can build something, you have to know what it is and how you're going to go about building it.
I've never worked with any client that new exactly what they wanted. Partly because they're also re-inventing their work processes at the same time. Sort of like mixing gasoline and fire, but that's the nature of the beast. I've essentially been practicing Agile for 20 years, before it was called Agile. The pieces that work for me are: 1. communication between team members in daily stand-up meetings / phone calls 2. putting the app frequently in front of the client so they can alter the course 3. unit testing, if you have the time and the client has the budget (reality bites) What Agile doesn't cover, IMO, is: 1. analyzing the cost of "altering the course" 2. updating the documentation so you have a record of what you changed and why 3. renegotiating the contract when changes occur And in the asinine category: 1. do just the minimum to get the functionality in 2. refactor often (or something like that) [edit] Oh, and the only way I've gotten Agile to really work is to take a declarative approach to programming. Separate the declarative from the imperative, and your development process becomes, by defacto, more agile. [/edit] Marc
I'm not overthinking the problem, I just felt like I needed a small, unimportant, uninteresting rant! - Martin Hart Turner
>And in the asinine category: > >1. do just the minimum to get the functionality in >2. refactor often (or something like that) Just wondering what has led you to this conclusion?
-
dmitri_sps wrote:
This "we don't need no education" manifesto was born by dot-com boom, when fresh graduates flooded start-ups, with the only "business plan" just to do something, which could be sold later. Later it clicked with management for all the wrong reasons, which you well described in your rhetoric question
Although that might be true, I can only note that the other formal methodologies are almost universally not followed as well. Most companies either do nothing or do so little that no one realistically suggests that they are following any methodology. Other companies claim adherence and yet examination shows that they are in fact not following the methodogies - they implement some of the easiest practices in a ship-shod fashion and completely ignore the harder ones (which actually produce the most bang for the buck.) There are of course some companies that do implement some formal methodology correctly. But the number is so low compared to total developement numbers that it is effectively zero.
jschell wrote:
the other formal methodologies are almost universally not followed as well
I do not see this as a problem. Among successful companies, as you correctly mentioned, there are some who do it by the book, and more are made successful by competent managers and professional developers who do not follow any formal methodology, as they are past a need for a textbook. And similarly different are the loosers in IT world - both who try to follow some methodology on paper, and those who do not have a clue. The later bunch, when they found out that there is such thing as "agile" methodology, gladly jumped on it, just as the Dilbert cartoon (quoted somewhere in previous replies) depicted so well ;)
-
Yes, I think you have to be careful that agile doesn't just become "lets not do any design" like the 'marketing/bad business people' want, but instead agile is recognising that doing all your design up front isn't necessarily the best thing because you discover new things as you go along that you could never have realised from the beginning. I'm not talking about changing requirements, I'm talking about the fact that half way through your project you discover that your design doesn't quite fit and you need to make changes. One of the things about agile that I do really like is the idea of "release early and often". This way you keep your client informed of progress, and get instant feedback so you don't go off in the wrong direction too far if something has been misunderstood. (By release, I don't necessarily mean full access release to the client, but some form of release to testing, or release as a sample of what's been done so far) Fixed requirements are still important, and lots of design is still important. Most methodologies seem to preach "their way" as the perfect path, but ideally I think you need to take the best from all of them without religiously adhering to any one. Different projects have different characteristics and priorities. If you follow any specific one too strictly you won't be flexible when the project isn't going exactly as the methodology allows for.
Simon
I think Simons response is about the most balanced of those I have seen here. No, in itself Agile is not simply a justification for bad business practices. On the other hand, I've seen plenty of organisations that use the term as an excuse not to plan. No-one would spend a million dollars on a new high rise building without a fairly comprehensive plan. Having said that, no-one would expect that plan to go down with the level of specifying where every individual nail will be placed. Plenty of people seem to attempt to write software with those extremes of planning though.
Good advice is always certain to be ignored, but that's no reason not to give it.