Is Agile just a justification for bad business practices?
-
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
Please read the Agile Manifesto and Principles agilemanifesto.org/principles[^]. Whilst what you describe may well be how many people are experiencing development, it doesn't match the clearly stated goals of agile. Agile done properly, as with most things, works extremely well.
-
Please read the Agile Manifesto and Principles agilemanifesto.org/principles[^]. Whilst what you describe may well be how many people are experiencing development, it doesn't match the clearly stated goals of agile. Agile done properly, as with most things, works extremely well.
That's like saying read the bible, it has all the answers and is crystal clear. That is why we have unlimited versions of christianity, each of whom is convinced they are right. That is also why Agile people seem to claim failures as "you just didn't do it right". My problem with Agile is that it claims to be all things to all people mostly by being completely unspecific. This allows the bad business processes to be propagated because Agile will equally say do design if you need it, don't do design if you don't need. If you have been failing in a process, then any process change could help. I think Agile has been successful "rescuing" people who were failing. Since their is no head to head comparison, there is no way to really now what made it successful. I think there are many cases where Agile is a very poor fit. And I have personal experience with switching from a working process to Agile where it decreased output, productivity and quality. That being said, trying to do a full end to end design up front is a bad idea. Doing little or nothing, for any system beyond the most simple, is a really bad and expensive idea. Unfortunately, this is how Agile is often interpreted.
-
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
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
-
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
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
-
Agreed. My experience is that if you have access to users/customers, design when needed (iterative design) works well because you can get a piece done, verify it is what is needed, then concentrate on the next piece. 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.
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
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
-
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