Comments on: Differences Between Scrum and Extreme Programming http://blog.mountaingoatsoftware.com/differences-between-scrum-and-extreme-programming Succeeding With Agile® Fri, 10 Feb 2012 03:51:54 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Mike Cohn http://blog.mountaingoatsoftware.com/differences-between-scrum-and-extreme-programming/comment-page-1#comment-134996 Mike Cohn Sun, 16 Jan 2011 03:06:38 +0000 http://blog.mountaingoatsoftware.com/?p=8#comment-134996 Nicky-- I answered your question about which type of projects are most appropriate for agile in this post: http://blog.mountaingoatsoftware.com/deciding-what-kind-of-projects-are-most-suited-for-agile Nicky–
I answered your question about which type of projects are most appropriate for agile in this post:
http://blog.mountaingoatsoftware.com/deciding-what-kind-of-projects-are-most-suited-for-agile

]]> By: Mike Cohn http://blog.mountaingoatsoftware.com/differences-between-scrum-and-extreme-programming/comment-page-1#comment-131170 Mike Cohn Wed, 05 Jan 2011 17:55:35 +0000 http://blog.mountaingoatsoftware.com/?p=8#comment-131170 Hi Alexis-- I have not seen a significant difference between teams that start with XP or Scrum in which continue on to continuous improvement. Too many of both types of teams get complacent after a first round of improvements and stop. I suspect the reason that XP teams you've been on continued to improve is because those teams had you and perhaps others like you who cared enough to continue to improving. Quite seriously, the fact that you read and comment on an agile-oriented blog probably puts in the top 1-2% of people passionate about what they do. A person or two like that on a team makes a huge difference. It's also why I don't see as much ScrumBut as I hear about. A team that calls me in to consult must have someone around who cares about improvements so they are less likely than the average to be doing ScrumBut. (They're likely doing ScrumWithStruggles but that's different from a team that rationalizes away the hard parts as is the key factor in making a team ScrumBut.) Hi Alexis–
I have not seen a significant difference between teams that start with XP or Scrum in which continue on to continuous improvement. Too many of both types of teams get complacent after a first round of improvements and stop. I suspect the reason that XP teams you’ve been on continued to improve is because those teams had you and perhaps others like you who cared enough to continue to improving. Quite seriously, the fact that you read and comment on an agile-oriented blog probably puts in the top 1-2% of people passionate about what they do. A person or two like that on a team makes a huge difference. It’s also why I don’t see as much ScrumBut as I hear about. A team that calls me in to consult must have someone around who cares about improvements so they are less likely than the average to be doing ScrumBut. (They’re likely doing ScrumWithStruggles but that’s different from a team that rationalizes away the hard parts as is the key factor in making a team ScrumBut.)

]]> By: Alexis La Joie http://blog.mountaingoatsoftware.com/differences-between-scrum-and-extreme-programming/comment-page-1#comment-131143 Alexis La Joie Wed, 05 Jan 2011 16:04:19 +0000 http://blog.mountaingoatsoftware.com/?p=8#comment-131143 Mike, it is interesting how much diversity there still is in the market. I am glad to hear development teams using adopting Scrum to communicate well with management. My experience has differed, but I see your point. I guess I am also looking more primordially at each. It has been my understanding that XP evolved from developer best practices and then became a dogma. Scrum specifically omitted development practices because it wanted to avoid the pitfall you described and also be more management friendly/focused. If XP evolved from a dev team/teams who was formalizing their best practices, it would not be difficult for the typical developer mindset to say... this works... use it - otherwise it doesn't. This 'might' account for some of the dogma in the XP realm - the nature of the players. At the same time, the successful XP teams I have been on started as XP-Lite (or some other similar euphemism). The part they got right and allowed them to succeed was the feedback loops and introspection/retrospection. They took refactoring their practice seriously. While they initially did not see need for all of XP, by the time they were into it for a while, their own candid reflections led them to full adoption over time. I have seen similar starts on the Scrum side (where they call their implementations Scrum-but). For some reason, these lukewarm Scrum implementations never see full Scrum adoption the way the XP teams did. I have some theories as to why, but am not sure if they are universally applicable. I would love to hear your thoughts. Mike,
it is interesting how much diversity there still is in the market. I am glad to hear development teams using adopting Scrum to communicate well with management. My experience has differed, but I see your point. I guess I am also looking more primordially at each. It has been my understanding that XP evolved from developer best practices and then became a dogma. Scrum specifically omitted development practices because it wanted to avoid the pitfall you described and also be more management friendly/focused. If XP evolved from a dev team/teams who was formalizing their best practices, it would not be difficult for the typical developer mindset to say… this works… use it – otherwise it doesn’t. This ‘might’ account for some of the dogma in the XP realm – the nature of the players. At the same time, the successful XP teams I have been on started as XP-Lite (or some other similar euphemism). The part they got right and allowed them to succeed was the feedback loops and introspection/retrospection. They took refactoring their practice seriously. While they initially did not see need for all of XP, by the time they were into it for a while, their own candid reflections led them to full adoption over time. I have seen similar starts on the Scrum side (where they call their implementations Scrum-but). For some reason, these lukewarm Scrum implementations never see full Scrum adoption the way the XP teams did. I have some theories as to why, but am not sure if they are universally applicable. I would love to hear your thoughts.

]]> By: Mike Cohn http://blog.mountaingoatsoftware.com/differences-between-scrum-and-extreme-programming/comment-page-1#comment-130718 Mike Cohn Tue, 04 Jan 2011 15:43:49 +0000 http://blog.mountaingoatsoftware.com/?p=8#comment-130718 Hi Alexis-- I can largely agree but with a couple of notable exceptions. I rarely see Scrum being "imposed as a management tool." Probably 3/4ths of the Scrum implementations I get involved with were started by developers who were looking for ways to get more done. They then solicited management's support in doing Scrum. Since Scrum is somewhat management-friendly, the developers were successful in getting this support. I'm also not sure about the idea that XP requires management to "let development teams struggle and develop best practices which work for them." XP is pretty clear about which "best practices" to start with. In fact, the early days of XP required a team to do all 12 practices or they "weren't doing XP." This has always struck me as the big anomaly in XP: XP says to a team, "We trust you to solve this business problem but hey, here are 12 technical practices you must do." It always seems a little backward to trust a team to solve a business problem yet tell them the practices to follow even though the team members have solid technical backgrounds. By the way, I should add that I have no particular bias between these processes. Visit a team I coach and wear some headphones while you're there and you won't know if they are doing Scrum or XP. You'll see Scrum things like burndown charts and a person who seems to be protecting the team. But you'll also see pairing, test-driven development, continuous integration, etc. (Why the headphones? Because you will hear all the weird Scrum vocabulary from the teams I coach.) Thanks for your comment. Hi Alexis–
I can largely agree but with a couple of notable exceptions. I rarely see Scrum being “imposed as a management tool.” Probably 3/4ths of the Scrum implementations I get involved with were started by developers who were looking for ways to get more done. They then solicited management’s support in doing Scrum. Since Scrum is somewhat management-friendly, the developers were successful in getting this support.

