Are Agile development practices the Kryptonite of poor developers ?

One of the key factors in all of the Agile development practices is constant monitoring of the situation via feedback on the status of the project. This is highlighted by small units of work that are completed or not so it’s very difficult to be in the “almost finished” state. Coupled with this are practices that look at the overall progress of the project, such as looking at units of work remaining, and the current “velocity” or rate of completion of tasks.
All of this is designed to be done in a non-confrontational manner, with an aura of openness and honesty prevailing, with everybody working to the best outcomes of the project.
However, this might be the case in the “fairies at the bottom of the garden” development land, but it’s nowhere I’ve ever worked. What’s more likely is that there are entrenched developers who have been working for years without responsibility or accountability, always capable of blaming somebody else, while giving wildly padded estimates and seemingly continuously at “80%” complete.
Introducing an Agile process (or in fact any process that highlights accountability) immediately highlights the incompetence, inability or downright unhelpful members within a project team. Given the rate of project failure (some say 70%) there must be a lot of rubbish developers about the place. With that much around, it’s no wonder there is significant resistance to Agile processes.
Imagine if I walked onto a project, telling everybody how the processes will highlight your deficiencies, make it obvious your lack of teamwork and slackness from the past. What sort of reaction is that likely to get ? I’m guessing that it’s not going to be good. However, that’s what the reaction of a certain section of the development community is leading me to believe they are hearing.
So, project managers, team leaders and more importantly customers, if your project team is resisting processes that highlight accountability and visibility, then start asking questions about whether they should be working on your project or in your company, at all.
Who knows, with enough introduction of these sorts of processes, it might even force a few of the pretenders to resign. Now, that would be a great achievement.

Advertisements

