Why Agile Development Fails (Sometimes)

Agile consultants ruined the software group I work in. Making good software is hard, and anyone claiming to have a magical process that guarantees good software is selling snake oil. I can appreciate your wanting to make a buck, but would also seriously appreciate it if you could find some other industry besides software development to go screw up.” – Anonymous Agile Victim

 ********

I want to start this post by making one thing perfectly clear: Agile development and testing practices have worked wonders for thousands of organizations. Whether it’s decreased time to market, improved communications or lower costs, the positive aspects of Agile are well-known through the software development industry. And since so many software professionals have had so much success with approach, who I am I to tell them they are wrong? No, this piece is not meant to discredit Agile or the people who promote it.

Instead, I wanted to take a deeper look at all the times when Agile fails. For all its proponents, Agile has its fair share of skeptics and detractors. These are people who have a much different Agile experience – one characterized by chaotic processes, lower quality, miscommunication and numerous other problems. As you might expect, these people tend to have extremely strong opinions on what they consider to be the shortcomings of Agile. Here’s one comment from our very own software testing blog:

“This system is bloated with meetings, excel spreadsheets and anemic of any real documentation. Agile and the people who support it are full of themselves and their aversion to documentation is detrimental to real active communication. The disinterest to documentation presumes humans will retain meeting to meeting barrage of verbalized ideas. Agile is full of egotistical self congratulating ideologies over used buzz words like “flexible” and “living”. People can’t remember what they said from one over stated meeting to another.”

Ouch. Clearly, there’s a disconnect here. How can one approach work magic for one group and fail miserably for others? The full answer to that question is admittedly beyond the scope of one blog (or perhaps even one book), but I wanted to address some of the most obvious reasons. Let’s take a look:

Old Habits Die Hard
Based on my observations and those of several noted experts, Agile seems to “fail” whenever it’s forced on a team or organization that is accustomed to other methods. After years of developing and testing in a certain manner, one cannot expect an entirely smooth transition. Want proof? Here are a few results of a recent survey that interviewed 200 companies that had recently transitioned to Agile:

Out of over 200 participants, 64 percent said that switching to Agile Development was harder than it initially seemed. Forty percent of respondents did not identify an obvious benefit to the practice. Out of those who did, 14 percent thought it resulted in faster releases, and 13 percent – that it created more feedback. Seven percent of participants noted that Agile developers were happier due to reduced future planning and documentation.

According to Voke, since the global financial crisis of 2008, the average cost of software projects has seen a sharp rise, even though developer teams have become smaller and the deadlines tighter. Meanwhile, the risk of software failures associated with Agile Development has remained high.

“While many people assume that Agile is faster, better, and cheaper, actual results vary greatly. Many organizations are diving into the Agile movement without a clear understanding of what it is, and what the consequences of adoption may be. They may not realize that today’s solutions are tomorrow’s problems,” said Theresa Lanowitz, lead analyst at Voke. (link)

I think it’s fair to say that the process of “going Agile” must be clearly explained and outlined (more on this shortly), otherwise your development practices will change, but in name only.

“I don’t think most people need convincing about agile principles, even if they’re just attracted to the idea of frequent delivery,” said Nate Oster, an Agile Player-Coach and Founder of CodeSquads LLC. “In practice, however, a lot of waterfall behaviors survive by hiding behind the new agile jargon.  If we want different results, it’s not enough to change our jargon, we have to actually change the way we collaborate!”

He continued: “I think the deep-down objection to agile is that it challenges our hidden assumptions.  A lot of our cherished ‘best practices’ from waterfall are actually optimizations of ‘our job’ – they make us ‘efficient’ but actually undermine the agile goal of frequently delivering high quality software as a whole team.”

In terms of waterfall legacies, Nate gave me the example of how some test teams still request that a feature be 100% complete before it’s ready to be tested.

“That’s a verification mentality, a holdout from waterfall when it was the tester’s job to efficiently find all the bugs,” he explained. “On agile teams, we prevent those bugs by specifying the feature as a team using testable examples, then we build those behaviors in small slices.  When we work in small increments like this, we test continuously instead of at the end. That’s how we prevent ‘mini-waterfall testing.”

So is making an Agile transition impossible? Not at all. Is it difficult? Yes. Is it necessary? Here’s what Agile expert Scott Barber once had to say on the matter:

