Some practices which harm the way we adapt to agile way of working or in a way sort of bad practices which are counter productive. They may very well push back the organizations which are still testing the waters of going agile. End of the day integration: Doing it one time a day is not continuous enough. Many a times the counter argument is that the build time is so much that it makes sense to do it only once but that defeats the whole purpose of CI which aims to provide a quick feedback on the status of code under development. With frequent check-ins, there will be frequent integration, frequent feedback and very less merge conflicts. The more the code lies on the developer’s box, the more adverse effect it can have. Here is what Martin Fowler has to say:

Many organizations do regular builds on a timed schedule, such as every night. This is not the same thing as a continuous build and isn't enough for continuous integration. The whole point of continuous integration is to find problems as soon as you can. Nightly builds mean that bugs lie undetected for a whole day before anyone discovers them. Once they are in the system that long, it takes a long time to find and remove them.

Let us keep the refactoring tasks for later: Quality of design and code is as important (if not more) as the implementation of the functionality. We all understand that sometime it is difficult to come with a business case for it and may get hard to justify the time and effort involved in the refactoring activity to the customer but it has to be done and sooner the better. More often then not refactoring can be done as part of the development and the effort should be estimated as part of the estimation of implementation of user story until and unless there is big architecture or design change involved (which then is considered as a separate task in itself and should be treated that way). Unit testing the complex pieces is enough: All the code should be unit tested as it is very subjective to decide how much unit testing is enough and which all pieces are too easy not to test. More the unit testing, more are the chances to catch an issue which might have quietly crept in as a side effect of making changes somewhere else or due to refactoring tasks. Move the iteration untill all the user stories are done: All the iterations should be time boxed as sustainable pace and rhythm keeps the team going. Moving over the iteration to complete a user story is bound to break it. It might seems to be ok to take care of an exceptional condition but then the number of exceptional conditions keeps on increasing the rhythm to develop and release breaks. Here is an interesting quote:

The iterations are time-boxed. This means that the length of the iteration does not change from iteration to iteration. And we do not extend any single iteration (or sprint) because "we're not quite done yet".

Let us try to do as much as possible during the iteration: Be pragmatic do what can be done and what provides the maximum customer business value. It is important to have something working at the end of each release, a working code rather then a lot of code which fails to work. Never do overtime as it kills the pace and so the team. Doing more will make the code coverage fall, will serve as an excuse to skip stand-ups and the rest a crappy and fragile code. Comment the test as it is breaking the build and we will come to it later: There is no better time then now to fix the test case. Test cases fail for a reason, identify and fix it rather then deferring it for some other time. Retrospectives are not adding much value, will save time if we skip it: They give us a chance to inspect, learn and adapt. They do not add value as nothing happens after that, nothing happens to the ideas and suggestions which come as a result of it. Allan Kelly reasons:

The most common reason given for not doing a retrospective is lack of time. True, we are all busy people, but if we really value retrospectives the way we say we do, surely can we make time? Finding the time is really a question of prioritization, deciding that the retrospective is more important than other things.

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. Most of the user stories are high priority: Very important to make sure we have the requirements prioritized and what we do as part of iterations are the ones at the top of that list. If we have too many high priority items then different team will go about it in different ways, some will pick the easy ones to demonstrate how high their velocity is and some will pick the tough ones to technically feel great about themselves.

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.

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.

Anyone that advocates being/using "Agile" always seem so "rigid" in their definition. Well, being rigid when promoting an agile process seems to be speaking in oxymoron's to me, don't you think?

Here is what Martin Fowler has to say:

Many organizations do regular builds on a timed schedule, such as every night. This is not the same thing as a continuous build and isn't enough for continuous integration. The whole point of continuous integration is to find problems as soon as you can. Nightly builds mean that bugs lie undetected for a whole day before anyone discovers them. Once they are in the system that long, it takes a long time to find and remove them.

http://notdennisbyrne.blogspot.com/2007/09/top-5-signs-of-discontinuous.html

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.

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.

"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.

"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.

Its not just the maintenance where the quality of code has an impact. Its also durign development (how quickly can you build feature 2 once feature 1 is done) and the liklihood of accidental bugs in that finished product. I've seen poor code quality affect projects during their initial development and first release.

But what if there never is a maintenance cycle? This is always an interesting discussion but I wonder what the result would be if the developer had to pay the cost of the extra work involved in things like refactoring. It's always easier to say what's important when you aren't paying for it.

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.

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 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.

"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.

"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)

"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.

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?

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.

To me, Agile is not a tool: it's a toolbox. 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

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.

This was the central XP idea. Agile changed proposals and recommendations to commandments.

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. Architect's Toughts

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.

How much code base we are talking about? How are the modules coupled to each other? Agile methodologies with a old style design - Will have problem. Agile methodology need an agile architecture. I handle this particulat piece of problem from the design perspective. In a Plug-in architecture like eclipse, nutch indivisual teams just work on their small project of building a plug-in. I am sure, the build process will be with in a minute as well as testing the plug-in. Software Architecture for India http://sunilabinash.vox.com/

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.

I have seen cases where refactoring is used as an excuse to write bad code at the start. Basically, few developers tend to meet the timelines and complete the functionality by writing kludge code at the start. They tend to say the code can be 'Refactored'(the nice term for the bad job) to make it better. This adds to the refactoring effort that was not necessary at all.

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.

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.

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.

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.

This strikes me as a remarkably non-agile mindset, and it is the exact reason why Agile has failed to gain any momentum in the mainstream. -- Cedric http://testng.org

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. 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 http://agileconsulting.blogspot.com

This post is in no way trying to help measure the agility of any team or defining any sort of requirements for agility. It is more about the bad practices in my view which I recommend anyone thinking of going agile should keep an eye on. I totally agree agile is definitely not a "do/not do" thing and if anyone thinks that way it is for sure not agile.

On extremely large projects, 100% coverage is just not feasible. I would rather have 200% coverage on critical pieces covering multiple scenarios...

i'm pedantically confused: i thought the definition of 100% coverage of something was that all code paths are tested? so i don't understand what 200% would be? that sounds like 100% is really 50%. curious.

Google has made online documents, spreadsheets to facilitate collaboration. Every minutes the live editting syncs up with with the server. If I apply that to the version control tools, why don't they push the fresh sources automatically to all the clients. Let others code break. Anyway it is bound to break now or later. If too much has broken, that means modules are tightly integrated and there is something wrong in the design. Interfaces don't change frequently. We need a new age tool. CVS, SVN are not just good enough. The code need to be in a centralized place and the fresh copies need to be pushed. Not pulled by the developers. I am just passing the responsibility of continuous integration to the tool. No micromanagement, no day end nothing... The machine just does it. Read more our architectural view points at Sunil & Abinash http://sunilabinash.vox.com/

Agile Anti-Patterns doesn't necessarily mean that Agile is Anti Pattern. It has benefits, but not always fits everything in every conditions.