I’m also not sure about the idea that XP requires management to “let development teams struggle and develop best practices which work for them.” XP is pretty clear about which “best practices” to start with. In fact, the early days of XP required a team to do all 12 practices or they “weren’t doing XP.” This has always struck me as the big anomaly in XP: XP says to a team, “We trust you to solve this business problem but hey, here are 12 technical practices you must do.” It always seems a little backward to trust a team to solve a business problem yet tell them the practices to follow even though the team members have solid technical backgrounds.

By the way, I should add that I have no particular bias between these processes. Visit a team I coach and wear some headphones while you’re there and you won’t know if they are doing Scrum or XP. You’ll see Scrum things like burndown charts and a person who seems to be protecting the team. But you’ll also see pairing, test-driven development, continuous integration, etc. (Why the headphones? Because you will hear all the weird Scrum vocabulary from the teams I coach.)

Thanks for your comment.

]]> By: Alexis La Joie http://blog.mountaingoatsoftware.com/differences-between-scrum-and-extreme-programming/comment-page-1#comment-130715 Alexis La Joie Tue, 04 Jan 2011 15:34:33 +0000 http://blog.mountaingoatsoftware.com/?p=8#comment-130715 Your last point about wanting to allow XP practices to develop on their own, intrigued me. It seems that XP and Scrum approach the development team from opposite ends of the spectrum. Scrum is imposed as a management tool by management on the team, while XP emerges from introspective development teams seeking to improve their practice. Both require bravery and a leap of faith to get the most out of them. XP requires management who is open to letting the development teams struggle and develop best practices which work for them. That can require a great deal of bravery from a manager who has pressure to show continuous productivity. At the same time, Scrum being imposed from above requires development teams to be brave enough to trust that the management using Scrum will allow them to be introspective enough to explore improving their process. Another way of putting it: XP starts with developers trying to improve the quality and efficiency of their work and then requires management to figure out how to harness the teams productivity, while Scrum starts with a management initiative and leads to developers trying to find ways to improve their quality and efficiency within the particular Scrum implementation. Your last point about wanting to allow XP practices to develop on their own, intrigued me. It seems that XP and Scrum approach the development team from opposite ends of the spectrum. Scrum is imposed as a management tool by management on the team, while XP emerges from introspective development teams seeking to improve their practice. Both require bravery and a leap of faith to get the most out of them. XP requires management who is open to letting the development teams struggle and develop best practices which work for them. That can require a great deal of bravery from a manager who has pressure to show continuous productivity. At the same time, Scrum being imposed from above requires development teams to be brave enough to trust that the management using Scrum will allow them to be introspective enough to explore improving their process. Another way of putting it: XP starts with developers trying to improve the quality and efficiency of their work and then requires management to figure out how to harness the teams productivity, while Scrum starts with a management initiative and leads to developers trying to find ways to improve their quality and efficiency within the particular Scrum implementation.

]]> By: Nicky http://blog.mountaingoatsoftware.com/differences-between-scrum-and-extreme-programming/comment-page-1#comment-128481 Nicky Wed, 29 Dec 2010 05:26:16 +0000 http://blog.mountaingoatsoftware.com/?p=8#comment-128481 hi Mike, thanks for your information, I'm looking forward to read your new blog post. thanks Nicky hi Mike,

