Is agile for everyone?

I have often been told that the purpose of a good software process is to ensure quality consistently, independent of the people implementing it. But what I commonly hear from the agile camp is that your success depends on having the right people (as opposed to the right “roles”) on your team. Does that mean that agile isn’t for everyone?

I just read a blog post that repeats this same refrain: process trumps people. But the author asserts that this isn’t the antithesis of agile. In fact, Scrum is a very structured and repeatable process. But is part of the process making sure you have the right people? I don’t remember anything about candidate selection in the Scrum books…

I know, I’m being overly obtuse about this. I’m sure the point is that in order to do agile right, you just need to get your team to all buy in to the same philosophy and practices. But, as I heard Chris Sims say in a workshop on agile processes, “not everyone is a team player”. And… “great programmers with a terrible process will always be more successful than terrible programmers with a great process.” In other words, people trump process.

So, what happens when you get stuck with a team of duds? A common response from agile evangelists about the problem with “problem” people is “why would I even want to work with people like that?” Too true, but there’s a certain snobbishness in such a response that seems to say “I’m too good to be caught working with ‘average’ programmers!” Average… well, by definition, there must be a LOT (about half) of developers out there that are just average, or worse. What happens if agile processes finally take over the world, and the majority of programmers are working in that paradigm? Will it finally collapse under its own weight, because half the team doesn’t have the discipline required?

Let’s turn this thing on its head now.  As the “Herding Cats” post points out, people who are OUTSIDE the process, like managers and those trying to work on a long-term strategy, like to know that everything is under control, and that all risks have been mitigated (via, for example, a controlled, repeatable process). That would presumably include trying to get the best people for your project, but accepting that that’s not always possible. Would you choose agile, if the process requires a certain amount of inspiration and discipline (as opposed to some nice, old-fashioned whip cracking)?

The agile philosophy encompasses a set of practices and disciplines that are meant to bring us all out of the primordial code muck and realize our full potential as alpha-developers. But we all know that not everyone is up to that challenge (or just doesn’t want to play ball). So, is agile for everyone?

Advertisements

