Delimit Your Responsibility

You're a developer (or developers) intent on adopting XP or getting it adopted. You've learned enough about what your team is doing wrong and what it is doing right to IdentifyTheWorstProblem; you have decided to solve it the XP way, to let other problems wait for their turn when they are no longer the worst, and to measure the results of whatever you will do.

The problem may be too big for you. Part of XP's appeal is the FortyHourWeek, and you recognize that getting BurntOut adopting XP would be a contradiction in terms.

Therefore,

Don't make promises you can't deliver on. If the problem you're addressing is too big to be entirely solved - using XP or not - tell whoever needs to listen. State that you will have solved some part of the problem by whatever date is appropriate. Don't say that you will give it your best shot; start out confident that you will do something right, even if you don't know how much.

Then,

Your next step might be to make the difference between XP and other processes evident, to focus with precision on how the XP practices you're proposing to install address the problem. Whether or not you call it ExtremeProgramming (it might or might not be a good idea) will vary, but be sure to identify the practices. Depending on what your worst problem was, you might want to ShopForIndexCards, ForgetTheDebugger, or SaveLotsOfMoney.

Examples

I had just joined the team. All of the "infrastructure" software solutions they'd seen, some of which had wasted days or weeks of valuable time in evaluation, either came up way short in functionality or were way too expensive; usually both, in fact. The question naturally came up : "Can we implement our own ?" Well, we could, of course. Nobody was stopping us. Only... The deadline for going in production was less than a month hence.

I tried to see it the XP way. "Well, what we can do is implement something. I can't give any guarantees as to how much of it will be implemented in a month; I won't even hazard a guess as to how long it would take to implement as a whole. I can't draw UML diagrams for it , or write technical specs; that would take time from coding it, which we can't afford. Oh, and I have two kids - I can't do much OverTime. But I should be able to do something simple that will have very few bugs, and show a working program early and often."

I had more or less expected that would be the end of a brief but interesting career with that firm. To my pleasant surprise, the right decision was made. And that's how we adopted XP.

Discussion:

Wow, that is a great example of how one can turn a desperate situation into an opportunity for improvement (i.e. AdoptingXp). Cool! -- RobHarwood

Taken to extremes, this can be an AntiPattern. That's not my job. or I can't guarantee that. are sentences that can become too easy to say by those who want to avoid responsibility entirely. Everyone has to be willing to accept responsibility for taking risks, and to accept responsibility for the outcome. -- KrisJohnson

"Success has a thousand fathers, failure is an orphan."

I'd say this is a very frequent AntiPattern, and I don't know why it is linked to Xp, maybe you should try DelimitYourResponsibilityInXp?. At least I've witnessed tons of times, especially in the western hemisphere. All my friends that immigrated from Eastern Europe told me they had the same impression when they arrived here.

The first concern of the project manager is to delimit his responsibility. The first concern of "architect" is to delimit his responsibility. The first concern of senior developers is to limit their responsibility. You can imagine that junior developers will feel happy because they won't have responsibility.

The first concern should be getting the job at hand done. What if it fails? You assume responsibility, assuming responsibility makes you do your programming better so that it won't fail. What if it succeeds ? You assume responsibility that you did it well and reliable and is not going to crash down the road.

The concern here seems to be not to get XP busted. What are you talking about ? Your care should be to do the job even if you had to do the bloody WaterFall. You choose to do XP, great fo you. Take pride and responsibility in that. You are not religious zealots trying to prozelititize for XP, for God's sake. You are there to do the bloody programming and get results. -- CostinCozianu

Costin, you missed the context. The focus on this page is how to get XP installed as a development process in your workspace. That's why this page is primarily sourced from AdoptingXpPatternLanguage. Naturally enough, then, the primary context is how to get XP adopted without some preventable failure screwing up the process. -- anon

I think I correctly interpreted the context. Both what you say here, and what was enounced earlier is concerned with how to prevent a possible project insuccess (maybe a partial failure) from casting a bad reputation over XP. Isn't it so?

The only good part of this pattern that I agree with is not to promise ( or create expectations for ) something that you can't deliver. This is obviously good, they even teach you both in school and in family when you're a kid. But this applies to whatever methodology, why is the starting context narrowly defined as You're a developer (or developers) intent on adopting XP or getting it adopted ? I have a problem both with the proposition itself and with the way the larger context is narrowed to XP.

There is no "larger" context. This proto-pattern is intended to help developers who want to work the XP way; it is in fact, largely, the story of one such developer (me).

This wasn't about "protecting XP's reputation". It was about giving feedback on risks I had identified, it was about not wanting to let my enthusiasm for XP be the cause of a failure. -- lb

Your care should be to do the job even if you had to do the bloody WaterFall.

I don't know how to make a project work with WaterFall. If I attempted to do it that way, knowing that I'm probably going to fail, wouldn't that be "making a promise I can't keep"?

Delimiting your responsibility is a key aspect of getting anything done. If you fail to identify clearly, to yourself and to others, what the extents of your responsibility are, you risk taking on too much. If you do not have authority (and competence) to match the responsibility, you are heading into a deep dark hole of failure.

This is not a CYA-technique; that applies when you refuse responsibility for something you do have authority over. This is the simple rule of "Focus on what you can do, and do it."

AdoptingXpPatternLanguage

CategoryPattern | CategoryExtremeProgramming