I believe that the trend to “go Agile” is misguided. If a company is developing good software, the people involved in developing that software are happy working there, the software development is sustainable, and the business is being adequately served by that software, there’s really no need for them to try to be more or less Agile. Agile has challenges like any other culture, but the single biggest challenge I find is companies trying to solve development, process, management, and/or schedule problems by “going Agile.” Teams who have grown up in a culture that is fundamentally different than Agile simply will not find it easy to “go Agile.”

Unrealistic Expectations
Another reason why Agile sometimes fails has to do with unrealistic expectations of the Agile actually is and what it can help you achieve. Agile is commonly believed to be a set a practices, processes and tools, when in fact, Agile is really more of a mind-set and culture.

Processes vary depending on the company, the product and the personnel, so it’s no surprise that they sometimes fail when they are misapplied. A mind-set and culture, on the other hand, can transcend those factors. Here’s a good analogy of this problem from Scott Ambler (emphasis added):

Would you take the same approach to create a web page describing your family and the embedded software for a NASA space probe? Of course you wouldn’t. What about a business application and a NASA space probe? Likely not. Would you take the same approach with a team of six people that you would with a team of sixty people? Or six hundred people? Once again, likely not. Different situations obviously call for different approaches.

It’s easy to see that you need to take a different approach developing a web page as compared to developing a space probe. Your company likely doesn’t develop both web pages and space probes, so it’s easy to stand back and recognize that there’s a difference. It would be clearly foolish to follow similar approaches on these projects – a very simple process is sufficient for the web page development effort whereas a complex and rigorous process could be appropriate for the space probe. You would put the space probe project at serious risk following the web page process and you would incur significant costs following the space probe software process to develop your web page. Clearly it is important to follow the right process.

Basically, if you expect Agile to perform miracles or instantly transform your software development process, then you’re likely to view the method as a major failure.

Department Fragmentation
What happens when a development and product team adheres to the principles of Agile, but the QA team does not? Conversely, what happens when a QA team wants to be involved early in the dev process, but the engineering and product teams resist? What happens when executives want everything to be Agile even if they don’t really understand what it means?

“When I hear ‘we have an agile test team,’ I think that’s a contradiction in terms,” said Oster. “If all they do is test, then they’re not really an agile team.  Agile teams frequently deliver high quality software, and that includes testing.  An agile ‘feature team’ needs all the skills it takes to deliver software, and that includes programming, analysis, and testing skills, regardless of who performs these tasks.  I love it when new agile team members start cross-training outside the role on their business card.  Mature agile teams know there isn’t a sharp line between ‘my job’ and ‘your job.’  There are just tasks we need to complete, and everyone brings different skills to the table, so that we can complete them as a whole team.”

As mentioned previously, Agile is not a playbook. It’s not a set of directions. It’s not a checklist. As Scott Barber said, it’s a mindset and a culture – and it needs buy-in across an entire organization in order to succeed . Here’s a great presentation by Agile coach Mike Cottmeyer that explains the importance of agile being adopted by multiple departments:

Giving Up Too Easily
As we’ve covered, the transition to Agile isn’t easy. I’m sure every department thinks they have the steepest climb, but since this is a testing blog, we’re going to focus on the QA department and its ability (or lack thereof) to move to an agile process. As Nate Oster points out, the problems of the agile transition have less to do with Agile and more to do with existing practices.

“In my experience the biggest challenge with adopting agile is how it just relentlessly exposes what we’re not very good at yet, and in a lot of organizations, that includes testing,” he said. “When the goal is frequently completing new features, that forces teams to work in small batches with short timeframes, so agile exposes how traditional testing is optimized for ‘throwing a big pile of code over the wall.’ Traditional testing is really a broken system, because these huge piles of work arrive late in the game.”

When trying to adopt Agile practices, there will be a ton of excuses as why it won’t work. Those who understand the real benefits of the approach – and genuinely want to make the transition – will likely have success. Those who are searching for reasons why it will fail – well, they will likely find them and either abandon the effort entirely or end up practicing what Elisabeth Hendrickson calls “fake agile.”

********

I wanted to close this post with an open-ended question to all of the testers, developers and product people: Have you experienced Agile failure? If so, what were some of the reasons why? The same goes for those who have Agile success. Either way, please share your thoughts in the comment section below.

*Special thanks to Nate Oster for taking the time to answer my questions.

Essential Guide to Mobile App Testing

