4 ms·

As someone who has never worked with XP, does XP really encourage proactively _pushing_ business context and customer POV all the time?

rramadass 7y ago
The whole XP (eXtreme Programming) movement came out of the Consulting domain. "jasim" in this thread explains the context where it makes sense. The company i had worked for had jumped on the XP bandwagon when it came out (we even had Kent Beck, originator of XP himself come out and do presentations!) but i never saw anything unique about it. It was merely a systematic way of working much more closely with the Client and doing rapid implementation iterations towards the known requirements which all experienced Engineers/Managers/Companies were already doing. Except it wasn't a dogma with them but adaptation of a sane process to a context. I always thought of XP and its successors as marketing by successful Consultants rather than any true insight. You might want to take a look at the original short book "Extreme Programming Explained" by Kent Beck and form your own opinions.
mikekchar 7y ago
I depends on who you talk to. IMHO, the most important thing is that every single story has to have "business value". In other words, it has to have something where if you put it up on a board and said, "My team did this today", anybody in the management structure would say, "That's wonderful news". I also feel that you should try to have stories that average between a day and two days in length -- so it's pretty darn tough to think of ways to meet both criteria. These days, I'm unable to due pure XP, but I often find that if I manage to build a backlog like that, then it barely matters what else I do: it's going to be successful. The main thing is that every single change needs to be vertical in nature. You are never making stories where you say, "I'm going to add this functionality to a library. Later we'll add the UI and finally, we'll add the data to the DB schema and then ship". But it means that you need to design your software quite differently in my experience. Even just from the DB level, you need to have things set up so that you can make very quick changes safely. You need to be able to change the schema, do migrations and make sure that rollouts can be done safely -- and it needs to be done on the order of an hour or so. That probably seems impossible to some people, but it's one of the reasons you can't really take a legacy project/team and say, "From today we are doing XP!" Similarly, you need to be able to make changes to your infrastructure quickly. So if you have some big set of microservices and each small change requires a signoff from some group somewhere: well, it's not really going to end well. You need to be able to make that change and get everything working end to end in hours, not days/weeks. One of the things that a lot of people have difficulty with XP is that it's generally incompatible with nailing communication specs to a wall. One day, I may need to add something to the API. The next day I need to be able to change that API. If someone comes to me and says, "You need to know everything you want this API to do for the next 3 months so that we can have a sane versioning system", I'm totally screwed. I don't know what I'm going to need next week let along 3 months (or whatever) from now. For a lot of people, this stuff is just way too different to deal with. XP comes with the subtitle, "Embrace change". It literally doesn't work unless you decide to go whole hog on it. I've been successful introducing it to some teams, but on others I don't even try. To try to answer your question a bit more closely... it's probably not what you imagine. It's not like you have people telling you how everything is going to work all the time. However, you are constantly thinking about it. Sometimes you'll have developers say, "I want to work on X" and you'll respond, "Why? How are we going to give value with that work?" And then they think about it and say, "Well, what if we altered the work flow here. That would allow us to remove this stuff. And then if we added this, it would mean that we don't need that library any more", etc, etc, etc. And instead of telling management that today "We removed some technical stuff" or "We got rid of some old libraries", we say, "We improved the workflow for the customer which enabled us to simplify the code at the same time".
- pflenker 7y ago
  I am a huge fan of attaching a "business value" to everything the team does. I also see the value (for everyone involved) to frequently collaborate and think about these things. But where the article proposes to ask all the developers for updates three times a day, I prefer the approach where the developers "pull in" their product managers when they need them, instead of the product managers "pushing" their views onto them multiple times a day. This is why I was asking - I still don't fully understand if this is a "XP thing" or not.
- repolfx 7y ago
  I don't know what I'm going to need next week let along 3 months (or whatever) from now. Doesn't this reflect some much deeper problem with the product planning or management? If you literally can't plan even a week in advance that suggests there simply is no plan, and even the most scatterbrained business environment doesn't change that fast. I'd say customers being able to stick to a coherent story about what they want for more than a week would be a key need in any successful IT project.
  - pflenker 7y ago
    Not necessarily. The idea here is that the customer has an idea about what he wants, but has only a vague idea about what he actually _needs_, and no idea about what is technologically possible. Methods like XP embrace that by allowing requirements to change over time, to account for the customer accumulating more knowledge about all three areas.
    - repolfx 7y ago
      But you can nail those things down before coding begins, just through talking with them. You don't need to literally change the code completely every week - iterating a plan is much easier than iterating a codebase!
      - afarrell 7y ago
        But with 2 weeks of coding, you can save yourself an hour of planning.

