Three things I don’t like in the agile community

http://www.andybrandt.net/669/three-things-i-dont-like-in-the-agile-community

by adambyrtek • 16 years ago

16 20 16 years ago

stevenp• 16 years ago

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.

benbjohnson• 16 years ago

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.

TamDenholm• 16 years ago

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.

100k2• 16 years ago

I killed the morning standup meetings at a former company after I pointed out that we were all on separate projects and so were wasting 3 person hours a day communicating updates that were irrelevant to others.

wccrawford• 16 years ago

We just moved to agile at my company, and it was rough at first, but I think things are much smoother now. Our standup meetings are for the teams, not the entire company, so they are short and sweet. Everyone on the team knows what's going on, and that's it.

We also have an assigned standup time, but it's after the latest developer gets there. We have set hours we have to be there, but we got to pick those hours individually. We just have to stick to them. That's good for both management and your team members.

It sounds to me that the problem isn't agile, but how the company is applying it. If you use a hammer like a screwdriver, you're going to be disappointed.

mattmcknight2• 16 years ago

Two hour weekly team meetings aren't part of any agile method that I am aware of. Scrum standups are supposed to be for people working together. Those aren't agile principles.

adambyrtek2• 16 years ago

I claim that the daily stand-up is the single most beneficial agile practice, and also the simplest one to implement on any project. It's absolutely worth to spend 15 minutes each day to learn what others are working on, what problems did they encounter, how does it overlap with your tasks and what is the overall progress. Noticing only the perceived time expense without taking into account the big picture is very short-sighted.

Of course all of this makes sense only when you work as a team, not on your own (although the iterative approach is desired even in such case).

100k2• 16 years ago

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.

duncanj• 16 years ago

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.

mattmcknight2• 16 years ago

Another aspect of XP is that pair programming is a replacement for code review. If you drop pair programming, you should consider a compensating practice.

yannickt• 16 years ago

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.

raganwald3• 16 years ago

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

jdp23• 16 years ago

my experiences match yours: I've worked with a lot of agile practitioners and most of them are very respectful of different agile practices regardless or their preferences.

westajay• 16 years ago

My town had a lot of early agile projects in the first part of the decade. The consultants only talked about the successes and not the many failures at conferences. Specifically WRT scrum and XP. I can tell you about a scrum failure that was in the 10's of millions of dollars.

I've had many negative experiences with less effective consultants using agile as a way to convince the client that they are all wrong and the only way out is more consulting guidance. In fact, I worked for some time at a consultancy where I am sure this was their business model.

There's more than one path to the finish, and "agile" sold itself out as a vapid marketing term years ago.

Ramone2• 16 years ago

I'd be interested to hear about (1) that scrum failure in the 10's of millions of dollars, and (2) what you prefer instead of Agile.

(I'm a developer on a scrum team and really think it helps us, but I'm not dogmatic about it or anything... I'd like to hear about the other side. I'm surprised that a huge scrum failure is possible because the customer is generally shown everything at regular small intervals, so it's hard to imagine how a project could get so far off course.)

edit: grammar

raganwald3• 16 years ago

Question: If you take your own comment and replace the word "Agile" with "BDUF," does it still ring true? Why? Why not??

p.s. To be clear, I know many ineffective consultants who sell a variety of snake oils, both Agile and BDUF. I'm wary of falling into the "No True Scotsman" fallacy of claiming that what they sell isn't Agile or isn't BDUF. Really, I have no evidence that there is any methodology that turns a bad consultant into a genius, or allows a great consultant to turn a bad development team into software shipping superstars. I don't claim that anything works. But then again, I don't claim that anything "doesn't work," either.

Vic-nyc• 16 years ago

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.

adambyrtek2• 16 years ago

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

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

Three things I don’t like in the agile community

Related Stories