Three things I don’t like in the agile community

I am a developer, and in the past I used to be a proponent of "agility". These days if I am interviewing for a job and I hear that the company is using "Agile practices", I generally try to avoid it like the plague.

I believe there are 3 main factors for software projects to succeed: one is the technology and the skill level of the tech team; the second, very important, are the business requirements (are we building the right thing, and with the right priorities?); the third is the level of communication between team members. Now "Agility" (Scrum/etc) really addresses only the 3rd point.

And herein lies the dogmatism that others have mentioned -- a lot of these companies who do "Agile" usually do so because they have serious problems, and they think "Agile" is a magic bullet that will solve them. This is extremely wrong and dangerous - if your problems are caused by crappy technology or (very often) by the fact that you don't understand what you're trying to build, then throwing scrum meetings at developers will alienate them even further.

What I also see in these companies that are so adamant about Scrum/etc, is management who doesn't understand technology. Therefore they use the "Agile" weapon as one of their only ways to give them a sense that they are in "control" of the situation. They neglect the other parts because they don't understand them.

Odd, I haven't met any. I'll repeat that, ANY agile practitioners who suggest that other agile practices are doing it wrong. And unless I misunderstand the original Agile Manifesto, it's all about valuing certain things over other things, not about saying the other things are wrong, and certainly not really about specific practices.

The analogy I would draw is to the relationship between ideals of code beauty and design patterns. Design patterns aren't the goal, they're particular ways of achieving an ideal that people have discovered work well under certain circumstances.

Likewise, the practices aren't the goal, they're implementation details. I can't even understand how to say a practice is wrong, the things I judge are the degree of communication, the amount of discovery, the flexibility to pivot, and so on. Practices are how but not what.

p.s Get off my lawn!

http://weblog.raganwald.com/2007/10/three-blog-posts-id-love...

I think dogmatism is the worst of the three problems. So many teams seem to be looking for a catch-all solution for running a productive team. What I've found is that each team I work on does much better if we're open to experimenting with different processes in order to find what works best for our team.

The company I'm at now has more than 6 teams, many of which work in different ways.

Some use online scrum boards, some use physical ones. Some track projects only with story points, some use actual hours or days.

The point of agile (at least as I understand it) is to get your team in flow so they can ship value to customers. Being too religious about process seems to be a recipe for frustration.

I worked a 2 month contract at a company that employed agile techniques and i found them to be nothing but superfluous minutia. Thats not to say they dont work for the company as a whole, but i was 1 guy working on 1 project by myself.

I was brought in to tackle a specific problem and sort it out, i was just given what i needed and i got on with it, but was forced to partake in the daily stand up meetings and weekly team meetings, which for me specifically were just a waste of time.

The stand ups were at 10am which meant that even though the company had flexible hours (awesome) i had to be in at at least 10am, whereas i'd prefer to walk in around 11am-noon and stay late. Also, my part of the weekly 2 hour team meeting was 5 minutes long and nothing else was relevant.

My point here is that i'd like people not to try to force principals to fit into every situation, cuz they wont, it'll work for some things but not others, just keep that in mind.

PS: Atlassian sounds like an awesome company but JIRA sucks.

I think I can explain some of the dogmatism seen with XP practitioners. XP is a set of practices for customers, developers, and communication. XP consultants think that teams should try all the practices. Most XP people don't oppose removing or modifying a practice, but they don't see why you should remove it before you've tried it, especially when the reason is something like, "Pair programming will never work here." Try it for real, then make it your own.

In discussions between agile groups, XP people are often confused by, say, Scrum, because the Scrum consultants teach fewer practices and use funny vocabulary. But I'd say that most XP people would prefer to work in a Scrum environment than in many more traditional environments, and they would say so if you asked them.

If I'm reading him right, he doesn't like that Agile is dominated by consultants, meaning people who teach other people how to be agile.

I agree with that, but I think there's a further problem: a lot of the people practicing agile are consultant developers. They take on a project, apply their "agile methodology", and build some software. As the project goes on and begins losing its luster, the contract ends, and the consultants are on to the next Shiny Thing.

With this kind of environment, people don't have to face the long term consequences of their technical decisions.

(I think this is also why there is so much "what's cool this week" churn in the Rails world.)

I would like to see an agile methodology come out of a successful product team, that applies it for years.

One thing I would add to the list is: relative lack of evidence. Now don't get me wrong, unit testing, continuous refactoring and pair programming are very helpful when applied in the right context. But there is a lot of code out there that was written with no overt agile enthusiasm, and this code is working just fine. I always roll my eyes when I hear or read things like: "if you don't write your tests first you're doing it wrong". I'm very happy that TDD and daily scrums work for you, but I won't convert to your religion unless you show me a search engine or a web browser written with agile consultants on site.

Ward Cunningham: 'The word "Agile" has worked hard for ten years. I forgive it for being tired.'

http://twitter.com/#!/WardCunningham/status/27668990943

I'd like to add something to your list: Adding an entirely new vocabulary to learn. Velocity, story points, etc. I don't mind learning new things but most of these terms are just the repackaging of existing ideas.