10 Responses to Is agile for everyone?

  1. Great post with great insights.

    I do agree that agile is great, it has its niches, but is WAY overrated. It is not the holy grail of software development, and it doesn’t apply in all circumstances.

    I you bring up a great point which is that Agile expects the best of people. I see it as the communism of software development. Great in theory, not so great in practice.

  2. BTW, you beat me by 1 day on this, I have a draft about the same subject 🙂

    I’ll post it anyway, I think our ideas may be complementary

  3. I think I don’t agree with your main argument. Agile is just a way for collaborative development (often software development but can be applied to other fields), there are multiple other ways including more bureaucratic. Agile focuses on real-time, face-to-face communication whilst other methodologies focus on formal specs and documents. Both require team players.

    Managing agile teams for a while now, I’ve seem lonely wolves working on agile projects. Usually they don’t share knowledge, they don’t help improve the process, they don’t act as facilitators but they can still be good workers. if the team/company thinks that it is worth keeping Mr. Wolf around he can work like he wants. If he won’t add value and is not worth he is generally voted off of the island.

    Before working full time in agile teams I’ve managed and worked in more bureaucratic situations. in this case, lonely wolves are still dangerous, maybe more than in an agile environment. In an Agile team often members have similar skillsets, in abureaucratic team Mr. Wolf can be the guy that you need approval from to implement that module or try out that new idea -and he won’t make your life easy. The process may inhibit communication but you still need collaboration.

    So I propose a change in the title of your post, what about: “Is Collaboration for Everyone?”

    cheers

  4. Timothy High says:

    Hey Phillip,
    Good to hear from you!

    I suppose you’re right in saying the focus should be on collaboration, but tell me if I’m off the mark here: without collaboration, there is no agile process. This is in contrast to a more “traditional” process like the RUP, where using a more collaborative approach would be an implementation detail.

    Now, I’m all for working with the cream of the crop. But this aspect of agile feels to me like when I went to work for Sapient Corporation. They were working real hard on creating a company culture that would bring out the best of you. But ONLY if you fit in with that culture. To the rest, it was “so long and thanks for all the fish.” I personally fit in quite well there, and I think I would just fine in the collaborative atmosphere of an agile process. But Sapient wasn’t for everyone…

    Anyway, I’m just looking at this from a strategic management perspective. What if I have a company of 10,000 developers. Should I risk trying to institute agile processes across the board? The odds of me hiring 10,000 team players seems slim… (although I actually think the lone wolves are probably a small minority). Actually, I don’t think that would be the main consideration here. A collaborative environment would be hard to set up universally for many other reasons. So, agile would have to be used on an as-applicable basis. It’s not a silver bullet, which is probably not a shock to anyone.

  5. Several points-

    1- Scrum is a process, Agile is a set of values and principles. Scrum = Agile, but Agile != Scrum. (2nd paragraph response)

    2- People can be categorized based on skill and on personality type separately. You seem to be mixing between these two throughout your post as you discuss good vs. average people. The scale of average and great does not match well with these either of these items since it would be different dependent on what you desire.

    3- There are different cultures. You should hire or build teams based on this. Team sports require team players, individual sports do not. You can’t take a person from a command-and-control environment and expect them to immediately excel in a collaborative environment. Agile environments tend to be a collaborative environment.

    4- Rather than implying that agile is weak because it suggests certain conditions necessary for success, I appreciate agile for its honesty in sharing where it is appropriate and where it isn’t. I see this as a strength.

    Is Agile an elitist software process that can only succeed with the brightest and best? No! (But people have applied XP in competitive or control type of environments with success by carrying this approach.) Agile has a higher chance of success in a collaborative environment.

    On one hand, I think this is a great post due to the discussion it inspires. On the other hand, it worries me that this is a topic/issue to be discussed in the agile camp since it borders on the elitism category. Part of me feels as though the core ideas of agile have been lost if this is where the conversation is wandering. Somehow this feels like a distraction from where the agile conversations are supposed to be heading.

  6. Timothy High says:

    Hi Kevin,
    You make a lot of great points here! First, let me start by assuring you that this isn’t the way the agile discussion is going. I’m not “in the agile camp”, but instead someone who’s never worked in an agile environment. So consider this post more like “the kind of things you have to deal with when trying to explain agile to others”. It’s more like target practice for those in the agile camp 😉

    You’re also right that I mix concepts throughout this post. I would say that’s more due to the laziness of a blog discussion than any sense of REAL confusion. Sorry about that – I’ll try to be less muddled in the future.

    So, that leaves us with the two potential issues with developers: good or bad? Team players or lone wolves?

    Well, if they’re bad programmers, I don’t want them on my team. But my question to those who have worked with agile processes is the following: it is my understanding that they require a certain number of disciplines that other processes don’t (e.g. TDD, openness, courage to refactor and so on). Are bad developers (that don’t have this kind of discipline) more dangerous in an agile process, or in a traditional one? Perhaps they’re just dangerous in different ways: they always get in the way of their pair programmer, or leave cleanup work for everyone else in agile, whereas in a traditional environment, they add to bugs and the technical debt that no one will bother fixing.

    I think Phillip has already answered the question for the lone wolf case. In my experience, I have seen that lone wolves can actually flourish in a setting that lets them do their own thing. It’s a headache for their managers (and architects), but if they’re good, they still add a lot of value. I think in a collaborative setting, they’d be hampered and eventually ejected due to the cultural mismatch.

    The other point I bring up is how managers might see agile. What if you can’t hire? What if you have a very experienced team that has worked together (in the non-collaborative sense) for a long time, and you are thinking about introducing an agile process? One of the questions you’ll have to deal with is: how will this change affect my team? Will they all fit in? Or will I end up losing one of my hotshot coders because he/she hates “being babysat” or having to do the babysitting? In other words, will my team FIT IN? Now, you shouldn’t make a decision based entirely on a FUD like this. If there are clear reasons for wanting to introduce agile, then it’s worth giving it a shot. You can always go back if it doesn’t work out.

    I don’t think I’m implying that agile is weak. Just because something can’t be universal doesn’t make it bad. Sapient adopted a strong culture based on recommendations from the book “Built to Last” that showed in studies that the top companies in the world all have a strong culture. One consequence of a strong culture is that not everyone fits in. I understand that in no way, shape or form is that the intention of agile. But perhaps it’s a side effect.

  7. Hi Tim,

    his is in contrast to a more “traditional” process like the RUP, where using a more collaborative approach would be an implementation detail.

    My point is that software development -regardless of the adopted methodology- is a collaborative activity. Weak team players will cause problems in any development process I know, including heavy bureaucratic, document-based ones (they can always hold a document forever in the worfklow or something).

    Anyway, I’m just looking at this from a strategic management perspective. What if I have a company of 10,000 developers. Should I risk trying to institute agile processes across the board? The odds of me hiring 10,000 team players seems slim…

    As I said before, I don’t think you have any other option. Using agile or not you need team players and this is true for software development just as for any creativity-related activity I’m aware of.

    Of course that a 10K people comanpy has a lot of problems but there are dozens of ways to deal with this situation. I’ve been in such projects before and my advice would be: it’s not because you have 10K people that they should work together in the same thing at the same time. Create small, self-managed teams.

  8. Timothy High says:

    My point is that software development -regardless of the adopted methodology- is a collaborative activity. Weak team players will cause problems in any development process I know, including heavy bureaucratic, document-based ones (they can always hold a document forever in the worfklow or something).

    Well, now, there I would disagree with you somewhat. I guess it depends on your definition of “collaborative”. In the general sense of “working together”, yes, everyone needs to work towards the common goal in some way. But that way does not by any means have to be according to the types of collaboration used in agile processes. Agile processes take an “upfront and personal” approach, preferring face-to-face communication over other types of communication because it is more effective and efficient.

    I would argue that other models, such a fully distributed and anonymous open source project, can achieve the goal of developing quality software using a much different approach to collaboration. And that different approach is exactly the type of environment in which “lone wolves” can really thrive and make astounding contributions. This is because they can be highly talented and totally self-driven, but work towards a common goal. And can be given more or less free reign in terms of their creativity. The worst that can happen is that their code is rejected and never merged. This model works for lone wolves because efficiency of communication and effort are not held at a premium (no one’s paying them by the hour in most cases),

    There’s another model out there (that I intend to speak about in more detail soon) related to this: Top Coder (http://www.topcoder.com/). They develop code through COMPETITION. Anyone can write a component for them, but only the best gets their code accepted, and gets paid. This to some degree is the antithesis of agile-style collaboration. It’s collaboration via competition, and is where lone wolves can thrive over team players.

    But what about traditional processes? I can see (and have seen) lone wolves work perfectly well in such an environment. Just because they want to work alone doesn’t mean they don’t want to work for the team. They just don’t want someone looking over their shoulders all the time, don’t want to have to work the same hours as everyone else, and don’t want to deal with the whiny customer every two weeks – they just want to write code. A more traditional process may be inefficient, but it might also give them the space they need to do just that.

  9. I think you may be using “collaboration” when you mean “communication”.

    Agile requires a different communication but Agile or not you still need collaboration.That’s exactly what I said in my first comment:

    Agile focuses on real-time, face-to-face communication whilst other methodologies focus on formal specs and documents. Both require team players.

    It is very unlikely that any software will be defined, developed and tested by the same person so we will have collaboration. The communication between collaborators is something that varies with methodologies.

    Anyway, the fact that you prefer face-to-face communication doesn’t mean that’s the only way to do it. Most Open-Source software projects I’m aware of are very agile, in those scenarios agile practices (TDD, small iterations, etc.) are used and communication generally is strong among team members using IRC, mailing lists and the like.

    Some projects, like Eclipse, have even created their own published agile software model -Eclipse Software Development Process is so strong and Agile that was used by IBM as the base for its RUP-can-be-lightweight-and-agile processes.

    I don’t consider Top Coder a realistic approach for software development. It is very interesting for research and maybe to outsource spike solutions but base your development project in such model is extremely problematic.

    As I said before:

    if the team/company thinks that it is worth keeping Mr. Wolf around he can work like he wants. If he won’t add value and is not worth he is generally voted off of the island.

    It’s not because you’ve adopted agile that you will fire everyone that doesn’t say ‘Good morning, team!’ aloud every day. If the team see value on Mr. Wolf there’s no problem with it.

    In summary: there’s no problem having someone that can’t collaborate effectively in a team if this person provides value.

    BTW: I’m not receiving notifications about new comments. Is this normal?

  10. Timothy High says:

    Normal? I hope not! But I’m new to WordPress and blogging in general… also, for some reason, it didn’t bother me asking to approve your post this time -now’s your chance to get away with murder 😛

    So, yeah, I think we’ve pretty much explored this subject as far as it can go. The people who REALLY wouldn’t fit in to an agile environment are people who are going to be a headache to their managers no matter what. As you pointed out, the conditions that they might bristle at are actually somewhat orthogonal to process per se, having more to do with the particular work environment (do they have to be on time? can they make their own hours? do they have to work with someone sitting next to them all the time? Can they be “creative” with their code (even to the extent of making up new features as they go)? etc.). Agile processes do have a reputation of favoring the type of environment mavericks might hate, but that’s more about values and practices than about the process itself.

    I do find the Top Coder example intriguing (albeit extreme and unrelated to this discussion). I wouldn’t dismiss that model outright. There’s something strangely fascinating about it. I think the chord it strikes has something to do with “development in the cloud” to coin a term… I’ll be exploring this issue more at some point in the future, I’m sure.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: