Re: Agile Anti-Patterns - a discussion Go to top ] Posted by: Chris Turner

Posted on: April 30 2008 11:12 EDT

in response to Priyanshu Goyal From my experience on a number of agile projects I tend to agree with all of the anti-patterns above. I have come across a number of cases where organisations decide to adopt 'agile' but then try to fit it into existing practices and hit one of more of these issues. I would also like to suggest one more: Micro-manage developer work: I have found a number of cases where an organisation adopts an agile process but rather than trusting the agile team to complete the iteration they try to assign a project manager to micro-manage the tasks of each developer working on the iteration. This always results in loss of team cohesion and in the worst cases each developer working on a slice of the iteration in isolation from the rest of the team. Reply to this Reply to original

Agile is what works for an organization Go to top ] Posted by: David Karr

Posted on: April 30 2008 12:10 EDT

in response to Priyanshu Goyal We are doing continuous integration so we are already agile: Agile is something which you either do or you do not. There is no partial way of doing it and doing it partially will not take us anywhere. Agile is more about doing development in iterations, working code, customer feedback, adapting to changes rather then picking and choosing few practices and calling yourself agile. I agree with everything you said, but this statement bothers me. I agree that only doing CI is not "agile", but I disagree that someone can prescribe an exact set of requirements for being "agile", and if you don't follow every one of those prescriptions, you are not "agile". Being agile means building a process composed of agile principles that works for the organization. I agree with everything you said, but this statement bothers me. I agree that only doing CI is not "agile", but I disagree that someone can prescribe an exact set of requirements for being "agile", and if you don't follow every one of those prescriptions, you are not "agile". Being agile means building a process composed of agile principles that works for the organization. Reply to this Reply to original

Write test cases for everything Go to top ] Posted by: Ryan Shillington

Posted on: April 30 2008 18:24 EDT

in response to Priyanshu Goyal Somewhere near 500 test cases, you'll realize that "Unit testing the complex pieces is enough" isn't such an anti-pattern. Of course, there are extremes to both sides of this argument that everybody will agree with. 500 test cases is not an extreme. The bottom line is that test cases need to be designed and thought through so that they're efficient and effective. If a test case costs a lot to maintain but never finds any real bugs then redesign it or delete it. Don't write test cases that eat up your nights in maintenance costs. They aren't worth it. Reply to this Reply to original

Write test cases before implementing logic Go to top ] Posted by: Iwein Fuld

Posted on: May 13 2008 04:29 EDT

in response to Ryan Shillington Don't write test cases that eat up your nights in maintenance costs. They aren't worth it. Completely agreed. Test driven development is not about coverage alone. It is about letting the tests help you focus on solving the problem. Generating tests for getters is not going to help you in any way, it is just going to slow you down (which is precisely the thing we should be avoiding). This is not an excuse not to write tests though. If you have low coverage it is a symptom of using a flawed method of producing working software. You should fix the method, not write tests afterward. Completely agreed. Test driven development is not about coverage alone. It is about letting the tests help you focus on solving the problem. Generating tests for getters is not going to help you in any way, it is just going to slow you down (which is precisely the thing we should be avoiding). This is not an excuse not to write tests though. If you have low coverage it is a symptom of using a flawed method of producing working software. You should fix the method, not write tests afterward. Reply to this Reply to original

Re: Agile Anti-Patterns - a discussion Go to top ] Posted by: Erik Engbrecht

Posted on: May 01 2008 13:37 EDT

in response to Aaron White But what if there never is a maintenance cycle? I think that's a much more important question than people realize. A fair number a applications just die during or relatively soon after initial development, and even more become zombies that are used at levels significantly below the original intent and therefore not maintained. The users just live with the problems. I think that's a much more important question than people realize. A fair number a applications just die during or relatively soon after initial development, and even more become zombies that are used at levels significantly below the original intent and therefore not maintained. The users just live with the problems. Reply to this Reply to original

