PairingInAStrictHREnvironment
|
|
| Your trail: |
Difference between version 17 and version 4:
| At line 13 added 46 lines. |
| + |
| + Keith, I'm unclear on what features a "workable" compromise would have for you. Have you explained your concerns to the administrators, and asked for their help in finding a solution that does not impair productivity, and hence your team, your department and ultimately the company's bottom line ? What was the reply ? -- LaurentB |
| + |
| + Good question. A Workable compromise is one that does not interrupt the flow of pairing with the need to log out/log in, or even switch to a different profile (as it seems that would lose context in the IDE, local servers etc.), or ''even'' go through some time-recording shennanigans to provide a minute-by-minute log of who was typing when (this has been suggested), as the keyboard changes hands between pairing developers. |
| + |
| + The team discussed this and I have proposed to the business the team consensus, which is that the one pairing id (username "extreme") is available only on the designated pairing mahcines, and is the only login (bar "administrator" and such) that is available on those machines, and then we make it part of the "XP developer" role definition that we all take joint and several responsibility for what happens ''on those machines'' and ''with that login''. This appeals to me since it is a sociological fix for a sociological problem, and is fully aligned with the values and principles of XP. I've yet to have a response. |
| + |
| + My informal survey of other XP teams regarding this question has been illuminating. No-one is prepared to admit to having had this problem before (which amazes me). It seems that our situation is unusual in that 1) we have one "extreme" login under which all pairing occurs, rather than a pair's work being done under one member or the other's login, and 2) we have half as many pairing machines as developers, rather than a 1:1 pool of machines, half of which are idle during pairing time. I'm most reluctant to monkey around with either of these features of the environment, as they both seem to me to foster good practice. I should add that OliBye put this environment in place and did a pretty good job, I wouldn't want to do XP in any other scenario. So I'm particularly keen that HR don't break this scheme a few weeks before I export it to the new team in Singapore!--KB |
| + |
| + I'm leaving this company --OliBye |
| + |
| + Surely that's an over-reaction... :-) |
| + |
| + Extreme? --OliBye |
| + |
| + ''Maybe they could create the set of all possible permutations of pair-logins. Each permutation would have a unique password made of two halves. Each developer in the pair would be responsble for keeping his half of the password secret - so both partners need to be present to log in. To avoid being fired for something your partner did whilst you were on break, you'd have to lock the machine before turning your back on the monitor..... or the management could decide that this insanity has gone too far and trust the developers to get on with the work. -- AnonymousCoward'' |
| + |
| + I have great respect for the positive attitude of people trying to find a solution to this problem, however when I realised it was the company I'm leaving I had to laugh, words fail me, I can see where they're coming from and I'd happily to tell them where to go. --OliBye |
| + |
| + __Update__ |
| + Now that the "simple" solution (they tell us what to do, we do it) has not worked, and the ball is back in MIS/HR's court to assess our suggestion, the whole problem suddenly seems to have become much less important, and we have an instruction to carry on as usual until they get round to it... |
| + |
| + __Further Update__ |
| + Joint and several responsibility was not acceptable, there has to be a named individual. So, the suggestion now is that the coach of a team will take responsibility for what happens on the pairing machines only, uner the shared login only, and during pairing time only, whomever was using the machine at the time. As one of those coaches, I'm pretty happy with this, since I do actually trust my colleagues not to surf porn (well, not to surf porn ''on the pairing machines, uner the shared login, during pairing time'' :), and I'm not afraid to stand up and say so. --KB |
| + |
| + ''Seems like a perfectly reasonable solution that accomodates everyone. I'm intrigured by the test built in to the solution. Unlesss the XP folks, in this case you, Keith, actually trusted your colleagues as you were asking the MIS and HR folks to do, the solution would fail. You'd back off. Real solutions to balancing agenda often have this kind of "money where your mouth is" element to them. In this case, the development team has to exhibit the trust they were asking of others. The MIS / HR folks have to exhibit some willingness to acknowledge that their concern is to have _some one person_ responsible for each act committed on one of the machines they administer.'' |
| + |
| + ''I'll be curious how this plays out. As much as it is an inescapable reality, the process bound have a hard time coming to terms with the fact that in the end, you have to trust somebody, to some degree, or nothing gets done. Even in a secure environment working with classified material there are instances of "trust" and of delegated responsibility. Fascinating tale Keith.'' -- JB |
| + |
| + |
| + !Musing on this Story |
| + |
| + Lots of folks are interested in free policies - free for them to implement. Anyone who's job includes managing risk but not results is at - er - risk of this. HR, for example, which is tasked with avoiding lawsuits and other legal claims but not with producing something. They will, absent some perspective, myopically make policies. They are ignorant, and managed to narrow goals vs. malicious. My personal favorite example of this involves computer security people who in the end are biased toward a computer locked in a darkened room connected to nothing. Such a computer is close to perfectly safe, but useless. Sometimes I have to point this fact out to them: All use of a computer to do some good includes associated risk to security. |
| + |
| + Folks tasked with getting something done, even software folks, often engage in their own accidental (sometimes willful) unawareness of other folks' concerns. These range from regulation and lawsuits (which unfortunately every business in a Developed nation must consider at all times) to simple costs. I've seen dozens, no hundreds of developers who insist on their own desktop configuration without considering the possible effect on a LAN which someone else is tasked with keeping available. These same developers are the first to complain when their computing environment is down. They usually don't recognize that the beleagured LAN staff are solving a problem very different from "optimizing one developer's coding." The LAN support staff are usually managed as a cost, so their problem is keeping some minimum service up at all, for a big pile of people, at the least possible cost. They are chronically under-staffed. It's a crummy job most of the time. |
| + |
| + The trick is to bring the concerns together. Rather than see the HR policy and it's abandonment as sinister or inconsistent, why not simply see it as everyone doing their job, perhaps with some ignorance? If it's free, HR & MIS have a perfectly legitimate concern to meet with the one-login policy. And why would they consider groups of people sharing a keyboard as dynamically as in pair programming? That's not what they are used to seeing. The development team also has a perfectly legitimate concern to assert about the policy, specifically: "This isn't free." So now someone has to make a tradeoff decision. |
| + |
| + There's nothing necessarily sinister, or even myopic here. It's simply people who are new to each other working together in a business. HR and MIS folks, especially LAN administrators do tend to have an unfortunate communication style when it comes to policies. In part that's the mindset that fits people to such jobs. In part that's the crap that these people have to put up with. "New" folks to an organization will walk head-first into old assumptions in that organization. That's part of the price of being new, and of changing things. |
| + |
| + The lesson that I'm inclined to take from this story has two parts. First, if I want to do something unusual, the support organizations may not be set up to accommodate that. Second, that I can give them the opportunity to be part of the solution. I can't count - literally can't count - the number or "uncooperative" and "reactive" LAN or Network support teams I've co-opted simply by starting out with: "I want to do something that I suspect is unusual around here. Let's figure out what it will take for you to support it . . . " If I'm flat out stiffed, which happens sometimes, I have a very interesting fact to kick upstairs to one of those trade-off decisions. |
| + |
| + If in the end, my concerns and priorities are never considered, and there is no appeal, or no successful appeal, well, that's an important and useful piece of data. |
| + |
| + |
| + But that's just me. -- JimBullock |
Back to PairingInAStrictHREnvironment, or to the Page History.
|