15 thoughts on “Are Agile development practices the Kryptonite of poor developers ?

  1. Jon, dude, are you trying to out-Hani Hani?
    Seriously, saying that anyone that doesn’t like Agile process is a pretender… nice.
    Anyway, I like your statistic of 70% project failure, because approx 5 years ago the figure bandied around was 50%.
    So I’ll see you one flamebait, and raise you one spurious use of statistics:
    Given those figures the obvious conclusion is: “since XP and Agile became popular, 40% more projects are failing”.

  2. Without wishing to sound too rude, but did you actually read my blog entry ?
    I read your previous response and I understand that you don’t like Agile/XP practices.
    That’s fine, then this is probably not a blog you want to read.
    I’m going to push them, not because I’m some mindless zealot, but because in my experience the philosophy that Agile processes espouse, and the practises that XP entails support good quality software development.
    I was posing a question about how Agile processes increase visibility into projects, and how that can be a very difficult situation for developers who have made their niche in life by not delivering.
    I was posing that this exposure would be very threatening to them.
    I was not, and I’ve made this quite clear in my response to your other comment, saying that Agile and TDD are “the only way”. Nor that Agile and TDD practices are require to develop “good” software, nor that people who don’t use these practices are not good developers. I really hope that’s perfectly clear.
    I would suggest that you don’t bother reading my blog, as you’re unlikely to gain any insights into development as you would like to do it.
    If you’ve come looking for zealotry, then I’d suggest looking elsewhere, I simply just don’t care how _you_ develop software.
    And I’m old enough and grumpy enough to know that anything I say or do is likely to reinforce your opinion of me, Agile people, XP people, ThoughtWorkers, Tasmanians and people with names that start with ‘J’, so this will be my final response to you on this or any topic.

  3. That’s interesting, thanks Jase. The way that I read what he has to say, reinforces what I was thinking, even though I might not have expressed it that way.
    I wasn’t saying that we should belittle people and berate them, but that I can see why there is such strong resistance to many of these practices particularly because it raises the visibility.
    I can see why people get upset and feel threatened.
    Some people I’d be happy to lose, but there are many that I’d like to be able to educate and show why this visibility is a good thing for everybody in the long run.
    How to achieve this, well I don’t know.

  4. @B.K. Oxley
    Why on earth would you want to do this?
    Oh sure, it might get a few laughs from ‘your side’, but my point is that this is surely no way to ‘win friends and influence people’.
    No, you might never win over the really anti-agile camp, but by polarising the issue into ‘them’ and ‘us’ what happens to all the people who hadn’t really made up their mind yet? Won’t they get pushed away by these kind of tactics, into the open arms of anti camp?
    @Jon
    Don’t be like that. Don’t be afraid of open dialogue. Don’t be afraid of change. Unless Agile is in its ultimate pinacle state of perfection already, how will it improve if noone is allowed to ask questions?
    My point is that by making these kinds of sweeping generalizations it is very polarising. Yes, there are ‘pretenders’, yes we’d all be better off without them. Maybe systems with higher levels of accountability will help flush some of them out (though there is the political/people skills angle).
    But by presenting it like this, by tieing the two statements together, it really really does come across as though you are saying that everyone who isn’t into agile is a pretender and/or incompetent.
    Which I think hurts your chances of getting your message across to a wider audience.

  5. Hi Jon,
    interesting idea, but personally I think the weakest precondition of your argument is that these people are actually aware that they weak development skills, evade responsibility etc. etc. While certainly it may look to you like some people must feel like that, the truth is that most people (especially the ones that are on the “bottom of the scale”) are not even the least bit aware of it. It’s like that joke I heard yesterday: “Actually he was not a friend, I just happened to sit next to him on the first day of school, and than he was hanging on for the next fifteen years. He was a real hang-on. Everybody knows someone like that. You don’t? Well, then that’s because you’re one of them Hang-ons.”
    I’d advise you to read this timeless article:
    http://www.phule.net/mirrors/unskilled-and-unaware.html
    “Unskilled and Unaware of It: How Difficulties in Recognizing One’s Own Incompetence Lead to Inflated Self-Assessments”
    The good news is: it is not necessarily a permanent condition. 😉
    Regards

  6. While you are correct that the pre-condition is the weakest part. To me, it’s the important bit.
    I don’t mind if people are inexperienced but are willing to learn.
    You don’t normally see them trying to evade responsibility, or not being a team player. That only occurs when you are a “poor” developer. Inexperienced developers, or developers with under-utilized or under-developed coding abilities can be assisted if they want to.
    Attitude is the key in my comparison here.

  7. This is a pretty bad comment. How about let’s take your example which is HUGELY LEADING about why people don’t like Agile and restate it into an equally absurd reverse fashion:
    “Imagine if I walked onto a project telling everybody how there’s no more processes at all – and your users who are wily snakes and avoid giving you any actual useful information so later they can pretend they knew all along and you somehow are an idiot so let’s then blame developers…PLUS I’ll take away the ability to concentrate and I’ll STOP measuring by results – as in WORKING CODE – instead I’ll measure you by ADHERENCE TO A PLAN I MADE YOU RUSH INTO”
    Uh, yeah I think most developers don’t like that idea.
    Agile has some good points – TDD is brilliant. Going to short meetings is great. Collocation is absolutely STUPID. Send people home and ELIMINATE the need for discussion. Let them write really solid code – and hire only the best.

  8. Erm anon. You’re an idiot. But thanks for stopping by and sharing that with us.
    Co-location is the single greatest success factor for any project, agile or otherwise.
    Isolation and lack of communication is one of the prime causes for project failure.

  9. “Agile” is a fad. The word is tossed around as though it’s a magic wand that will turn poor development methodologies into good ones by getting rid of proper project management and replacing it with silly “feel good” exercises. I am dealing with this froo-froo nonsense right now at a major credit card company located in Richmond, VA. It’s astonishing how gullible people are.
    “Agile” is no substitute for proper planning, iterative development, and meeting one’s deliverables by writing code to satisfy the requirements. Eliminating proper planning and eschewing the gathering of requirements (which are two of the cornerstones of the “agile” environment being pushed down from above at this company) is a recipe for disaster in any significant development project.

  10. Agile is no more a fad than “waterfall”, “RUP” or “Spiral”.
    It’s a collection of development practices that place a higher value on certain parts of the process and artifacts than other processes.
    It sounds to me like the team is doing a shit job of developing software, and no process is going to help them at all.
    I work for a major Australian bank, and we’re adopting the cornerstones of the agile development practices, and we still have good project planning, have a great project manager and are doing all the things you mention in the good part.
    Sounds to me like you’re just doing a shit job. I’d advise that you stop it and do a good job. That doesn’t matter what the methodology is. Or are you too scared to stand up and say “we’re doing it the wrong way?”
    If so, then the problem isn’t with agile, it’s with your ticker.

  11. Hi there Jon
    I came across this when I listened to a speech about agile development and co-location for the first time in my 33 years of life earlier today. I have for some time been advocating remote work for myself as a developer as I have the type of job which I always believed would suit remote work. I took up programming when I was quite young because it promissed to be an absorbing way to avoid highly social situations.
    No doubt, I’m quite astonished to learn the idea that individuals involved in development work might do it better when physically co-located. What specifically is it about co-location that you believe really makes it “… the single greatest success factor for any project, agile or otherwise”? Do you think someone like me has a future in software development?
    Owen.

Comments are closed.