That's What Scripts Are For Go to top ] Posted by: Tim Fulmer

Posted on: May 01 2008 14:55 EDT

in response to Aaron White But what if there never is a maintenance cycle? If the app is so small there is never a maintenance cycle one should not be worried about process, design and all the rest. Do a one off script in Perl, PHP, or any other of the hundreds of special purpose scripting languages out there. If the app is only slightly bigger and may need limited enhancement and limited maintenance use Ruby on Rails in an ad-hoc manner without the software engineering. If the app is expected to expand over several release cycles with a growing user base and/or is released to the wild (public internet), that is the time to worry about setting up a rigorous development process, focus on design over individual features, do exhaustive unit and integration testing and all the rest. I've done long running projects with very large user bases both ways and prefer to follow the advice of this article because it is actually easier/cheaper to satisfy business needs and make the consumers of the application happy by using good software engineering than not using it. -- Tim If the app is so small there is never a maintenance cycle one should not be worried about process, design and all the rest. Do a one off script in Perl, PHP, or any other of the hundreds of special purpose scripting languages out there. If the app is only slightly bigger and may need limited enhancement and limited maintenance use Ruby on Rails in an ad-hoc manner without the software engineering. If the app is expected to expand over several release cycles with a growing user base and/or is released to the wild (public internet), that is the time to worry about setting up a rigorous development process, focus on design over individual features, do exhaustive unit and integration testing and all the rest. I've done long running projects with very large user bases both ways and prefer to follow the advice of this article because it is actually easier/cheaper to satisfy business needs and make the consumers of the application happy by using good software engineering than not using it. -- Tim Reply to this Reply to original

Re: That's What Scripts Are For Go to top ] Posted by: Gary Braswell

Posted on: May 02 2008 10:17 EDT

in response to Tim Fulmer

If the app is expected to expand over several release cycles with a growing user base and/or is released to the wild (public internet), that is the time to worry about setting up a rigorous development process...



..it is actually easier/cheaper to satisfy business needs and make the consumers of the application happy by using good software engineering than not using it.



For the most part, I agree; a couple of points, however. 1) Agile is not the only approach that accomplishes "good software engineering". 2) If you have a dedicated team that is willing to embrace agile, I believe your statement about it being "cheaper" is true. However, if you are doing a fixed bid custom solution using matrixed resources where every hour counts against your margin, and the customer does not have the budget to support your approach, then your assertion that it is "cheaper" is not true. It goes back to my assertion that Agile is a great tool for certain problem sets, but no approach can be applied universally in the technology space - there's just too many permutations in the real world to be that inflexible. For the most part, I agree; a couple of points, however. 1) Agile is not the only approach that accomplishes "good software engineering". 2) If you have a dedicated team that is willing to embrace agile, I believe your statement about it being "cheaper" is true. However, if you are doing a fixed bid custom solution using matrixed resources where every hour counts against your margin, and the customer does not have the budget to support your approach, then your assertion that it is "cheaper" is not true. It goes back to my assertion that Agile is a great tool for certain problem sets, but no approach can be applied universally in the technology space - there's just too many permutations in the real world to be that inflexible. Reply to this Reply to original

Re: Agile Anti-Patterns - a discussion Go to top ] Posted by: Gary Braswell

Posted on: May 02 2008 09:58 EDT

in response to Wille Faler "Quality of design and code is as important (if not more) as the implementation of the functionality."



The customer who is paying you to implement that functionality would disagree with you.

Maybe so, but they'll be wrong once the maintenance cycle has kicked in and change requests start pouring in. That doesn't change the fact that the customer is not willing to pay for it initially. Developers don't get to set the terms of the sale in the services industry. They can provide estimates, but if the biz dev folks want the business, the service provider has to adapt to what the customer will buy. Once the service provider has locked the customer in with the initial application build, the balance of power shifts towards the service provider and then you can start factoring in more Agile methods if you like. That doesn't change the fact that the customer is not willing to pay for it initially. Developers don't get to set the terms of the sale in the services industry. They can provide estimates, but if the biz dev folks want the business, the service provider has to adapt to what the customer will buy. Once the service provider has locked the customer in with the initial application build, the balance of power shifts towards the service provider and then you can start factoring in more Agile methods if you like. Reply to this Reply to original

