Collaboration Noise
First of all, I’m not saying collaboration is a bad thing. For me, it has been key in the success I’ve had in software development. However, I’ve always had a problem with the XP bullpen style of developer space organization which apparently is supposed to ‘facilitate communications’. Nguyen is really getting frustrated with the noise that this type of workspace produces and I couldn’t agree more. Even in a cube farm, the noise can be enough to drive you crazy. No barriers at all must be a nightmare when developer arguments get going, when business analysts start spewing their knowledge or when testers cheer with glee as they find another bug.
I can’t speak for the other roles on the team, but developers definately need some quiet to think. I’m not advocating 24/7 radio silence, but an opportunity to have a quiet time in front of your computer so that your mind can focus on the problem at hand is key to solving any problem.
Just like most everything else we talk about here at pliantalliance.org, it comes down to a balance. Yes, there needs to be an environment that is open enough (both physically and socially) for good collaboration to occur, but there also needs to be a way that developers can get some peace and quiet.
on September 1st, 2006 at 8:51 am
From an anonymous commenter who finds himself in a similar situation…
My condolences to you, sir…
on September 26th, 2006 at 7:56 pm
When I first read about XP I thought “hey, that’s how Brad and I work” and then I read some more and realized that “no, we do that only when necessary”. Collaboration is a tool just like everything else. It can’t solve all problems, and sometimes it just creates problems.
As for the noise problem… its an unfortunate reality. I have found that I want to work in a space where if I want to passively listen to whatever else is going on around me, I can do that while I work. If things around me are getting to be too loud, or I am uninterested, or need some time to focus, I have to isolate myself from it. How do you do that? My workspace is not moving (and I don’t advocate the mobile workspace), so I have to adapt. I got myself a pair of noise isolator earphones. They were pricey, but as my co-workers can attest, I can’t hear anything with them in; even without music playing. Thank you Etymotic!
on September 27th, 2006 at 11:25 am
I’m guessing putting on headphones in an XP bullpen is a federal offence and will likely trigger a visit to your home by KB’s cronies for some ‘re-education’ :)
Other than that, you are completely right.
on October 23rd, 2006 at 1:14 pm
[This was moved from another topic. Comments used to be closed on this, but are now reopened]
Sorry to veer off topic, but I wanted to comment on “Collaboration Noise”, and comments are closed on that post.
I was reminded of a little amateur research I did some time ago. After several XP projects at my previous employer, I had noticed that certain types of people seemed to be attracted to the agile style of work while others were put off. I read up on the old Myers-Briggs personality types and noted the ones that sounded as if they would be predisposed to enjoy that working style. Then I looked up the statistics on the relative proportions of society comprising the various types, and added up the numbers.
Based on this little exercise, it looks as if about 14% of people would naturally take to agile work (as defined by pedal-to-the-metal XP). Others, as indicated by comments in many places (notably Cedric Beust’s blog) would simply find it all rather stressful. Words people have used to describe their experiences on XP teams include frustrating, confusing, noisy, erratic, chaotic, directionless, unmanaged, and so on. I wonder if one of the reasons people have such very different responses to XP has to do with basic personality types.
Personally, I find XP to be energizing, stimulating, empowering, and far more productive than other working styles. I know others who feel the same way. When I read comments like those in your post about collaboration noise, I don’t relate to it. Quite the contrary, the typical cube farm feels like a graveyard to me.
Do you think personality type plays into it at all, or am I off in the weeds somewhere?
If I’m right, then it’s good news for everyone. Most IT projects are undertaken for the purpose of reducing operating costs. These tend to be less amenable to agile methods. A minority of IT projects are undertaken to support a business process that generates revenue for the enterprise (justified on the basis of projected ROI). These tend to be highly amenable to agile methods. If the minority of IT projects lend themselves to agile methods, and the minority of people are naturally predisposed to enjoy the agile workstyle…sounds like a win-win, doesn’t it?
on October 23rd, 2006 at 2:08 pm
I think personality has tons to do with it. I think pretty much everything comes down to the people on your team, and that includes both their skills/experience and their personalities/demeanors/moods.
If you are right about the IT project proportions, then yes we should be able to create a win-win. Those _minority_ of people who take to agile methods should be assigned to the _minority_ of projects that lend themselves to agile methods and I would think the projects would tend to be successful. Then the rest of us (the majority, if my math is correct) can be left alone to develop software in whatever way fits our teams’ skill, experience and personality.
I do somewhat disagree with your sentiment about revenue generating projects. I’ve been involved in plenty of successful revenue generating projects and a very low percentage used pure agile methodology. Maybe they lend themselves to agile methods better than other project types, but they don’t require agile methods to be successful. On the other hand, one of the few operating cost reduction projects I was involved in used Scrum and was fairly horrible, so (based on my one experience :) ) you may have a point about those types of projects not being as appropriate for agile methodologies.
Finally, if it is the _minority_ of projects that agile can be successfully applied to then why is it so highly touted (by some) as the only way to develop software in the 21st century? Someone take away their megaphone and let us all get back to work.
on October 23rd, 2006 at 3:34 pm
tbeck,
I agree it makes sense to match people’s personalities with the project processes that line up with the realities of specific projects. I’ve observed many cases when a person who is very effective on an agile team had been seen as a mis-fit on traditional teams, always questioning things, etc. Conversely, I’ve seen people try working on agile teams only to become frustrated and stressed-out by the style of work. They preferred a more predictable work day, and a manager who assigned them tasks to work on. Both types of people bring more value to their companies when they’re assigned to projects that suit their personalities.
I have no “sentiment” about revenue generating projects. I have experience and numbers. I’m too skeptical to be convinced by anything less. And I only said those projects lend themselves to agile methods, not that the majority of past projects were actually carried out that way.
Scrum is a management process wrapper based on empirical process control. It isn’t limited to agile projects. It isn’t limited to software development projects. It predates the agile software movement by several years. It dictates nothing about development methodology. It’s just a tool, like a hammer. You can build a nice cabinet, or you can smash your thumb. It’s up to you. The hammer gets no credit for the cabinet and no blame for the thumb.
I suspect “Scrum doesn’t work” wouldn’t begin to explain what actually happened on the horrible projects you mentioned. I further suspect that if that’s the extent of your failure analysis, you can expect a repeat of those experiences no matter what methodology you choose.
As for your final question, I think the enthusiasm of some people about agile methods is understandable. I’m enthusiastic myself…when it’s applied to the right sorts of problems and when it’s done properly. It’s not a magic bullet. It’s just a tool, like a hammer…
As for “why” some people come on so strong…probably a variety of reasons. Some may have a narrow perspective on IT, and overlook the many types of IT-related work that aren’t suited to the agile approach. Others may fall victim to the “magic bullet” syndrome. They are, after all, human.
One might turn the question around. Why do you come on so strong against agile methods, when it’s obvious you’ve never really applied them? Do you have equally strong opinions about other things you’ve never done? Consider the possibility that exactly the same psychology is operating on the other side of the agile fence. If so, then perhaps you already know more about how they think than I do.
on October 23rd, 2006 at 6:12 pm
First, let me apology for characterizing your feelings about revenue generating projects. I just didn’t express myself properly. I’m not questioning your numbers, but just wondering if they can be extrapolated. Obviously everyone has different experience and perspective and we just have to go by the numbers we have.
Secondly…
What is the definition of “applied them”? I’ve applied many many techniques that would be characterized as “Agile” or are now encompassed in XP, for example, so I’m not sure what you mean by it is obvious I’ve never applied them. I admit I’ve never been involved in a “fully Agile” project, but then what percentage of people who claim to be “Agile” developers actually have?
Plus, you can’t really turn the question around because the onus is on the pushers to prove that something works. I’ve got counter examples that prove that they don’t _always_ work like people claim and that is why I come on so strong. I have evidence that disproves, they don’t have evidence that proves. Having said that, all my evidence is just as anecdotal as theirs is but disproof by counter-example is valid. Proof by example is not.
I’m also not against the agile techniques themselves, but rather the way in which they are being pushed by some members of the community. Now maybe these people are just the money-grubbing loud minority of the community but to those on the outside, they could be perceived as the community. This is obviously wrong, but perception is reality. I’m trying to change the perception whether it is through coining another phrase or prompting the silent majority in the Agile community to stand up and say no (which they are starting to do).
on October 23rd, 2006 at 6:16 pm
In the end, no one can argue with “Do whatever works for you” which is what pliantalliance.org is all about. Agile happens to come up so often because it is the current process du jour. 20 years ago I probably would have been railing against waterfall.
on October 23rd, 2006 at 6:38 pm
There may be those who insist agile “always works,” but you may be attributing too much to a noisy few. You often contend that agilists “never” talk about the downsides or the practical issues in applying agile methods. The truth is we discuss these questions quite openly and frankly, because we are interested in learning how to refine and enhance these methods. Repeatedly claiming that agilists “never” talk about these matters doesn’t really add anything productive to the dialogue.
To the question, “…what percentage of people who claim to be ‘Agile’ developers actually have [applied agile practices]?” I have no answer. I have met people who call themselves agilists because they are in tune with the general idea of agility, and who have never applied agile practices. I don’t know how many such people there may be.
In my opinion one should not claim to be an agile practitioner unless one has rigorously applied a specific agile methodology, such as XP or Crystal Clear, in a disciplined way on at least one real-world project. Tinkering with various individual agile practices in isolation won’t give you a good feel for the style of work, since the effectiveness of an individual practice is influenced by all the other factors on a project. The specific practices defined by XP, for instance, are designed to complement each other such that the strengths of one practice offset the weaknesses of another. If you pull out one of the XP practices and apply it in the context of a project that has a different style of work, it may or may not add value. But doing it that way doesn’t tell you anything about whether “agile” or “XP” as such work well or not, because you haven’t actually applied “agile” or “XP” as such.
That’s not to say there are no individual practices at all that can’t add value in the context of other approaches to software development. Test-driven development is a good example of that. You can use that technique in the context of any methodology. It will have about the same cost and the same benefit in any case. It “costs” about 25% in terms of development time, and yields benefit by reducing design debt throughout the project so that you don’t end up in a death march. Exactly how TDD accomplishes that is well known. It’s not a question of guesswork. TDD was already known and used before the agile movement started, although it hasn’t been the most widely-used technique for building code.
“Do whatever works for you” is all well and good, but hard to quantify, share, or reproduce. Some of the techniques we associate with the word “agile” are well-proven in practice, and it seems a little silly to continually question their value as if we were living through a kind of Groundhog Day of IT methodologies, where every morning we wake up on Day One all over again, with no memory of what worked or didn’t work yesterday, or why it worked or didn’t work.
When something “works”, there are reasons why it works. I think there’s value in trying understand those reasons so that we can determine other circumstances when the same technique might also “work.” The phrase, “whatever works for you,” doesn’t give us even so much as a starting point to understand what might be worth a try in another organization or on another project. It’s more useful to have a clear definition of some technique, how to do it, under what conditions it delivers value, and how that value is generated. Then other people can consider whether that technique is worth a try on their own projects. That just seems more rational and practical to me.
on October 24th, 2006 at 7:54 am
Two things:
1) Your third paragraph in your last comment confirms exactly what I’m saying about a certain segment of current Agile thought. Namely, that “Agile” is not about being _agile_, but about doing a certain set of techniques. This is fine, except the name is confusing and misleading. We’d be better off calling it Foo. Since “Agile” is about doing a certain set of techniques, I really don’t care about it and am not interested in hearing how great “Agile” is. Everything anyone says in that context is suspect because there is a chance they are trying to sell me books, “Agile” products or consultant services. Now I realize that for some, “Agile” isn’t about dogmatically implementing a set of techniques and I’d love to hear from them and learn what does and doesn’t work, as long as I have some sort of idea of the context in which they develop software, so that I can then make comparisons with my own context and try techniques that make sense.
2) “Do whatever works for you” does not preclude sharing what has worked for you and listening and researching what has worked for others. That is key in figuring out what will work for me. If you tell me what works for you and give me an idea of the situation you found yourself in and what you did to solve your problem or successfully develop software, then I can take what your experience and apply it intelligently to my situation. But I’m not going to just follow blindly down a path that someone claims to have had success in when I don’t really know what issues they were facing, what their definition of success is, what kind of people they had, or what kind of software they were developing. That is what some “Agile” pushers are trying to get people to do and I’m trying to convince their potential victims not to abandon Agile, but to not fall prey to someone who is just trying to make money and will say anything to get them to adopt Agile, whether it suits them or not. pliantalliance.org comes down to “Think. Evaluate. Change” not “Follow, Follow, Follow, Pay, Pay, Pay”.
on October 24th, 2006 at 8:05 am
One more thing:
This is blantantly over generalized and false. Claiming something as ‘well-proven’ is dangerous namely because proof is a very difficult thing to find. Absolute proof is in fact impossible to find in software development, since it is impossible to create reproducible scientific experiments. That aside, if you had said “Some of the techniques associated with the word “agile” have worked out well in my experience and I’m confident in their practice” then I’d be fine with that. The fact is that a large majority of software developers don’t use pure “Agile” so the fact that you’ve got some examples (even hundreds of them) of successful Agile projects means nothing compared to the number of projects being done every day in many different ways. Proof by example is not proof. And I’ve got lots of evidence that a) Agile techniques are not required for successful software development and b) Agile techniques can really get in the way of successful development. I’m sure pretty much every developer you ask will have some sort of ‘proof’ on either side of the debate, so getting out our measuring sticks is really not going to solve anything.
I’m not interested in proving that “Agile” works or doesn’t work. I’m interest in letting people know that it may or may not work for them in their context, with their team, with their project and they should think about all that before drinking the kool-aid. But then that is not as economically valuable as a cure all solution for our software woes.
on October 25th, 2006 at 9:06 am
I agree that “agile” was a poorly-chosen term. They should have made up a “new” word rather than using an established English word that everyone already understands differently. It has led to more confusion than it’s worth. Water over the dam now, I guess…unless you want to coin a new word like Pliant, or something. ;-)
The two things you mention in comment #10 are very interesting. On the one hand you write
“Do whatever works for you” does not preclude sharing what has worked for you and listening and researching what has worked for others.
In order to do this, you’d need some kind of well-defined vocabulary to create a shared frame of reference so that others would understand what you were talking about when you shared what had worked for you. But…
Since “Agile” is about doing a certain set of techniques, I really don’t care about it and am not interested…
…sounds as if you lose interest as soon as someone tries to nail down what “worked for them” in any sort of formal way, so that they might actually have a chance of sharing what they had learned.
Interesting. You are the tree that doesn’t bend, whichever way the wind blows.
You also write:
The fact is that a large majority of software developers don’t use pure “Agile”…
I might add, “and they never will.” What you call “pure Agile” is an ideal to strive for. In real-world situations, it’s rarely possible to get there and it’s often counterproductive to try and force things to go that way. But it does provide a useful target for incremental process improvement.
Agile may be contrary to organizational culture, management practices, or individual preferences of the developers. It may be impractical to obtain the level of direct participation agile requires from customers, causing us to take a step back from the ideal. It may simply be the wrong approach for a particular problem based on the characteristics of the problem itself.
The truth is, agile is about finding the most effective way to deliver value in the context of each particular situation. It’s neither more nor less than the goal you claim to have, yourself. What seems hard for you to accept is the idea that some people may have already discovered techniques that are generally applicable; that they have gone past the YMMV level of understanding. So you build a strawman that you can knock down easily: The “Agile religion.”
You’re right to say that there are countless stories of success and failure in software projects involving every sort of process and methodology we could think of, and then some. All the more reason to try and distill all that experience into some kind of re-usable form.
If you become interested in that, let me know.
on October 25th, 2006 at 9:36 am
What I don’t care about is Agile as a _set_ of techniques. I definately want to hear about the techniques themselves, like when pair programming worked or didn’t work, or when TDD was a benefit or when it became an administrative nightmare. Those are the kinds of thigns I want to hear. I don’t want to hear “This set of techniques has produced 1000% increase in productvity, made us millions and got us lots of girls. Send $59.99 now and you can join in the fun. It will work for you!”
We clearly live in two different worlds with two different truths. If this truly was what Agile was about, then this site would not need to exist and I wouldn’t be getting so much support from people who agree with me. I also wouldn’t be upsetting people so much.
Yup, you are right. I believe that there are no techniques that are generally applicable. There are so many variables and unknowns and differences between projects that we can’t even begin to claim in any sort of scientific way that we’ve found something that is generally applicable. All we can do is share what has worked for us and the environment we were in and hope that people are smart enough to figure out how our experience can be applied to their environment.
on October 25th, 2006 at 10:05 am
“I definately want to hear about the techniques themselves, like when pair programming worked or didn’t work, or when TDD was a benefit or when it became an administrative nightmare.”
Discussions of that kind are common. There are even a few controlled studies available (but not nearly enough). It’s hard to believe you’re genuinely interested in that sort of discussion, and yet haven’t come across any.
It’s hard for me to visualize how TDD in particular could become an administrative nightmare, but I guess you were just trying to give an example and not to get into specifics.
“What I don’t care about is Agile as a _set_ of techniques.”
Individual techniques can be used and may add value. No one will stop you. In some cases, a set of techniques is crafted in a certain way to achieve particular goals. XP is put together the way it is so that the strengths of individual techniques can offset the weaknesses of others. So, as a “set” it can deliver greater value than the individual techniques applied in isolation.
Even if you don’t apply some predefined “set” of practices that has a name, then you can improve results by combining techniques that enhance each other. For example, pair programming doesn’t add much value by itself, but tends to help reinforce best practices on other techniques the team may be using. My point is that sometimes you will overlook something potentially useful if you scrupulously avoid assessing the value of multiple techniques used in conjunction.
Also, the very fact that the people who defined XP as a “set” were aware of weaknesses in individual techniques and took pains to offset those weaknesses contradicts your claim that agilists think it’s a silver bullet.
Where you lose me is in your contention that there’s some sort of crusade going on, where the Knights of Agile want to gallop in and force everyone to do all these things at swordpoint, “just because.” That’s totally contrary to the whole philosophy of the agile movement, and IMO an unproductive way to engage fellow professionals in the search for effective methods.
“All we can do is share what has worked for us and the environment we were in and hope that people are smart enough to figure out how our experience can be applied to their environment.”
We definitely disagree on this point. I think it is very possible to go one better than just “hope.” There are practical ways we can help people figure out how the collective experience of the profession can be applied to their environment. Every organization, every team, every individual doesn’t have to start on Square One.
on October 25th, 2006 at 10:22 am
Two different perspectives … and I’m not alone.
Who said anything about starting from Square One? That would be everyone trying to figure out everything for themselves. We just can’t assume that because one technique or set of techniques worked for you, that it will work in any other circumstance. Agile assumes it will work in every situation, or at least that is what the people trying to make money want you to believe. BTW, this sort of marketing based process adoption is not exclusive to Agile or software development. Agile just happens to be the current snake oil in my chosen profession.
on October 25th, 2006 at 11:23 am
“Agile assumes it will work in every situation, or at least that is what the people trying to make money want you to believe.”
There’s the rub. “Agile” doesn’t assume any such thing. OTOH, when people want to separate you from your money, they’re liable to try and get you to believe just about anything.
It’s clear that you are unshakeable in your beliefs. Carry on!
on October 25th, 2006 at 12:03 pm
Perception is reality. What people believe something means is what it means, regardless of what other people want it to mean. You can try to change the belief or you can move on. I don’t have enough energy, time or money to try to convince people that Agile is different than what the marketers have told them it is. It seems you do, so good luck with that. I’m moving on.