9 ms·

This reminds me of the Extreme Programming "bubble" (for lack of a better word). Really awesome Practice A (skipping up-front requirements development, shorter

by wtracy 6y ago

This reminds me of the Extreme Programming "bubble" (for lack of a better word). Really awesome Practice A (skipping up-front requirements development, shorter QA cycles) is made possible by really tedious Practice B (pair programming, TDD). If you try to cherry pick the obvious shiny stuff while skipping the slow/expensive less-obvious things, you are doomed to fail. Getting back to the subject at hand: I think what would be much more helpful than case studies of existing successful teams would be case studies of teams that were successfully turned around. Not only does that quickly winnow down what factors actually have an impact, it provides more actionable advice in other ways. There are certain factors that are only helpful if you start with a magically perfect team from day one that may not help (or actually be harmful) when implemented with B players or a team with existing dysfunctions. (You are probably right about detailed retrospectives falling into this category.)

jacques_chester 6y ago
Denise's case studies are coming from time at Pivotal, which performed a lot of turnarounds by embedding client teams in order to demonstrate the possible world. I've also worked at Pivotal and I was allocated to several rescue missions in both Labs and R&D. A lot of the work was patiently modelling the possible and continuing to make small, incremental steps towards the better condition. From week to week the situation may appear to be impossible, but one day you look back and realise how much better things are than 4 weeks, 12 weeks, 6 months ago.
- urbanetrellis 6y ago
  As someone who got to embed with a mixed client/Pivotal team, this was a great experience for me. I had never seen pairing or TDD done in a disciplined and thoughtful way, or participated on a team that was "Agile" in more than just name and appearance. We certainly had plenty of room to keep improving, but by the end of my time on the project we were deploying a high-quality product on an ongoing basis, making good design choices, and delivering substantial value for the users every few weeks. It felt great and I'm sorry to say I haven't gotten to experience it again since.
- twic 6y ago
  I spent about thirty or forty years of my life working with enterprise clients in Pivotal Labs, which i think lasted two and a half calendar years. A year or so of that was leading engagements with one particular enormous and highly dysfunctional retail bank. Every week, we tried to demonstrate that a better world was possible, and every week, they remained resolutely stuck in their world of suffering and not delivering software. Some time after i left, i asked after that client. Apparently their organisation is agile, the projects shipped successfully, and they're really happy. I have no idea how that happened. I'd love to think that i was making a difference and just not seeing it because i was stuck at the coalface, but it's probably just that people much better than me got involved after i left!
  - jacques_chester 6y ago
    Ah yes, the banks. By far our hardest clients. I think we took on too many bank engagements.
    - dajohnson89 6y ago
      what about banks make them so difficult to work with?
      - jacques_chester 6y ago
        It's a mix of things. The biggest is that they're just enormous, so nearly every engagement is pretty much from scratch. As in: single departments of single divisions could dwarf us in headcount and revenue. It can be dispiriting for Labs consultants and I know people who quit because of it. A lot of the time you hit what I call "veto culture". You are forever running into groups, committees, boards, bureaus, offices of the whatever etc etc who have the power to gate some change. Those folks almost always say "no". The logic is simple: if they say "yes", and something goes wrong, and they are blamed for it, then they might lose their job or at least risk a bonus or promotion. But if they say "no", there's no risk to them. In practice it drives everything productive underground. We often relied on discovering the nomenklatura who actually did things as we went. The parallels to the USSR's experiences (as I understand them) were fascinating. It's important to note that I don't see any of this as being a deliberate outcome. In general folks don't wake up and ask "how can I make my company less productive and pleasant today?". People do what makes sense to them, based on their experiences. But I have seen how culture can drift into a bad place that's hard to dig out. Big banks seem to have even more of this than regular megacorps. I know some folks who worked in the Federal sector had some similar experiences, but overall it seems like a lot of the time it seemed more manageable due to different incentives. In fact a lot of the compliance / standards folks were often thrilled that someone wanted to talk to them.
dionian 6y ago
I agree with you and i also see the flip side of this: people who think you need to do 100% of XP techniques to be 100% XP. Whereas XP is supposed to be about doing what's right for the situation
- urbanetrellis 6y ago
  I would argue it's doing what's right for the situation but with a few top level goals that should constantly be in view. - Simplicity: you should be creating simple designs / solutions - Feedback: you should be getting continuous feedback as to whether what you're doing is working and self-correcting - Courage/Communication/Respect: you should be fostering a collaborative environment where people feel free to tell the truth and feel they're respected as people and professionals The practices (pairing, TDD, etc.) are just a way of getting to those goals. You can follow any other disciplines you want, but if the end result doesn't look like what I just described (or if it isn't the explicit goal of your activities) then I don't think you're doing XP.