Comments

  1. says

    Though there are many anti-inflammatory drugs out in the market that are able to give
    arthritis pain relief , proper training, exercise, food intake may slow down or prevent the development of arthritis.

    · Wing Chun (forever spring) . s martial arts classes
    in Sandy, children really feel that they have succeeded.

  2. says

    Hi it’s me, I am also visiting this website on a regular basis,
    this website is actually pleasant and the people are genuinely sharing good thoughts.

  3. Greevous says

    I’ve lived through an agile adoption in a large corporation that was going wonderfully…. it was scaling up, dozens of teams, visual management, etc. It’s now failing. Why? Management turned over.

    Agile is essentially a culture and a way to addressing problems. When management turns over, without even realizing it they begin to undermine everything, because they weren’t adopters .

  4. says

    Hmm it seems like your site ate my first comment (it
    was super long) so I guess I’ll just sum it
    up what I wrote and say, I’m thoroughly enjoying your blog.
    I as well am an aspiring blog blogger but I’m still new to the
    whole thing. Do you have any tips for novice blog writers?

    I’d really appreciate it.

  5. says

    Acceleration is a fast growing start-up which is having their ERP Web solutions for Education, Finance & Hospitality domain.

    Recently they have started with training modules for Dot Net / JAVA / PHP technologies & Android / Windows 8 Framework application development. Good opportunity for 6

    Week / Internship program for all Engineering & MCA.
    They are Industry professionals to train & get you prepared for IT Job Interviews. The Good part is they have seperately added a interview preparatory technical

    programs to get you qualify in any IT interview.

    Add-Ones for training profile: –

    –> Technical Leaders & Managers from Industry to train
    –> Live project development Exposure
    –> Valid Pvt ltd company experience
    –> 100% Job Assistance
    –> Personality Development Sessions + Resume Writing Tips
    –> Free Mock Tests for written exams for Interview Cracking

  6. JD says

    wow…lots of salty people in this world, and most of them appearing here as posters on this blog. lots of bitter people, snarky, even ignorant. i highly suggest to each poster, introspecting on what you wrote, putting it squarely in context to the values and practices of agile (scrum for example) and find that virtually all of your commentary conveys a real sense of close-mindedness, and is contrarian to all things agile. it’s nice you took the time to respond, and potentially even read what the blogger wrote about, yet many of you came off sounding like you were sold on agile, believe you actually experienced agile done well, and believe you were burned by it. i cant say for sure, but most of how you replied conveys to me that you did not experience much anything of agile in a proper sense. go ahead and be snarky about my post – sure sure…all i’m saying is that you were not agile enough, right?

    hear what you want to hear, but agile done well, is embraced by many of the team’s i’ve led. you need real sponsorship, strong leadership and talent of all levels of experience, business partners who give a damn to shape and build product with you, and to enjoy the fruits of your success. remember when you started your profession and you thought it was fun. many of you appear to have gotten farther and farther away from that, and i hope you’ll find that bridge back – only then could you possible really consider how awesome agile can be – and your team experience your awesomeness in kind. otherwise, your part of the formula for success, and your negativity will taint your team and increase risk of unrecoverable failure.

    um…no agile team works 72/hrs per week. you’re right…you’re leadership is non-existent. offshore creates challenges indeed. so, i think back to days of manifesto. did they outsource back in those days. no. but now they do. why do they. oh, it’s cheaper faster. perhaps a local team can outperform offshore model, and you can bring it home to your internal team again.

  7. says

    It will demand you to spent time you just read and understand manuals to navigate between various modes along
    with their functions. This range also will come in a
    large selection of colors, so most people would be able
    to find one that meets their own personal taste.

    No matter everything you decide to try this summer, whether it’s mountain climbing
    or cliff diving, this watch has you covered.

  8. says

    Jesus chrsit man :D ….

    second to the writer of the blog my friend i need some suggestion and information as well regarding to software methodology is it possible you can reply me here or you can email me ?

  9. says

    Be consistent in your choices but also be flexible
    to adapt to new things. Fresh fashion ddesign graduates can
    expect a salary of around $1800 a month to
    $2500. Manufracturers now use cubic zirconia, high-end crystals and even diamonds as well
    to make these ornaments.

  10. DonaldB says

    I squirm when I hear terms like “manifesto” and “positive can-do teamwork”, etc. It smacks of so much “KoolAid” and silver bullet mentality you can easily slide into groupthink and confirmation bias. No one is willing to speak up for risk of being labelled negative and not a team player. Agile works best when you have a small, very competent team that lives and breathes the system being implemented… oh wait… insert your favorite framework, methodology, etc for “Agile” and the sentence still works… imagine that!

  11. HSIm says

    Whenever I read discussions on why agile fails and how to avoid it, author often lists examples of why people believe their efforts for agile development failed – e.g., lack of documentation as you listed at the beginning. But misses to cover the issue in the discussion on why should not fail. Most of them simply ends up repeating the same – agile fails for only those who misunderstood it.

    I really want some practical answers to the problems people believe why they failed.

  12. Nick says

    You tried to tell management that AGILE was pie in the sky and its consultants where nice people but definitely full of sh*t but that didn’t get you anywhere because they drank the FASTER and CHEAPER kool aid and face it: you’re just a programmer and all those managers and consultants who never wrote a line of code or implemented a successful project know more about your job than you do……

    BUT somehow you just got to admire how something so SIMPLE sounding and so ‘EASY’ to sell can be so DIFFICULT to make work and how your company tried for 3-4 years and never quite got it to deliver its promises because after all its someone’s fault for not implementing it correctly and no one could quite pin down what was lacking and after 3-4 years …everyone finally REALIZED that AGILE was no better and in most cases WORSE that what you had been doing before but you FORGOT what you were doing before because your head is now full of AGILE terms and acronyms. In this context, AGILE is pure genius. You add it to your resume to impress those that don’t know any better and move on to the next magic tool or quit programming all together….

    AGILE is a perfect world framework, a world where no one is ever on vacation, everyone is at the same skill level, people attend meetings on time and come prepared, requirements are clear and concise and are actually done before starting development and where management stays out of the design process…In short, a world run by robots and androids on some science fiction TV show or a simulation game. In the real world, actual AGILE development rarely happens and if you have multi-site or cross cultural development teams, multiple GEO/time zone teams or any team of 10 people or more, it can NEVER happen as the basic raw materials of AGILE methodology do not exist in that reality. If you doubt this, then you have never been on a support call to India or used the Microsoft developers’ forum to ‘solve’ an issue. Imagine trying to solve a dozen issues REAL TIME using these resources and you will understand how truly difficult it is to get people on the same wavelength and motivate them to work together no matter how smart they are individually or how many clever PowerPoint swim lane and causation foils you have. It’s much easier to herd cats.

    You can attempt AGILE in a multinational Fortune 500 company environment, but you will gain nothing and lose hundreds of thousands of dollars in training and consultant charges and BURN your developers and talented project managers out. After your developers and PMs leave, you will be stuck with a dozen or so train the trainer types, SCRUM facilitators and less than stellar project managers, the sum total of which couldn’t screw in a light bulb and who then become AGILE consultants at other Fortune 500 companies. The circle of failure is complete.

    AGILE requires all your ducks to be row for success. If you have a team of 5-6 people who know their stuff AND have worked successfully together before, then go for it, you’ve probably been doing AGILE and never knew it. If it aint broke don’t fix it.

    My experience has been that most development is more agile before AGILE than it is after AGILE. For those of you old enough to remember, IBM came out with the basic framework for successful SW (mainframe) development around 1980 (or before) very similar to AGILE which their consultants taught and had much more practical results and methodology, but was just called common sense back in olden days.

    Like ITIL, Six Sigma, TQM, etc. Agile is just a MBA school buzzword for magic thinking. It just doesn’t work where it’s needed most (big IT and development shops) and it works great where it’s NOT NEEDED, like small developer shops. The real beauty of the concept is that that it extracts the maximum amount of money for consultants, and at the same time looks real good on management goal and shareholder reports while actually never living up to the hype. It lasts for about 3-4 years until then next magic comes along to fix the problems that AGILE was supposed to fix, that ITL was supposed to fix that Six Sigma was to fix etc., etc.

    Years from now when you are closing up at Radio Shack you’ll know I was right

  13. Bill says

    Every agiled project(large enough to be leading in market as commercial product, or at least key player) I worked has failed or is failing, from company to company, here and there.

    There are many reasons, put every blame on agile isn’t fair, but agile is one of a major factor.

    In every team, there is an agile believer, usually senior enough to shut other people’s mouth. He will talk to you face of all the advantages of doing agile. Of course, they are correct( in theory). But in practical, developers and testers are human. If you start using agile as a covert aggressive way(usually management, and bean counters) of pushing them into their limit, they will find their way out. That’s just the nature.

    One last to mention, when company start to laid off people, agile fails faster than company. No matter how good a tool is, it’s the human behind it.

    I have seen enough instances, that agile succeed in the beginning, then management found their excuses to laid off people(i.e. laid off top agile contributors, simply because they had done their job) , cut off budget, sometimes, delay upgrading developer’s computer, when these things happens, agile progressively move into failure stage.

  14. David says

    It presumes software development happens in a vacuum, apart from all other working machinery of the company. So-called “Waterfall” development used to be simply called “Development”. And it evolved in concert with all the other business practices, processes, and management of the company and the industry at large.

    Agile can work IF, in addition to changing the development methodology, you also change all the other business practices, processes, and management of the company. The problem now is that Dev is expected to change, but all the infrastructure around it (which evolved up in a “Waterfall” world) is expected to run business-as-usual.

    The article makes an excellent observation that if a shop is already producing quality software in a timely fashion, “going agile” may be more trouble than its worth. In their effort to turn “very good” into “perfect”, too many companies end up fixing what ain’t broke.

  15. says

    Please let me know if you’re looking for a article author for your blog. You have some really great articles and I feel I would be a good asset. If you ever want to take some of the load off, I’d really like to write some content
    for your blog in exchange for a link back to mine. Please blast me an e-mail if interested.
    Regards!

  16. Chris says

    Word of advice, never accept a job as a BSA when the project has already started, there are no requirements and your entirely playing ketchup finishing requirements a day before the development ends, praying to God that the developers wrote what they should have and wondering why the hell you even wrote the requirements because they weren’t referred to during development. Not to mention that somehow your supposed to find time to actually gather requirements. If thus keeps up ill be walking out before I get fired for missing a major issue.

  17. forcewill says

    Agile failed in my case, because managers at least in my company used that for an excuse to have “Interactive Design” meaning today you implement code to support the design and tomorrow you are refactoring evertying, also used as an excuse for putting people that always try to give 100% to give 200% (My case was 2 months working 72 hours per weak),

    And meetings were to discusse things non related to development but for example the development team add to wait until in the meeting they figured out a solution for an UX problem.

    Bottom line Agile cannot be used to put people working like dogs, i believe Agile has its advantages when used correctly and in a “humanized” form

  18. Slightlycynical says

    Two challenges of Agile I haven’t seen a solution to:
    1) On/Off shore teams – Oftentimes testing is done off shore while requirements/dev may be done on shore (or some config of). If you are trying to support a 5-7/24 follow the sun model, it’s not possible to have people sitting in meetings all day together. It’s quaint and lovely but..

    2) Some technology does not do well testing codes in chunks when the release itself will be packaged. Oftentimes the environments we work in is so integrated that giving me a chunk of code to test is like testing the air. You need all the piece parts to see how they work together.

    Anyone else seeing these issues with Agile? I’m learning more from the comments than the article. Thanks!

  19. says

    According to me lack of Test Driven Development (TDD) can also be the reason for failing of agile testing.In agile testing multiple automated testings are carried out continuously and if any of the test failure is ignored can lead to the failure of entire agile testing.

  20. David says

    If you take a team of competent developers that communicate well with each other and put them in a room with business users who can continually guide them, it doesn’t matter what management methodology is used: the project will be successful. I have never seen an Agile project succeed, except for one developing a marketing department driven website. The business owners were there every day giving direction. I work only on very large, complex custom software applications and have never had the luxury of being on a team where all resources are committed 100% of the time.

    I bristle at Agile evangelist’s opinion that if a project fails using agile it was because it was not agile enough.

  21. Bryan says

    Having read the article, plus people’s comments – the issue seems to be that there is a degree of flexibility required which both Agile and Waterfall methodologies fail to realize.

    Sometime Agile can give the required benefits, sometimes Waterfall can give the required benefits.

    Both fail when team members are inflexible (and it can only take one team member to cause this).

    Both Waterfall and Agile succeed well when team members are involved early in decisions made and connect often to ensure that changes are socialized.

    Realizing that Agile is mini-Waterfall, and Waterfall is a maxi-Agile process helps.

    Acting as if one method is uniquely different from the other and invoking elitist thought patterns causes friction.

  22. TvD says

    The whole discussion is a non issue. Of course Agile is not a magical spell that resolves all of the problems and of course you need to implement “agile” (and all of its consequences) in a proper manner.
    In general:
    - if you are not doing what you are supposed to do, than you won’t reach your goal.
    - if you are not able to do what you are supposed to do, than you won;t reach your goal either.
    - if you try to resolve a problem with the wrong method, than you also won;t reach your goal.

    Driving by car is much faster than walking somewhere, BUT:
    - if you dont have the key, tjhere is no fuel, you can;t drive and hit a tree or there is no rioad THAN it isnt
    - if you decide to sit in the backseat and not drive at all, it isnt either.
    - for very short distances, getting in the car, starting it, parking it and getting out again takes more time than walking.

    Agile development creates (IF IT IS WELL PERFORMED AND COMPARED TO WATERFALL):
    - better, earlier and cheaper end results for the very simple fact that the factor change is continuously considered, where in waterfall it isn’t (change procedure).
    - better financial steering because the method requires continuous feedback on spending (where waterfalll doesn’t)
    - also (but waterfall does too) will give sufficient documentation etc IF IT IS REQUIRED (with the right implementation, next to the product owner ALSO an operational owner is appointed who REQUIRES the delivery of that documentation, amongst other things).

    All and all if Agile and Waterfall are both performed WELL, the advantage of Agile is the adoption of change and therefore also cheaper and faster because it can adopt the (unavoidable ) change easier and earlier.

    TvD

  23. says

    At the end of the day, all agile has done is substitute overly short term thinking for overly long term thinking while preaching the joys of verbal communication.

    We need to move beyond agile; how to do that I cover in more detail on my website

    PA

  24. Adrian Speteanu says

    I have witness Agile fail. Not just at a team level, but at an organizational level as well. I didn’t realized the second until I read this article and the links in it. I’m a QA, so I also experienced at some points the tendency to be demanded an old style of testing even if the project was being developed with no process at all (even if we called it agile) and subsequently my own failure to impose more efficient ways of working…

    But as a response I would like to RANT (so bare with me) about the agile “evangelists”, as I see them: those who talk about fake agile and so on. There is no watterfall – agile transition. The success of the so called agile is the ability of developers to deliver faster, on a [more] constant basis… has nothing to do with process, but with good use of the existing tools on the market (which has them today) or good code-project management if you don’t like those tools.

    All the other things mentioned in the article or the presentation as the reasons for success are general, not just to agile, but to good project management and good development in general (the ability to estimate accurately, is this needed only in agile? common!!)…

    Furthermore, having a previous successful waterfall experience to those failed agile experiences, I would have to say that agile is an improvement to those teams that use no process in the first place. Otherwise, good agile/waterfall depend on good development in the first place…

    The place where so called agile differentiate from waterfall for real is at management level. Product management is where agile fail – the inability to provide good requirements to a development team that has good use of the tools available will kill a project. And this has nothing to do with programmers/testers but with the whole organisation, or the ability of a single person to deliver…

  25. shotsie says

    If you use the analogy of the steps to: 1) build a house, 2) adding an addition to an existing home, and 3) re-modeling an existing home, you’d see that the waterfall development process works best with 1), spiral development (or mini-waterfall) works for 2), and agile works for 3).

    So, I believe that agile works best when there is a mature product to tweak – one that doesn’t need some major feature added, and only minimal documentation changed. Then you really only need a small team of developers/testers who can perform the coding/testing cycle fast. But I have been involved in 2) done in an Agile methodology, and the developer ignored those pesty steps of derived requirements and customer input to the design, so we went through many more iterations of code/test than if we had just performed a normal spiral.
    The other problem with agile is that outsider suggestions are usually treated with contempt or just ignored, since the team is so small and closely bonded.

  26. says

    Reacting to this: ““When I hear ‘we have an agile test team,’ I think that’s a contradiction in terms,” said Oster.”

    I think there are agile test teams. Thinking in 2 week long sprints, on the first week the devs are working on the (small) features, like putting a new module on the web page or implementing a new error message. The testers are working on test case design + starting to code the automated tests…in whatever language they decided to use. Can be Java, Cucumber+Ruby, etc. Does not matter. What matters is to have some kind of automated regression. On the second week, when the feature is almost ready, you can try out the test code (which is almost ready as well) on it. Finally, both devs and testers finishes the coding work, they put the automated test case into the regression set and they can have a manual test round too.
    I had a project which had more than 10 000 regression tests written in Java. I heard MS had 500 000 auto tests for outlook 2007. So…there are agile test teams!

    And finally another topic: I support the idea to make testers to write application code and make the devs to write test code. We call these guys devsters…or testelopers. ;)

  27. Jonathan says

    I have been a part of several failed agile projects. One of the issues I have encountered is that iterations are never planned with FAILED tests in mind. The 2 week sprint is held as an ideal and an unbreakable deadline but often issues are discovered as the test process gets pushed to the second week of the sprint (at best) with the first week used to design test cases). There is rarely time in the iteration to fix the issues as the “agile” team try to squeeze every second of development time into the sprint. This causes havoc with quality control. Another issue is one of integration. Companies adopt agile believing that each iteration will be live with its new feature set after 2 (3, 4…) weeks, but often in large systems there are multiple issues integrating into a live environment. No time is allocated for integration and system testing prior to the live upgrades resulting in poorer user experience and more undiscovered issues, which then force there way into the next iteration or sprint, causing the iteration to either drop functionality or squeeze more in. These are I guess communication and planning issues but seem to be prevalent and common on agile projects I have worked on.

  28. Geoff says

    I think many are missing the point, As the first paragraph said above, Agile is a Mindset. Its main purpose is to keep the users in the development loop, so that they can see progress and feed back issues to the development team sooner rather than later, you can fit Agile approaches into a SDLC and get the benefits of both an organised processes with Document Control, Change management and QA, with automated deployment procedures, and use the Agile at the user interfacing end of the project. Doing it this way, I have achieved repeatedly, projects ahead of schedule with room for tweaking and performance improvement.

  29. Kim says

    Why do people think Agile is solution to every IT project. Please keep the following in mind before you dive into Agile for your project:

    1. Not all projects nor all phases are good candidate for agile. You should use agile if you can deliver a tangible UI enhancement in a sprint or maybe two. Some projects may spend months developing backend architecture without any UI work, which is valuable for future work; but may not be testable by testers other than developers themselves.

    Good candidates for Agile is web site development and enhancement, which can deliver tangible UI changes in a sprint or two.

    2. Not all IT project delays are caused by technical people. Big project may have small technology component. You may spend more time getting stakeholders to agree on something than actually building something.

    More to come…

  30. says

    Very nice coverage of some of the real challenges of an agile transition. I did not notice coverage of the issue raised by someone’s unhappy client in the quote at the top of the page, though.

    Sadly, there is an overabundance of coaches, consultants, and ScrumMasters who do not yet have enough experience to be guiding organizations through these dangerous seas. Yet these coaches are naturally anxious to gain that experience.

    We can’t pin that one entirely on the organization: Coaches need to be honest and professional about their levels of experience, and not be in a big rush to be the sole “Agile Guru” (gah!) at the organization. Large-scale Agile transitions require at least two coaches (internal or external); who are both willing to risk getting canned by surfacing uncomfortable truths to the execs, and who cover each other’s blind-spots.

    The organizations are unwittingly complicit in this: They often see “Agile” as a cost-cutting mechanism, and use their own cost-cutting approach to hire the least expensive coach they can find (akin to hiring the cheapest surgeon to perform experimental surgery on your own body). If you hire inexperienced ScrumMasters, don’t expect great changes. If you hire “Agile” staff-augmentation, don’t expect them to lead you out of your self-imposed chaos.

  31. Jason says

    @Adam
    Testing should be done the minute usable code is checked in, built, and deployed to an environment. Usable code would be a UI portion (static page), Backend portion (DB) or anything in-between (connection strings, jobs, etc).

    Testers should be looking at it continually so that can better adapt the tests based on their findings. It’s also helpful to the developers because they may discover a flaw before the code is complete that could potentially reduce domino effects later.

    It all depends on how your features are divided and what type of testing is needed for the feature.

    Bottom line: If you are coding everything in one environment and waiting until everything is finished before pushing it to a test environment, you will be asking for bottleneck problems. It’s best to stagger features allowing the tester time to cover each when resources are limited.

  32. Dan says

    My last contract job was at a place that claimed to be agile, but in fact they were just trying to go fast, and not focus on the most difficult challenges til the end. Predictably, they wound up with the “easy stuff” working pretty well but not meeting all the needs of all the users. Turnover ruined the long-term potential for success and they are still struggling seven months after project go-live.

  33. Steve says

    I think the goal that agile is trying to reach is noble but there are shortcomings it will never overcome.

    Any good software application will have an architecture.

    The architecture provides a common framework of re-usable components, templates, styles and behaviours for the application.

    Working in incremental stages you may add 3 things towards your 10 thing list and you can even test them 100%… But the second someone modifies the code for things 4-10… Any one of them can break the 1-3 things that were already fixed and tested.

    Anyone that thinks they can clear out massive chunks of testing before the final release is fooling themselves.

    The other issue in Agile is that all developers are considered equal. However this is a fallacy an there are specialist for a reason. Doing the UI for a screen might be a 4 point task for me but a 20 for someone else… Ditto for a SQL task if I don’t know the schema… 20 for me, a 2 for DBA.

    Finally in many environments getting customer feedback into the loop is much more trouble than its worth… And often puts pressure on dev teams to accept bike shedding instead of having a company vision.

    Steve
    Agile-ish developer

  34. ZA says

    About a year and a half ago, I joined a company that is presumably agile. Our manager was a cerified SCRUM master. We were spending whole mornings on meetings that after a while were concentrating on one of us who was in charge of dealing with the core technology.
    There were some other modules to be developed and I was probably the only one who understood the requirements, but I do not know (and don’t care to know) Java. I suggested to do them in Perl and be done with. Three months were wasted with the argument that we have not yet decided on the technology.
    At a certain point this manager was gone as well as most of the team. The new manager told me to code it in Perl, which I did and the project succeeded (at least from the technical point of view). But the best part was that we did not have any SCRUM meeting or whatever. We did not have pair programming, we just developed what we needed to develop…
    This was my first, and hopefully last, encounter with Agile
    ZA

  35. Sumeera Nangia says

    I have seen agile process work to some extent in our company. However, the major concern I have with it is the interpratation that we can run away from documentation. I am a strong believer that you should not have unnecessary documentation in place but if you attempt to take away written requirements/test plans in the name of agile, it may not work out to anyone’s benefit.

  36. Michelle says

    Sometimes Agile fails for serveral reasons
    1. The term agile is used to avoid doing work or due diligence
    2. The term agile or the agile process like Scrum is not understood
    3. The agile process focuses only on technology not the other aspects
    4. Key aspect of agile are not practiced like focused daily scrum meetings with all relevant team members
    5. Agile is being applied to a project that should be using a different methodology… one size does not fit all
    6. Different teams on the same project are not all using agile… so the different methodologies bump or sometimes crash into each other …

    There are many more reasons … but in my expereince the above are the top 6 reasons

  37. Adam says

    Hi,

    Could you explain testing in agile team?
    When testing should be done?
    For example, there is a team of six developers, they have two weeks to make three new features.
    So when testing should be done, if all features are finished second week (for example Thursday ) and now there is one test specialist.
    So, does he/she have to ask developers to commit parts of code (feature’s part), test it, wait for another part, test it and then, on Thursday, test the whole feature (one of three)?

  38. David says

    I test software for a large and successful application. The shop where I work for has been moving toward Agile for several years. I see Agile’s value in that it (a) forces developers, testers and designers to talk to each other, (b) allows for easy changes of requirements, and (c) minimizes spec documentation.

    Here are two points where difficulties can arise. One is that it is difficult for the testing group to transition from waterfall to Agile. I would argue that, with a large software product, some whole-system testing is necessary before a major release. But the final waterfall-type testing period does not seem to be shrinking fast enough. A second issue is the problem with getting tests automated. Ideally, the test for a new feature should be automated ASAP and then tested once an interation for the rest of the cycle. But generally the Agile tester is outnumbered; several developers can generate a lot of code to test in one iteration. Even if the developers help test, the tester barely has time in an iteration to write test scripts for all the new code and no time for automating the scripts. We automate test scripts but are usually many weeks behind, so this chance to boost testing efficiency is missed. It is a matter of time and manpower, two things that the testing group never has enough of.

  39. says

    In my opinion agile sometimes fails because the companies, expecially the big ones, try to re-invent the agile methodology.
    The management is not fully aware of what the agile methodologies means, and the implementation is often in charge only of the sw developers.

  40. Roe says

    Agile fails when developers are not well known or not able to resolve issues on time because there will be piles of tasks in pending state. It didn’t meet all of its iteration goals and was no more productive than it had been before.
    What do you say?

  41. says

    If you look at the value of Agile, it is fundamentally about earned-value management. In typical waterfall or iterative processes, teams live in the illusion of progress by checking activity progress on a gantt chart. In the agile world, you shift towards demonstrable progress every 3-4 weeks. In that way, you are able to manage the value you are delivering to the business. The challenge? change.

    So, for what it is worth, teams could be using requirements tools, modeling tools, no test automation, and claim to be Agile, if only they can demonstrate real tangible progress.

Trackbacks

Leave a Reply

Your email address will not be published. Required fields are marked *