XP or Scrum, Either, Both, or Neither?

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 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:

• Estimates will never be accurate enough, programmers are expensive, and must be highly utilized, therefore scope must be variable. All agile methods solves this by replacing scope definition and control with value optimization, in the form of an adaptively prioritized list of software capabilities.


• Requirements conversations and valuation will always be error-prone, therefore feedback loops must be tight and clear. All agile methods solve this with frequent delivery of finished software.


• Software design rots over time, therefore there must be a cost-effective way of controlling technical debt. Here's where XP prescribes TDD, pairing, and refactoring, and Scrum leaves it up to the team.

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.

Scrum itself doesn't provide practices for achieving a flat cost of change. The feedback from a lack of flat cost of change can arrive too slowly to be spotted in retrospectives, and teams often lack the chance to catch up on any technical debt they produce in the early days.

XP provides some practices which flatten the cost of change. There are other toolsets that do a similar job. Velocity and estimation, though, need something like XP to be useful over the long term.