thanks for your information, I’m looking forward to read your new blog post.

thanks
Nicky

]]> By: Mike Cohn http://blog.mountaingoatsoftware.com/differences-between-scrum-and-extreme-programming/comment-page-1#comment-126843 Mike Cohn Fri, 24 Dec 2010 16:33:50 +0000 http://blog.mountaingoatsoftware.com/?p=8#comment-126843 Hi Nicky-- That's a bit offtopic for the title of this blog post but I am planning next week to write something for an early January blog post. I'll write a new blog post on that topic. Thanks. Hi Nicky–
That’s a bit offtopic for the title of this blog post but I am planning next week to write something for an early January blog post. I’ll write a new blog post on that topic. Thanks.

]]> By: Nicky http://blog.mountaingoatsoftware.com/differences-between-scrum-and-extreme-programming/comment-page-1#comment-126748 Nicky Fri, 24 Dec 2010 08:36:29 +0000 http://blog.mountaingoatsoftware.com/?p=8#comment-126748 Mike, what kind of project do you think more worth/or fit to use Agile development process? thanks Nicky Mike,
what kind of project do you think more worth/or fit to use Agile development process?

thanks
Nicky

]]> By: Mike Cohn http://blog.mountaingoatsoftware.com/differences-between-scrum-and-extreme-programming/comment-page-1#comment-125490 Mike Cohn Mon, 20 Dec 2010 20:43:15 +0000 http://blog.mountaingoatsoftware.com/?p=8#comment-125490 Hi Chris-- That's an interesting question but I haven't seen any studies done addressing that specifically. It would be an interesting pursuit for an academic. Hopefully one picks up the topic. Hi Chris–
That’s an interesting question but I haven’t seen any studies done addressing that specifically. It would be an interesting pursuit for an academic. Hopefully one picks up the topic.

]]> By: clewis http://blog.mountaingoatsoftware.com/differences-between-scrum-and-extreme-programming/comment-page-1#comment-125485 clewis Mon, 20 Dec 2010 20:36:56 +0000 http://blog.mountaingoatsoftware.com/?p=8#comment-125485 I am curious if there are differences in quality between scrum and xp. scrum doens't mandate or give guideliness around code coverage and refactoring whereas xp does. i think in both the collaborative nature of the design is good in that there is strong buy in and (hopefully) consistent patterns and practices but doesn't speak to the possibility that no one might have strong design/architecture skills. there are many code monkeys that produce stellar code given a few parameters but ask them to architect a scalable system and they are in over their head. [btw - mean no disrespect in that regard because there is a ton of value these folks bring.] I am curious if there are differences in quality between scrum and xp. scrum doens’t mandate or give guideliness around code coverage and refactoring whereas xp does. i think in both the collaborative nature of the design is good in that there is strong buy in and (hopefully) consistent patterns and practices but doesn’t speak to the possibility that no one might have strong design/architecture skills. there are many code monkeys that produce stellar code given a few parameters but ask them to architect a scalable system and they are in over their head. [btw - mean no disrespect in that regard because there is a ton of value these folks bring.]

]]>