- mikekchar 6y ago
  The 12 practices of XP are not XP any more than a finger is not the thing that it is pointing to. XP is intended to be a minimal set of practices that generate a method. Rather than specify a method (which will dependent upon circumstances), XP specifies a set of practices which will hopefully help you discover the method. Having said that, if you are not doing the 12 practices, then you are not doing XP. You are doing something else. It's totally fine to do something else, but it is not XP. It may have been inspired by XP. That's also really great. But it is not XP. This is important because people talk about their experiences with XP and it is difficult to determine if their success (or lack thereof) is actually due to XP, or other factors. Do the 12 practices actually generate a method? Does it happen all the time? Is there something you have to do to get it to generate the method? Is the method always the same? There are many, many question. For most people, those questions are boring because they are not actually interested in XP. They are interested in being successful on the projects. This is a very understandable position to be in! However, it is frustrating for people who are interested in XP ;-)
hinkley 6y ago
XP (and most Agile Manifesto children) proscribes a bunch of onerous activities in favor of a set of less onerous activities, but people aren't looking for discipline, they're looking for ways to avoid pain. While discussing the failings of XP as practiced, someone put it this way: You are effectively telling people that if they eat their vegetables they can have dessert, and what happens is people eat their dessert and don't want to eat their vegetables.
karatestomp 6y ago
> Really awesome Practice A (skipping up-front requirements development, shorter QA cycles) is made possible by really tedious Practice B (pair programming, TDD). School/district administrators do the same thing. "Hey I just read [popular education book about some system] and got the district to pay for me to go to a conference about it and it seems great! We're doing that now. Oh but not that part. Or that other one. Those make me uncomfortable." [two years pass] "Huh, weird, none of this is working for us, guess the book sucks. Hey, I just read this other book...."
- skillfulpurple 6y ago
  This is unfortunately common in management. Ideas are easy and exciting; execution is difficult and requires sacrifice & discipline. Human beings love to enjoy the benefits of thinking pretty thoughts without the actual cost of action.
mpweiher 6y ago
> with B players or a team with existing dysfunctions. Hmm...I got handed a team of C players. By focusing on the technical aspects of XP such as simple code, test first, quick turnaround (work on master, check in when green) the team was outperforming the "star" team(s) after about a year or two. We paired only on a need basis, but I wouldn't say that we failed.
- wtracy 6y ago
  I would love to see a detailed retrospective on your experience.
