Tracking change and innovation in the enterprise software development community
QCon London 2010!
March 10-12, 100
Speakers, 80 sessions,
"THE" team leads and,
architects conference.
Free Book Offer
SOA Demystified
$40 Value
Scaling Scrum
in the enterprise?
ScrumWorks Pro
can help.
Start a trial today
Posted by Amr Elssamadisy on Oct 26, 2009
Which is better? Scrum or XP? Is there one that is more applicable than the other or is there another alternative?
Tobias Mayer recently wrote on his blog Don't Do XP:
I am beginning to grow weary of the repeated discussions with the many who insist that Scrum doesn’t work without XP. Scrum works just fine — if applied with an understanding of the values and principles that are at its foundation. The context you implement Scrum in will determine the practices you need to apply. Scrum in Church will have a different set of good practices to Scrum in Software, and both will be different to Legal Scrum.
XP advocates are quick to blame Scrum for the lack of good development practices in the software industry. But given the very slow uptake of XP it could be argued (and I shall do so) that in fact XP itself is responsible for the lack of good practice in our industry.
It seems what Tobias is saying is that Scrum is enough to "pull" (in the Lean sense) the necessary technical practices and that does not require all of XP. XP is too much of a burden and it's lack of adoption is proof of that.
Steve Freeman responded to Tobias' post in Do do XP:
As an occasional XP advocate, I don’t “blame Scrum for the lack of good development practices in the software industry”, I blame the software industry. If we worked in an effective industry, we wouldn’t be having methodology wars because things would just work. Now this same industry is messing up Scrum too by just taking on its ceremonial aspects. On the other hand, to blame XP for blocking good practice is just bizarre.
XP is a tiny movement that attracted some attention. What XP (version 1) did achieve was to show that it is possible to break through the logjam of cautious procrastination that still cripples many development teams, but without resorting to hackery. It gave teams a reliable package of practices that just worked. Of course XP didn’t take over the world because it’s not suitable for everyone–not least because it requires a degree of focus and skill that is not appropriate for many teams. Kent Beck’s presentation of XP version 1 was extreme on purpose: it was designed to inspire us huddled masses, and to stretch the boundaries of what was considered possible in software development, to reframe the discussion.
Steve goes on to say that XP had much to do with the current emergence of the craftsmanship movement:
Tobias writes that the good development practices were spreading slowly at the time, but I’d argue that without XP we’d still be waiting. Test-Driven Development is still not that widely accepted and even the original C3 team didn’t adopt it fully until Kent was writing his book. Refactoring had a small academic following, but it’s not very safe without the compensating practice of TDD. I suspect most teams still ban changing code unless it’s to change a feature. Pair programming is still a very hard sell and, again, works much better in the context of TDD. I’ve seen enough Scrum teams that have not found a coherent set of technical practices. To say that they just need to improve their Scrum implementation begs the question of how Scrum is adopted and the limits of self-organisation.
This conversation, and many others, prompted Yves Hanoulle to suggest that maybe the Agile community is going through the second of the forming/storming/norming/performing cycle:
It looks like we have a lot of discussions where we question ourselves as an industry.
I have the feeling it is the first time this happens at this scale. Maybe I’m too young. Maybe I ‘m more in the middle now or have more idea’s myself on who’s right or wrong. Maybe it’s the always connect, twitterly, blogging world that makes these discussions so more public.
This reminds me a lot of the storming phase that exists in a team live cycle,or the chaos phase in Satir's model. So from a point of view of a coach these discussions and where this goes is interesting.
In these discussions, there is clearly no leader. Or let me put it in another way, no leader that everyone would accept.
So this contention in our community might actually be just a sign of our continuing maturity. This writer has found in his experience that everything makes sense in context. There have been successful teams that started with Scrum, and others that have been successful starting with XP, and many that have failed with both. The one thing that we do well at the Agile community is learn by experimentation and not lose sight that all of these practices and processes are only a means to an end.
Learning to be a Good Product Owner: Foundation Skills
Technical Debt and Design Death
Amr, I think you have a copy & paste error with Steve Freeman's comment. I read it a couple of times, and it still looks exactly like Tobias'. :)
I see the title and content of this discussion as the problem created when people subscribe to a brand. Do it "XP" or do it "SCRUM". Without first taking on the fundamentals of Agile.
Applying Agile principles should be able to adjust SCRUM or XP to work in an environment. Following a process blindly is, as ever, unwise. Which I took as a starting point of Agile in the first place!
The argument of using Scrum rather than XP rather than whatever else is senseless. Many companies ultimately adopt a hybrid approach, using Scrum and adding XP practices such as TDD, pair programming, and refactoring. Why do you have to choose one over the other? Are any of these one size fits all? I think not. And there is no need for them to be. Take a look at your current environment and team, look at where you want to go, see how each of the Agile practices can get you there, and start going down that road. Use what works best for you and, with guidance, you can be successful.
I've been working in agile teams for over eight years now and I've only seen one implementation of what I would call "textbook" XP. All other teams were "Scrum-but" or "XP-like". And you know what? Most of these turned out just fine.
I guess I'm not upset when I hear this since I assume people are speaking about applying Scrum in a software development context. I don't presume they are talking about requiring XP when using Scrum in a Church setting, for example.
For me, the thing that is upsetting is when people suggest that, because Agile ideas came out of a software development context, they can only be applied properly in that context. So, for them "real" Agile is about software development and must address code development practices. I heard this position advocated at the Agile Roots Conference in Salt Lake City last June by some participants during discussions at the talks and over meals.
I agree completely with Jason Alcock: first understand the Agile Values and Principles. Then, the next thing to do is apply them in the context of an existing Agile method's practices and techniques. Only then "tailor" the practices and techniques.
Especially in large organizations, Agile adoption is becoming characterized by changing the practices and techniques before even trying to make them work. When I ask why, the responses are that they can't or don't need to do so given the way they currently work in the organization. The whole idea that pursuing an Agile approach is supposed to change how things work in the organization is either lost on or (implicitly) rejected by such instant "tailoring" of Agile concepts and practices.
Fixed. Sorry folks for the error :)
Geez, I haven't done something that dumb since at least yesterday. :)
While it is refreshing to hear that process are not the point and "Scrum or XP?" is the wrong question (for many years it seemed like it was the only question). I've got to think there is more to it than this.
Replace Scrum and XP with Project Management and Technical Practices, and the question is very valid? Can you do one without the other? Should you do one without the other? (I know, I know, it DEPENDS! )
Here's what I'm trying to get at, I think you generally need both. Your starting point may vary, you may start with the technical practices to build a foundation for the PM practices. Or you may start with the PM practices to create "pull" for the technical practices. But, in the end, is there a success without both in software development? (This is not a rhetorical question, I'm open to any answer.)
I think this is similar to the issue touch on when comparing Software Engineers verses any other Engineer. I think part of this is about a maturity of process.
For mechanical engineers, over the years, they had to draw things manually (now with CAD thankfully) before they could build it, make models (physical models now possible with simulated models), or use algorithmic means to test things (record data, plot it out; thankfully data collection systems make this easier as well), build protypes, then final production versions. It took time.
In CMMI circles (Capability Maturity Model Integration) for example, they have different levels of maturity. Early phases you either don't have a process or you have a basic process which may include many different process for the same activities. As you progress, you formally establish process, unify process, measure peformance of process, and improve upon process.
I think along the way we also failed to except the work necessary (learning all the language, patterns, existing frameworks, etc) looking for the easy way out. If you want safe and quality software, you have to consider aspects of safety on the performance of the software which takes time.
This extra time cost money of course so maybe some aspects of program management are good here.
I think there is some "not invented here" syndrome mixed as well.
We sometimes failed to consider the risk for doing things so quickly.
With present technologies, we have been given a great opportunity. I hope we don't loose sight of that.
Applying Agile principles should be able to adjust SCRUM or XP to work in an environment. Following a process blindly is, as ever, unwise. Which I took as a starting point of Agile in the first place!
I'm not sure that I agree. When someone is new to a thing - anything - they are not ready to make context-dependent choices. They need a step-by-step, context-free, set of things to do. Then, once they truly learn by practicing they have the experience and knowledge to make effective tailoring decisions.
There is a large number of failed projects out there started by 1) having a successful experience with Scrum or XP, and 2) anointing those team members as experts and farming them out to start their own teams within the organizations when they just do not have the experience to tailor the process.
When I worked at Intuit, we had Ken Schwaber (Scrum pioneer) come and train us for a few weeks. Ken introduced Scrum as a project management approach whereas XP is really a methodology for development. There really is no comparison and I see both frequently used together.
I agree with Yves Hanoulle that the "agile community" is going through the "storming" stage.
Agile is also crossing the chasm from early adopters to early majority. Early adopters were kind of agile to begin with, so the cultural change across the organization was easier.
But the early majority has PMOs, Governance Boards, Gated Processes, Roles as People (and an org chart that matches the waterfall phases), and a number of other toes to step on when Agile is introduced. So there's more pressure to modify whatever flavor of Agile is being introduced, and unknowingly cut through a load-bearing wall in the process. Down Agile falls, to a chorus of, "We tried that, and it didn't work," often sung by people whose cheese stood to get moved if it did.
IMO the key is understanding why agile methods work. What problems do they solve, and what are the load-bearing walls that form these solutions. Then you can mix-and-match, add whatever lipstick and holy water you need to get the essence of agile in the door, and call it whatever you want, and it will work.
Here's my suggestion for the problems, and associated load-bearing wall solutions:
So, if in order to get Agile in the door, you have to give up variable scope, frequent delivery of finished software, or measures to keep the design clean, you've cut through a load-bearing wall and it will fall down. But if you have ways of doing these things, you'll do OK, regardless of what you call them.
See The Load-Bearing Walls of the House of Agile.
I feel only SCRUM is not enough for the software development. SCRUM only focus on the management side, focus on what needs to be done. But it does not mention let developer how to do it, where is TDD, pair programming, refactoring? They are very essential to build a good quality software but missing in SCRUM. So I think using XP on develper side, SCRUM on manager side.
Brian Marick takes us through a quick tour of the most important values and challenges to adopting Agile successfully (they aren't the typical challenges and values we hear in the community).
The line between development and architecture is tricky. Does it exist at all? Is an ivory tower actually needed? There's a balance in the middle, but how do you move from developer to architect?
The word 'authority' sometimes produces an allergic response in hard-line agilists. Freedom and authority – both are bad if misused and both are good if used in right spirit for a noble cause.
"Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, and Taco Bell are all using Grails. Are you ready to get started as well?
Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. With ITIL V3, the focus of the framework shifted towards service-orientation.
SpringSource CTO Adrian Colyer discusses AspectJ, SpringSource's dm Server and tc Server products, OSGi and Scrum.
Heroku's Adam Wiggins talks about Rails, Background Jobs, Add-Ons, Ruby, and how Heroku manages to work around Ruby's inefficiencies using Erlang and other languages.
For Grady Booch the foundation of a good architecture is patterns, SOA being just one of many patterns. In this Second Life presentation, Booch attempts to bring more clarity on what architecture is.
13 comments
Watch Thread Reply