Extreme Programming In Enemy Territory
Extreme Programming In Enemy TerritoryMoved here from ExtremeProgramming
Summary
Most organizations don't feel the need to examine their processes - the ones they have are obviously working. The company gets contracts, delivers something and gets paid - so what could possibly be wrong with that? The difficulty in introducing new practices - from anything as seemingly innocuous as using the standard library upwards - is that doing so challenges the central truths of the organization itself. Attempting to do vocally ("Why do you do it this way?") so can get you marked as an upstart/not a team player/subversive.
If you just quietly apply what you feel are best practices as best you can, you'll be recognised as a productive worker, and (hopefully) be rewarded. Unfortunately no-one will ask you why.
The question is, if you can do ExtremeProgrammingInEnemyTerritory, i.e. in an organization that is not prepared to even think about their existing development process/methodology? The current process is BigAnalysisUpFront, BigDesignUpFront and spending big money on even bigger implementation after that. For implementation we strictly follow the NotInventedHere pattern to build a large scale (300+ people) C++ system. DeveloperOnlyXp is a great idea which I can't follow since a large number of developers seems to be quite happy with the current approach. A small number of programmers try to follow as many of the XpPractices? as possible, though we have to use GuerrillaTactics to do so.
It doesn't matter what you say, it matters what you do.
The point here is that if there are a few of you (one or more) who want to adopt some XP practices, you can do so quite effectively. Quite probably, just doing good stuff is better than talking about how other people might do good stuff. And if you're really lucky, they'll ask you how come you're so unstressed, why you don't get in trouble integrating, and so on. -- RonJeffries and helpers, please
Things to do right away include:
Fear is enemy number one
Communication is an important issue within XP, especially when introducing it in enemy territory. Especially if you are a totally lone wolf in the lowest rank at your company, with this idea of XP in your head, instead of in silence starting to get people to sit as your pair, consider the following. You should think of strategies to move the team that involved informing my supervisor, the contract's project manager, and the team's government liaison of where you are going. This would involved a little selling and gaining people's confidence. Management support might shift the fear factor into courage, or some other dynamic, such that your fellow team members would be more afraid _not_ to, 'check it out.'
Processes are a hard sell. Everyone who comes in contact with a process has to swallow their pride to a degree. It goes both ways. Processes are the mechanisms by which projects are controlled and stakeholders get insight. It is hard to convince a stakeholder to look for assurances other than the ones they are used to. This is part of the IllusionOfControl. It doesn't help that just about any manager can buy a process on a CD today and waive it around thinking that their problems are solved, or that they don't have to think as hard about them because the people who wrote the material on the CD did the hard thinking for them. On the other hand, if you do your own thinking you are liable to end up with a home-grown methodology. Given that even the most brutal processes succeed to a degree, the best hope a new one has is buzz. Generate the buzz.
Also, when introducing XP, remember that ExtremeProgrammingIsNotNew. At least not completely. It is the unknown that is most scary, so don't make the whole XP appear as a new unknown thing.
What is it going to take to PropagateXp?
See also
I think you can, or at least you can try.
Most organizations don't feel the need to examine their processes - the ones they have are obviously working. The company gets contracts, delivers something and gets paid - so what could possibly be wrong with that? The difficulty in introducing new practices - from anything as seemingly innocuous as using the standard library upwards - is that doing so challenges the central truths of the organization itself. Attempting to do vocally ("Why do you do it this way?") so can get you marked as an upstart/not a team player/subversive.
If you just quietly apply what you feel are best practices as best you can, you'll be recognised as a productive worker, and (hopefully) be rewarded. Unfortunately no-one will ask you why.
-- JezHiggins
See XpCourageValue
I was talking the other day about saving a 180 person/150M DEM project that is about to die a horrible death. They "have" to go into production before Y2K, but they don't have a prayer. The idea I came up with is an emergency backup interim solution- nowhere near as cool as the "real" system, but something we can put into production in a few months. Then when the "real" system is ready, we can turn off the stupid little thing we just hacked together for 10M DEM (it has to be 7 figure or they won't take it seriously- it should be ~5 person/years of effort). So, we're just selling them insurance. -- KentBeck
Kent: I think your reply highlights the difference between our two situations. You have been brought in as an outside consultant to try and salvage a project which it has been recognised is failing. I get the impression that you doubt that the "real" system will ever be finished and so the "stupid little thing we just hacked together" will remain in production. Hurrah! Another triumph for XP.
This makes Kent sound like Red Adair for software!!! -- PaulSimmons
We don't have that kind of clout. We're lowly developers - respected and senior within our own group perhaps - at the bottom of the corporate pecking order on a project which is not recognised as failing. (It may not be - but I believe it could be succeeding more.) And try as we might, our little group in amongst 300 others does not make a convincing voice for change. It makes us "troublemakers". So, as I described above, the best we can do is proceed by stealth and try and spread (what we believe to be) best practice by just doing it.
So the question remains - can we practice ExtremeProgrammingInEnemyTerritory to any meaningful degree? I don't believe you are in the case you describe, because you were invited help by people who want to listen. We want to help, but there isn't anyone who wants to hear.
What I have learned repeatedly through life, and especially through doing XP, is this: It doesn't matter what you say, it matters what you do.
We can discuss why I need to keep learning this in some other venue. Here, the point is that if there are a few of you (one or more) who want to adopt some XP practices, you can do so quite effectively. Quite probably, just doing good stuff is better than talking about how other people might do good stuff. And if you're really lucky, they'll ask you how come you're so unstressed, why you don't get in trouble integrating, and so on.
Things to do right away include [help me here, guys]:
This appears to be what we have done, when the size for our whole project was 3 people. CodeUnitTestFirst, PlanningGame with ProxyCustomer?, CrcCards, PairProgramming.
Maybe also ThereMustBeFood could be applicable in enemy territory. It, however, runs a risk of getting in contempt, as certain workplaces disaprove bringing food to where you work. In our project we didn't aggressively apply ThereMustBeFood, but everyone was allowed to have their snacks, tea and coffee and we did have a celebration after each milestone. That was an important motivator! -- TomiBgtMantyla
People- I have just spent 2 years trying and failing to get another XP project started on the scale of ChryslerComprehensiveCompensation. I have been unable to get a project of any size using the whole basket of practices. Therefore, any argument of the form, "Well, if you're Kent the Beck..." is a bullshit excuse. It ain't easy for me. I have to use stealth and WorstThingsFirst and sometimes swallow my pride and do things the wrong way just because the client tells me to and I have to get paid somehow.
I'm sure those who don't want XP to succeed will use the lack of followup projects as ammunition. I don't care any more. I'm damned frustrated- I see a better way but I encounter project after project of people who would rather fail in a familiar way than possibly succeed in an unfamiliar way.
OTOH, I hear from folks nearly every week who are trying XP for themselves by themselves and succeeding. This is good, because it counteracts the argument that you have to have Ron or me or Ward to succeed. OTOOH, I wouldn't mind just a weentsy little bit of that aura to remain- just enough so I can coach one project at a time that trusts me. -- KentBeck
I wasn't trying to say it's easy for you - you're Kent Beck, and I'm sorry if I annoyed you. What I was try to do was highlight the difference in our situations - you were invited to give your input, while our input is not wanted.
I don't know whether to be relieved or disappointed that your opinions are then being rejected. Relieved, because it happens to you too, in spite of the fact that you are "Kent the Beck". Disappointed, for the same reasons. I/We feel the same frustration - we want to do the best job we can, but we are actively discouraged from doing so.
C3 is best thought of as an existence proof. We have gone off process and back on enough to be certain that it's the process that makes the difference. We have gone off process and back on enough to be aware that something makes you want to go off process. Whether, as Alistair suggests, it's because XP is a high-discipline process, I'm not sure, but I'm inclined to think so. Another possibility is that we all have feet of clay.
Within DaimlerChrysler there are those who don't understand our process, and who have a lot of trouble with what they believe it to be. Also within the company, there are teams who are adopting some of our key practices.
My guess is that until XP is recognized in the industry as the way to be, it has to be done from within. Fortunately, lots of it can be. -- RonJeffries
Extreme programming in enemy territory is a good subtitle for the VcapsProject page. When I first saw the project it was awful. People were unable to work together. People were unable to say what they thought. People were being beaten down and discouraged by jangsters (see JangIt). People hated being on the project.
To change things we had to remain true to what we believe. I believe that Kent's methodology produces quality software on time. I believe that Kent's methodology is 6 times faster than anything else I have seen. I believe that Kent's methodology makes programming fun and a desirable occupation.
I spoke to many people about the work KentTheBeck is doing. Some listened, most sneered. I then started working the way I knew was correct. I was given a week to write a new section of code. The world was going to come to an end if I missed the one week deadline. I took 3 weeks to finish it. I spent 2 weeks writing UnitTests first. The world did not end.
We got the functionality out faster than anyone thought possible. We had been given a short deadline to allow for a huge effort in debugging, which I did not need. Knuckles were white, teeth were gritting, but I got it out in time. Now the environment began to change. Those first unit tests were the key to getting management to realize we were doing things better, smarter, and faster.
Then disaster. We were told a few months ago that the VcapsProject was going to enter a phase 3. Since we had proven so useful our little team was going to play a major part in this new system. We were also told a couple months ago that a new and improved methodology was going to be used.
Now I have been around long enough to feel I have earned the title "consultant". Companies pay a lot of money to be able to ask me a question and get an honest answer. I owe them my best thoughts. I told a high level manager that their "new" WaterFall methodology was not going to deliver on time.
I was fired on the spot. The managers we had worked so hard to teach about ExtremeProgramming were gone, replaced by someone who knows absolutely nothing.
But even now after months of unemployment I remain true to my beliefs. I have lost consideration for several jobs because I start my interview with "let me tell you about a man named Kent Beck". It is the way I choose to work now.
But all is not lost. I received word that the VcapsProject phase 2 (the extreme version) is coming back to life. The customers have realized that phase 3 will not be delivered in time. They knew all along that what makes the project work is our team and this new way of doing things. They have chosen to trust the phase 2 team to deliver on time and not the phase 3 team.
Unfortunately the Ford manager who wanted to restart VCAPS phase 2 felt the need to ask for the old team back from the phase 3 manager who killed the project to get them. The result was a second political killing of the phase 2 project to be able to keep them. Alas, poor VCAPS I knew it well, Horatio. -- DonWells
I wonder whether a Chemical Engineer, say, who made such a challenge to management on a refinery, say, could be so summarily dismissed. No wonder our industry's a mess. -- SteveFreeman
Fear is enemy number one.
First off, I must say, participating in this experiment (Wiki) has me so excited that my heart is pounding and my mouth is dry - of course, I've, at a late hour, had several cups of coffee too.
I've used many of the practices in XP for some time now. I began in that direction by taking a step further or to its logical extreme, everything I learned about software dev and design in my computer science classes and other people's code. Throughout, I've always had the sense that I was doing something or was onto something a bit different than most developers. KentBeck's ExtremeProgrammingExplained is a wonderful affirmation. But I digress.
My most recent job was as a programmer/analyst for a contractor at a federal government agency in Washington, DC. Though I was one of a five member programming team, each member usually was assigned projects individually by our contract's government liaison. For the first couple of years, each member shared an office with a government employee - there was little team interaction, and team meetings were sparse.
To save space, our team was moved to cubicles in a single room. As I naively continued my quasi-XP development practices, I began, in the unbeknownst to me, spirit of XP, attempting to include other team members in my dev process. I would say, "Hey, take a look at this," or "Check this out," in a genuinely innocent attempt to get a conversation going about something that interested me relative to my program development. I was always disappointed by lack of response, and it seemed as though fear, on the part of fellow team members was the reason.
Fear of what? Fear to show ignorance? Fear of wasting time on "idle chatter?" Fear of appearing to be led or not being in the driver's seat? I figure all of the above, and perhaps other reasons I can't think of right now.
Now, it's true, I've never been accused of having a lack of enthusiasm when it comes to something I'm interested in, and programming and program design is certainly something I'm interested in, but my efforts to elicit interest among other team members was light hearted and casual. Other members had nothing to lose by 'taking a look,' or 'checking it out,' and may have even gained from it. If they had, who knows?, we may have evolved into a formal XP team without even knowing it. Alas, however, I'm no longer working for the company, and I'm presently looking for work.
The point is, some cultures can indeed make XP very difficult. Each team member must be confident, open minded, courageous. They must be more focused on exploring the outer limits of programming, design, problem solving, than collecting a pay check, peer networking, and fearing for their jobs (not necessarily in that order). For some (and there, but for the grace of God, go I) the above characteristics may be extremely challenging to achieve.
In retrospect, having digested Kent Beck's book, and having had time to reflect on the above team member experience, I can see how I might have handled things differently.
If I had been more conscious of what I was doing, where I was heading (XP) in my design and programming I might have thought of strategies to move the team that involved informing my supervisor, the contract's project manager, and the team's government liaison of where I was going. This would have involved a little selling, but I think I had most of these individual's confidence. At the risk of sounding crass, management support might have shifted the fear factor, or some other dynamic, such that my fellow team members would have been afraid _not_ to, 'check it out.' Once there, I'm confident my fellow team members would have seen that fear is not an element of XP. -- BryanHoover
I've been trying to steer my present consult into XP territory for about six months now. I set about it carefully - wrote crypto-XP methodology documents (ExtremeUnifiedProcess) to slip the ideas past the in-house RationalUnifiedProcess gestapo; spent a lot of time up front introducing both the business users and developers to the practices; stuck to my guns throughout the PlanningGame. Now I'm trying as hard and as gently as I can to introduce the developers to ContinuousTesting and PairProgramming.
I'm certain I'm doing what's best for the project, but goddamnit this is hard work! I'm totally sick of being the guy who says, "sure, we could do it that way, but why not try it like this?" And I hate having to armwrestle both business and management to keep 'em doing productive work.
And to tell the truth, more often than not, I walk away wondering whether the gain is really worth it. On a typical consult I tell the clients what they want to hear, help the developers do their best with what they know, keep my nose clean and stay out of trouble. It's easy, it makes everyone happy, and if the project runs late or delivers crap it's not my problem. I do my best work and I leave 'em smiling.
And yet, and yet ... I think I'm making some headway. I think things are coming together. And I think there's no way in hell the folk I'm consulting to can make their Y2k freeze dates unless they go this way. The fact is this project would be no bowl of cherries without XP. In fact it'd look a lot like a DeathMarch without it. So what can I say? I say what CommanderMcAuliffe? said to the Nazi ultimatum during the battle of the bulge: "Nuts!" -- PeterMerel
I feel your pain, Peter, and I mean that sincerely. Clearly no team or coach can be at peak all the time. But when you're not, it sucks, n'est-ce pas? -- RonJeffries
Hmm. What do I mean by Nuts!? I mean we're doing the right thing the right way, and I'm happy to take whatever shit that stirs up. I expect doing this will get easier as time goes by because its results speak for themselves. And I'm secure enough in my position that I'm not about to go look for a more suitable consult. So no quarter offered, none taken, damn the torpedoes and full steam ahead, or in other words ... Nuts!
Processes are a hard sell. Everyone who comes in contact with a process has to swallow their pride to a degree. It goes both ways. Processes are the mechanisms by which projects are controlled and stakeholders get insight. It is hard to convince a stakeholder to look for assurances other than the ones they are used to. This is part of the IllusionOfControl. It doesn't help that just about any manager can buy a process on a CD today and waive it around thinking that their problems are solved, or that they don't have to think as hard about them because the people who wrote the material on the CD did the hard thinking for them. On the other hand, if you do your own thinking you are liable to end up with a home-grown methodology. Given that even the most brutal processes succeed to a degree, the best hope a new one has is buzz. Generate the buzz.
I hope that Kent does not get too despondent about this. I think that the genie is out of the bottle and there is no cramming him back in.
What is it going to take to PropagateXp?
Not quite enemy territory, but may be of interest: AnotherXpExperiment
Also, PaulSimmons is trying IntroducingXpToEnemyTeam?.
enemy territory not at all. A 'holy' mission isn't very easy, but it won't fail if everyone tries to explain. Managers and stakeholders got a brain to use, and most of the time they use it. -) When you have to explain, you have to talk in a known way, Using known words like analysis, design, redesign, quality management... . ExtremeProgrammingIsNotNew, it is different. Differences are easier to explain than new things!!
XP is a lot about un-learning all the corporate IT processes and just using your common sense.
Warning: If your bug rate is too low, and your velocity too stable, your XP could be exposed. Remember to work late, pounding a debugger and groaning, often enough to disguise those metrics. --StickToYourGuns
EditText of this page
(last edited May 6, 2009)
or FindPage with title or text search