donw 6y ago
> If you try to cherry pick the obvious shiny stuff while skipping the slow/expensive less-obvious things, you are doomed to fail. This is true with everything in life that you seek to do well: cooking, dancing, etc. > Really awesome Practice A (skipping up-front requirements development, shorter QA cycles) is made possible by really tedious Practice B (pair programming, TDD). A big nit: you don't exactly "skip up-front requirements development". First, the appetizer: One of the things you actively seek to avoid in an XP team is blocking: having people sitting around, doing nothing, because they are waiting for other teams/roles to hand them something. Another thing you want to avoid is building things that are not needed, wanted, or required by either you or your customers. Finally, customers are going to change their minds, and you can come to them with one of two answers, either, "we can't do that, it's not in the plan"; or, "sure, we can change direction". Now, the meaty goodness: You absolutely do market research, and probably have designers doing various types of prototype testing with Real Live Users (Or At Least Their Proxies) before you kick off any serious engineering work. This will yield a pile of low-fidelity prototypes, assumptions to validate, and a tentative roadmap upon which your whole team (Product, Design, and Engineering) can begin execution. You absolutely should have plans that stretch into the future, but the farther out those plans go, the lower their fidelity should be, because you are almost certain to change those plans as you build, experiment, and learn.
- mikekchar 6y ago
  > Finally, customers are going to change their minds There is actually a type of orgnaisation that does not change their mind. They have a vague idea upfront what they want. They ask for a plan and an estimate. They never actually think about what they want in detail. When the thing is delivered, if nothing goes wrong, nobody looks at it or thinks about it. If anything goes wrong, then they say, "You didn't deliver what I asked for" (a vague idea that doesn't break things ;-) ). The biggest problem I've had with some groups is convincing them that changing their minds is actually crucial to the success of the project. It's funny because you'll have a whole bunch of other people who are trying to cover their asses by getting management to sign off on the plan, etc, etc. But I'm coming in and saying, "I want you to change your mind" because then they have to have a mind in the first place. It's surprisingly challenging. I find that if I don't succeed in that, then it's pretty difficult to succeed with an XP team.

by wtracy 6y ago

jacques_chester 6y ago

Denise's case studies are coming from time at Pivotal, which performed a lot of turnarounds by embedding client teams in order to demonstrate the possible world. I've also worked at Pivotal and I was allocated to several rescue missions in both Labs and R&D. A lot of the work was patiently modelling the possible and continuing to make small, incremental steps towards the better condition. From week to week the situation may appear to be impossible, but one day you look back and realise how much better things are than 4 weeks, 12 weeks, 6 months ago.

urbanetrellis 6y ago
As someone who got to embed with a mixed client/Pivotal team, this was a great experience for me. I had never seen pairing or TDD done in a disciplined and thoughtful way, or participated on a team that was "Agile" in more than just name and appearance. We certainly had plenty of room to keep improving, but by the end of my time on the project we were deploying a high-quality product on an ongoing basis, making good design choices, and delivering substantial value for the users every few weeks. It felt great and I'm sorry to say I haven't gotten to experience it again since.
twic 6y ago
I spent about thirty or forty years of my life working with enterprise clients in Pivotal Labs, which i think lasted two and a half calendar years. A year or so of that was leading engagements with one particular enormous and highly dysfunctional retail bank. Every week, we tried to demonstrate that a better world was possible, and every week, they remained resolutely stuck in their world of suffering and not delivering software. Some time after i left, i asked after that client. Apparently their organisation is agile, the projects shipped successfully, and they're really happy. I have no idea how that happened. I'd love to think that i was making a difference and just not seeing it because i was stuck at the coalface, but it's probably just that people much better than me got involved after i left!
- jacques_chester 6y ago
  Ah yes, the banks. By far our hardest clients. I think we took on too many bank engagements.
  - dajohnson89 6y ago
    what about banks make them so difficult to work with?
    - jacques_chester 6y ago
      It's a mix of things. The biggest is that they're just enormous, so nearly every engagement is pretty much from scratch. As in: single departments of single divisions could dwarf us in headcount and revenue. It can be dispiriting for Labs consultants and I know people who quit because of it. A lot of the time you hit what I call "veto culture". You are forever running into groups, committees, boards, bureaus, offices of the whatever etc etc who have the power to gate some change. Those folks almost always say "no". The logic is simple: if they say "yes", and something goes wrong, and they are blamed for it, then they might lose their job or at least risk a bonus or promotion. But if they say "no", there's no risk to them. In practice it drives everything productive underground. We often relied on discovering the nomenklatura who actually did things as we went. The parallels to the USSR's experiences (as I understand them) were fascinating. It's important to note that I don't see any of this as being a deliberate outcome. In general folks don't wake up and ask "how can I make my company less productive and pleasant today?". People do what makes sense to them, based on their experiences. But I have seen how culture can drift into a bad place that's hard to dig out. Big banks seem to have even more of this than regular megacorps. I know some folks who worked in the Federal sector had some similar experiences, but overall it seems like a lot of the time it seemed more manageable due to different incentives. In fact a lot of the compliance / standards folks were often thrilled that someone wanted to talk to them.

dionian 6y ago

I agree with you and i also see the flip side of this: people who think you need to do 100% of XP techniques to be 100% XP. Whereas XP is supposed to be about doing what's right for the situation

urbanetrellis 6y ago
I would argue it's doing what's right for the situation but with a few top level goals that should constantly be in view. - Simplicity: you should be creating simple designs / solutions - Feedback: you should be getting continuous feedback as to whether what you're doing is working and self-correcting - Courage/Communication/Respect: you should be fostering a collaborative environment where people feel free to tell the truth and feel they're respected as people and professionals The practices (pairing, TDD, etc.) are just a way of getting to those goals. You can follow any other disciplines you want, but if the end result doesn't look like what I just described (or if it isn't the explicit goal of your activities) then I don't think you're doing XP.
mikekchar 6y ago
The 12 practices of XP are not XP any more than a finger is not the thing that it is pointing to. XP is intended to be a minimal set of practices that generate a method. Rather than specify a method (which will dependent upon circumstances), XP specifies a set of practices which will hopefully help you discover the method. Having said that, if you are not doing the 12 practices, then you are not doing XP. You are doing something else. It's totally fine to do something else, but it is not XP. It may have been inspired by XP. That's also really great. But it is not XP. This is important because people talk about their experiences with XP and it is difficult to determine if their success (or lack thereof) is actually due to XP, or other factors. Do the 12 practices actually generate a method? Does it happen all the time? Is there something you have to do to get it to generate the method? Is the method always the same? There are many, many question. For most people, those questions are boring because they are not actually interested in XP. They are interested in being successful on the projects. This is a very understandable position to be in! However, it is frustrating for people who are interested in XP ;-)