Re: Re: The customer who is paying .... Go to top ] Posted by: Wim-Jan Hilgenbos

Posted on: May 05 2008 11:06 EDT

in response to Wille Faler "Quality of design and code is as important (if not more) as the implementation of the functionality."



The customer who is paying you to implement that functionality would disagree with you.

Maybe so, but they'll be wrong once the maintenance cycle has kicked in and change requests start pouring in. Maybe so, but they'll dont care because that will be someone else's problem. The fact is that many business steer on project output and not project output quality. That being so they wont want to spend too much money on abstract quality. Also remember better is the enemy of good. (good is good enough) Maybe so, but they'll dont care because that will be someone else's problem. The fact is that many business steer on project output and not project output quality. That being so they wont want to spend too much money on abstract quality. Also remember better is the enemy of good. (good is good enough) Reply to this Reply to original

Re: Agile Anti-Patterns - a discussion Go to top ] Posted by: Pam Hickox

Posted on: April 13 2010 12:49 EDT

in response to Cliff Meyers "Quality of design and code is as important (if not more) as the implementation of the functionality."



The customer who is paying you to implement that functionality would disagree with you. I disagree. There isn't a customer around that doesn't consider the quality of what they are getting as important as the functionality. If you deliver something that manages to do the bare promised functionality, but every action outside of that tightly described scenario results in a crash, or corrupt data, you'll see how quickly fireworks go off.



The customer doesn't care about your methodology or your internal processes, but they do care that what they get not only does what they asked, but that it does it well and safely.



I disagree. There isn't a customer around that doesn't consider the quality of what they are getting as important as the functionality. If you deliver something that manages to do the bare promised functionality, but every action outside of that tightly described scenario results in a crash, or corrupt data, you'll see how quickly fireworks go off.The customer doesn't care about your methodology or your internal processes, but they do care that what they get not only does what they asked, but that it does it well and safely. Reply to this Reply to original

Re: Agile is an Anti-Pattern Go to top ] Posted by: Gary Braswell

Posted on: May 02 2008 10:06 EDT

in response to Casual Visitor Hasn't Agile turned out to be one huge Anti-Pattern? Useful only as income source for Agile consultants who sell Agile as universal remedy to companies lacking a software development process? Agile is a tool in the toolbox for us to use. It fits quite well in certain situations. IMO, it is a better fit for product development than for custom solution builds if you can convince product management and the executive team to buy into the approach. I also think it is a better fit for new development than for maintaining an existing application. The time-boxed cycles are not a good fit when you are coordinating roll outs of changes across an enterprise that have to be synchronized based on external dependencies over which the development team has no control. Where the issue arises is when an Agile evangelist takes his "hammer" - aka the Agile approach - and treats every technology opportunity as if it were a nail. Agile is a tool in the toolbox for us to use. It fits quite well in certain situations. IMO, it is a better fit for product development than for custom solution builds if you can convince product management and the executive team to buy into the approach. I also think it is a better fit for new development than for maintaining an existing application. The time-boxed cycles are not a good fit when you are coordinating roll outs of changes across an enterprise that have to be synchronized based on external dependencies over which the development team has no control. Where the issue arises is when an Agile evangelist takes his "hammer" - aka the Agile approach - and treats every technology opportunity as if it were a nail. Reply to this Reply to original

Re: Agile is an Anti-Pattern Go to top ] Posted by: William Martinez

Posted on: May 04 2008 22:34 EDT

in response to Cedric Beust It offers a handful of interesting ideas that everyone should be aware of, but each project and team should feel free to cherry pick whatever idea works for them and leave out the rest.



To me, *that* is showing real Agility.



--

Cedric