rramadass 7y ago

The whole XP (eXtreme Programming) movement came out of the Consulting domain. "jasim" in this thread explains the context where it makes sense. The company i had worked for had jumped on the XP bandwagon when it came out (we even had Kent Beck, originator of XP himself come out and do presentations!) but i never saw anything unique about it. It was merely a systematic way of working much more closely with the Client and doing rapid implementation iterations towards the known requirements which all experienced Engineers/Managers/Companies were already doing. Except it wasn't a dogma with them but adaptation of a sane process to a context. I always thought of XP and its successors as marketing by successful Consultants rather than any true insight. You might want to take a look at the original short book "Extreme Programming Explained" by Kent Beck and form your own opinions.

mikekchar 7y ago

I depends on who you talk to. IMHO, the most important thing is that every single story has to have "business value". In other words, it has to have something where if you put it up on a board and said, "My team did this today", anybody in the management structure would say, "That's wonderful news". I also feel that you should try to have stories that average between a day and two days in length -- so it's pretty darn tough to think of ways to meet both criteria. These days, I'm unable to due pure XP, but I often find that if I manage to build a backlog like that, then it barely matters what else I do: it's going to be successful. The main thing is that every single change needs to be vertical in nature. You are never making stories where you say, "I'm going to add this functionality to a library. Later we'll add the UI and finally, we'll add the data to the DB schema and then ship". But it means that you need to design your software quite differently in my experience. Even just from the DB level, you need to have things set up so that you can make very quick changes safely. You need to be able to change the schema, do migrations and make sure that rollouts can be done safely -- and it needs to be done on the order of an hour or so. That probably seems impossible to some people, but it's one of the reasons you can't really take a legacy project/team and say, "From today we are doing XP!" Similarly, you need to be able to make changes to your infrastructure quickly. So if you have some big set of microservices and each small change requires a signoff from some group somewhere: well, it's not really going to end well. You need to be able to make that change and get everything working end to end in hours, not days/weeks. One of the things that a lot of people have difficulty with XP is that it's generally incompatible with nailing communication specs to a wall. One day, I may need to add something to the API. The next day I need to be able to change that API. If someone comes to me and says, "You need to know everything you want this API to do for the next 3 months so that we can have a sane versioning system", I'm totally screwed. I don't know what I'm going to need next week let along 3 months (or whatever) from now. For a lot of people, this stuff is just way too different to deal with. XP comes with the subtitle, "Embrace change". It literally doesn't work unless you decide to go whole hog on it. I've been successful introducing it to some teams, but on others I don't even try. To try to answer your question a bit more closely... it's probably not what you imagine. It's not like you have people telling you how everything is going to work all the time. However, you are constantly thinking about it. Sometimes you'll have developers say, "I want to work on X" and you'll respond, "Why? How are we going to give value with that work?" And then they think about it and say, "Well, what if we altered the work flow here. That would allow us to remove this stuff. And then if we added this, it would mean that we don't need that library any more", etc, etc, etc. And instead of telling management that today "We removed some technical stuff" or "We got rid of some old libraries", we say, "We improved the workflow for the customer which enabled us to simplify the code at the same time".

pflenker 7y ago
I am a huge fan of attaching a "business value" to everything the team does. I also see the value (for everyone involved) to frequently collaborate and think about these things. But where the article proposes to ask all the developers for updates three times a day, I prefer the approach where the developers "pull in" their product managers when they need them, instead of the product managers "pushing" their views onto them multiple times a day. This is why I was asking - I still don't fully understand if this is a "XP thing" or not.
repolfx 7y ago
I don't know what I'm going to need next week let along 3 months (or whatever) from now. Doesn't this reflect some much deeper problem with the product planning or management? If you literally can't plan even a week in advance that suggests there simply is no plan, and even the most scatterbrained business environment doesn't change that fast. I'd say customers being able to stick to a coherent story about what they want for more than a week would be a key need in any successful IT project.
- pflenker 7y ago
  Not necessarily. The idea here is that the customer has an idea about what he wants, but has only a vague idea about what he actually _needs_, and no idea about what is technologically possible. Methods like XP embrace that by allowing requirements to change over time, to account for the customer accumulating more knowledge about all three areas.
  - repolfx 7y ago
    But you can nail those things down before coding begins, just through talking with them. You don't need to literally change the code completely every week - iterating a plan is much easier than iterating a codebase!
    - afarrell 7y ago
      But with 2 weeks of coding, you can save yourself an hour of planning.