hinkley 6y ago

XP (and most Agile Manifesto children) proscribes a bunch of onerous activities in favor of a set of less onerous activities, but people aren't looking for discipline, they're looking for ways to avoid pain. While discussing the failings of XP as practiced, someone put it this way: You are effectively telling people that if they eat their vegetables they can have dessert, and what happens is people eat their dessert and don't want to eat their vegetables.

karatestomp 6y ago

> Really awesome Practice A (skipping up-front requirements development, shorter QA cycles) is made possible by really tedious Practice B (pair programming, TDD). School/district administrators do the same thing. "Hey I just read [popular education book about some system] and got the district to pay for me to go to a conference about it and it seems great! We're doing that now. Oh but not that part. Or that other one. Those make me uncomfortable." [two years pass] "Huh, weird, none of this is working for us, guess the book sucks. Hey, I just read this other book...."

skillfulpurple 6y ago
This is unfortunately common in management. Ideas are easy and exciting; execution is difficult and requires sacrifice & discipline. Human beings love to enjoy the benefits of thinking pretty thoughts without the actual cost of action.

mpweiher 6y ago

> with B players or a team with existing dysfunctions. Hmm...I got handed a team of C players. By focusing on the technical aspects of XP such as simple code, test first, quick turnaround (work on master, check in when green) the team was outperforming the "star" team(s) after about a year or two. We paired only on a need basis, but I wouldn't say that we failed.

wtracy 6y ago
I would love to see a detailed retrospective on your experience.

donw 6y ago

> If you try to cherry pick the obvious shiny stuff while skipping the slow/expensive less-obvious things, you are doomed to fail. This is true with everything in life that you seek to do well: cooking, dancing, etc. > Really awesome Practice A (skipping up-front requirements development, shorter QA cycles) is made possible by really tedious Practice B (pair programming, TDD). A big nit: you don't exactly "skip up-front requirements development". First, the appetizer: One of the things you actively seek to avoid in an XP team is blocking: having people sitting around, doing nothing, because they are waiting for other teams/roles to hand them something. Another thing you want to avoid is building things that are not needed, wanted, or required by either you or your customers. Finally, customers are going to change their minds, and you can come to them with one of two answers, either, "we can't do that, it's not in the plan"; or, "sure, we can change direction". Now, the meaty goodness: You absolutely do market research, and probably have designers doing various types of prototype testing with Real Live Users (Or At Least Their Proxies) before you kick off any serious engineering work. This will yield a pile of low-fidelity prototypes, assumptions to validate, and a tentative roadmap upon which your whole team (Product, Design, and Engineering) can begin execution. You absolutely should have plans that stretch into the future, but the farther out those plans go, the lower their fidelity should be, because you are almost certain to change those plans as you build, experiment, and learn.

mikekchar 6y ago
> Finally, customers are going to change their minds There is actually a type of orgnaisation that does not change their mind. They have a vague idea upfront what they want. They ask for a plan and an estimate. They never actually think about what they want in detail. When the thing is delivered, if nothing goes wrong, nobody looks at it or thinks about it. If anything goes wrong, then they say, "You didn't deliver what I asked for" (a vague idea that doesn't break things ;-) ). The biggest problem I've had with some groups is convincing them that changing their minds is actually crucial to the success of the project. It's funny because you'll have a whole bunch of other people who are trying to cover their asses by getting management to sign off on the plan, etc, etc. But I'm coming in and saying, "I want you to change your mind" because then they have to have a mind in the first place. It's surprisingly challenging. I find that if I don't succeed in that, then it's pretty difficult to succeed with an XP team.