http://testng.org I will go further still. You can "be" Agile just by preferring four thing over other traditional four things. That is the manifesto. Nobody there said we should be XP or anything else. Nobody is forcing us to even use ONE of those ideas. Now, if we need a Agile tag to sell ourselves, probably we will need to paid to Agile certifiers. But I don't need that to build good software. And it is not enough either, to build a good software intensive system. William Martinez. I will go further still. You can "be" Agile just by preferring four thing over other traditional four things. That is the manifesto. Nobody there said we should be XP or anything else. Nobody is forcing us to even use ONE of those ideas. Now, if we need a Agile tag to sell ourselves, probably we will need to paid to Agile certifiers. But I don't need that to build good software. And it is not enough either, to build a good software intensive system. William Martinez. Architect's Toughts Reply to this Reply to original

Re: Agile is an Anti-Pattern Go to top ] Posted by: Jeroen Wenting

Posted on: May 05 2008 02:12 EDT

in response to Casual Visitor Hasn't Agile turned out to be one huge Anti-Pattern? Useful only as income source for Agile consultants who sell Agile as universal remedy to companies lacking a software development process? Not necessarilly, but in practice yes. The rigidity with which "agile" is usually implemented makes it so. CI is one example. When a project grows and your test cases become larger and more complex to cope, the build process WILL start to take so long that doing more than a few builds a day (or even more than one) becomes impractical if not impossible. Case in point: a project I used to work on had CI in place. Problem was that the full test suite took several hours to run, the build without the tests maybe 15 minutes. A full build including all tests could therefore not be done more than maybe twice a day at most, and would seriously tax the build server which was also needed to build other systems. So there are only 2 options left: strip the tests out of the automated build, or run a build only at night. We elected to do both. A full build with tests was run overnight, a build without tests scheduled in CC at 30 minute intervals. That way people would get feedback on compiler errors twice an hour, and still get feedback on failed tests at least once a day. The test suite was also tweaked to allow parts of it to be run standalone, so we could run part of the tests before committing code. One has to be pragmatic when doing agile development, but as already noted many of the "Agile" crowd are far from pragmatic. They've become as entrenched in their own ivory towers as the RUP advocates and every other pressure group, believing the full adoption of their ideal world is the only way things can work, and often with no clear idea about whether that ideal world in any way reflects the reality of the systems people in the real world (which isn't ideal) have to work with. Not necessarilly, but in practice yes. The rigidity with which "agile" is usually implemented makes it so. CI is one example. When a project grows and your test cases become larger and more complex to cope, the build process WILL start to take so long that doing more than a few builds a day (or even more than one) becomes impractical if not impossible. Case in point: a project I used to work on had CI in place. Problem was that the full test suite took several hours to run, the build without the tests maybe 15 minutes. A full build including all tests could therefore not be done more than maybe twice a day at most, and would seriously tax the build server which was also needed to build other systems. So there are only 2 options left: strip the tests out of the automated build, or run a build only at night. We elected to do both. A full build with tests was run overnight, a build without tests scheduled in CC at 30 minute intervals. That way people would get feedback on compiler errors twice an hour, and still get feedback on failed tests at least once a day. The test suite was also tweaked to allow parts of it to be run standalone, so we could run part of the tests before committing code. One has to be pragmatic when doing agile development, but as already noted many of the "Agile" crowd are far from pragmatic. They've become as entrenched in their own ivory towers as the RUP advocates and every other pressure group, believing the full adoption of their ideal world is the only way things can work, and often with no clear idea about whether that ideal world in any way reflects the reality of the systems people in the real world (which isn't ideal) have to work with. Reply to this Reply to original

Re: Agile is an Anti-Pattern Go to top ] Posted by: Simon White

Posted on: May 11 2008 17:32 EDT

in response to Jeroen Wenting I've found this thread fascinating, as I (and all of your, I'm sure), have begun to be bewildered by the way the "Agile" (and, for that matter, "XP" and "Scrum") labels are used and abused by software development teams throughout my own and other organisations. The first way this is done is defensivley: A team (or team member), desperate to tick the "Agile" box, pick upon some bit of process extant ('We use RUP', 'Our requirements artefacts are living documnets', 'We don't have a seperate design phase'), link it up to some Agile buzzword and claim to be an agile project. This can be because directions have come down from on high to 'be agile' or an attempt to justify a lack of a proper process. The second big abuse of the Agile label I've seen is that which Jeroen and the OP speak of: Some agile expert or consultancy tries to sell or mandate some Agile process toolkit lock, stock and barrell onto a project team that isn't ready yet. Generally, these people ignore the people and technology part of the PPT triangle, and a focus on Agile box-ticking and do-things-this-way-because-the-[SEI|RUP|Scrum|.*]-says-so . What both of these approaches miss is that Agile development is not a series of disparete process and is not a box ticking excersize, it is an interconnected series of desirable behaviours. Agile teams can respons to changing requirements, deliver guaranteed quality soloutions in an incremental fashion, allow the business to engage with and drive development and so forth. You cannot achieve all these outcomes simply from implementing a few processes in isolation, just as you cannot achieve these outcomes simply be imposing a process regieme on a non-agile team without having the requisite skills and technology in place first. The descision to move to an Agile development model is often a positive one, but descision makers should be aware that succesfull Agile development must be supported by vertical process change throughout the SE structure, and with the appropriate technology and people in place. This cannot be achieved by development teams alone. Reply to this Reply to original

More Anti Patterns Go to top ] Posted by: Ramiro Rinaudo

Posted on: May 02 2008 11:22 EDT

in response to Priyanshu Goyal Management Control: Management selects which users stories go in the iteration, the due date, and who should work in which task. This is the opposite of agile, and does break the rules of team work, specially lack of team responsibility about the work done. Epic Stories: The User stories are Epic Stories. The whole system functionality is intended to be solve with one or few stories. The users stories span among all the iterations in the project. No sense of achieving any objective at all, but the opposite, things are always late and passed to the next iteration. No prioritized/well thought backlog: On each planning meeting, the team loose a lot of time defining what's next reviewing the whole backlog. This is a big management fault, there should be a responsible to know what's next, and how important it is, and deal with the team in the planning meeting. Implement anything: We need to finish this iteration, the user stories are bad, just finish them, and then "Refactor" later. That's the worst assertion ever!. That reveals to the team that they have no idea where to go, and use the word "Refactor" to really mean, "redo-it" later. Implement logic partially with an end goal in mind, helps the team to make better design decisions while developing. Implement things just to show progress and then throw away is a waste of everybody's time. Create Mocks and validate them quickly, you are trying to help the business, not to just show progress. "Refactor" should be done as soon as possible, you cannot refactor the whole project at the end. Refactoring adds quality to the code, nobody does everything good the first time, and nobody remembers anything at the end of the project. Robot coders instead of developers: A robot coder is the one that just codes what he/she is told to do. You need developers that think what they are doing and develop a solution, and not excuse behind the known: "That was not in the Specs". You are building the specs with the users. Reply to this Reply to original

Re: More Anti Patterns Go to top ] Posted by: Peter Jansen

Posted on: May 03 2008 04:58 EDT

in response to Ramiro Rinaudo I have recently joined a company where developers have been 'trained' for years to be like 'robot coders'. This goes to extremes like: 1. asking permission for every small change (e.g. directory rename). 2. not daring to do any refactoring and working around problems. Yes, even complaining about problems but not fixing them. On top of this, the company is extremely process-oriented and agile was introduced and embraced as the 'new process'. Now all of a sudden agile itself is a formal process, where they are even considering to use finished user stories as the formal description of the system. In addition, we are working with a tight delivery schedule were functionality must be in place at a certain time. In a way, agile is being used as a tool for micromanaging developers where, of course, the robot-mentality of the developers strengthens this approach. This is typically a case where agile was adopted without thought about the consequences and requirements for this. Instead of introducing agile, the first step should have been to use the existing process, then manage people differently to make sure the robot mentality gradually disappears (difficult!), and relentlessly focus on process optimization (by the workforce not by management) following the basic agile principles such as eliminate waste and stop-the-line. Reply to this Reply to original

Where are the "lessons learned"? Go to top ] Posted by: Denis Baranov

Posted on: May 02 2008 18:52 EDT

in response to Priyanshu Goyal I'm surprised by so many folks getting caught up in this latest and greatest without really understanding it's benefits. My problem is this: I see Agile methodology borrowing pieces from XP, from feature-driven development (and possibly others I'm not familiar with). I see some concepts that map very well to older terms but were renamed for some reason. What I don't see is an explanation: if Agile resembles XP so much why pieces A and B were thrown out, if it borrows from feature-driven development, why these and not other pieces were adopted? My conviction is that unless you learned some lessons, you are bound to repeat the mistakes. I think evangelists of this (and any other) new methodology owe an explanation to us all, what is it that they learned before they set to impose their world view upon us. Reply to this Reply to original

Agile is not an all or nothing Go to top ] Posted by: Jeff Anderson

Posted on: May 04 2008 11:05 EDT

in response to Priyanshu Goyal Let us keep the refactoring tasks for later: true, continuous refactoring is a reality, and it's something that's ideal. I still schedule explicit iterations where the team does nothing but refactor, kind of like timeouts for the team to catch up, usually only a weeklong. It's an excellent mechanism and I will always use it on my projects when I can get away with it. We are doing continuous integration so we are already agile true, continuous integration does not make an agile team. But it's an excellent start, especially if you're in an environment that will simply not allow you to do some of the other things. Agile is definitely not a "do/not do", it's a set of best practices that have an exponential effect when used in a complementary fashion. Unit testing the complex pieces is enough again, while I agree with the title of your pattern, simply stating that you have to unit test everything is not feasible. Just as much, or more, care needs to be taken in designing reusable pieces of your unit tests, deciding what your unit testing strategy will be, and how much the test. On extremely large projects, 100% coverage is just not feasible. I would rather have 200% coverage on critical pieces covering multiple scenarios, and on integration points between teams than try to do a blanket coverage of the entire code base. Again, opinions differ, but one isn't more agile than the other. Overall the post has some good stuff in it, but some of the languages to gear towards preaching and prescribing, practices and recommendations always work better. Jeff Anderson You seem to be listing all these patterns in a "you must do it this way or else you are not agile...". This type of approach is what alienates practitioners in the IT community both at the business and senior level. IE: a lot of agile people come across as religious zealots. A lot of these patterns are certainly something I agree with you in principle, but they're not requirements for agility. My feedback on your specific patterns as follows.true, continuous refactoring is a reality, and it's something that's ideal. I still schedule explicit iterations where the team does nothing but refactor, kind of like timeouts for the team to catch up, usually only a weeklong. It's an excellent mechanism and I will always use it on my projects when I can get away with it.true, continuous integration does not make an agile team. But it's an excellent start, especially if you're in an environment that will simply not allow you to do some of the other things. Agile is definitely not a "do/not do", it's a set of best practices that have an exponential effect when used in a complementary fashion.again, while I agree with the title of your pattern, simply stating that you have to unit test everything is not feasible. Just as much, or more, care needs to be taken in designing reusable pieces of your unit tests, deciding what your unit testing strategy will be, and how much the test. On extremely large projects, 100% coverage is just not feasible. I would rather have 200% coverage on critical pieces covering multiple scenarios, and on integration points between teams than try to do a blanket coverage of the entire code base. Again, opinions differ, but one isn't more agile than the other. Overall the post has some good stuff in it, but some of the languages to gear towards preaching and prescribing, practices and recommendations always work better. Jeff Anderson http://agileconsulting.blogspot.com Reply to this Reply to original