The difference between Scrum and XP

We had a small discussion at work a few days ago about the difference between Scrum and Extreme Programming (XP).

My take on the distinction is that Scrum is essentially a management technique, while XP is essentially a development technique. They certainly have a lot of overlap, but the different emphasis leads to some different recommendations. There’s no “40 hour week” in Scrum, for example.

Jason Yip contends that Scrum stops where actual development work starts.

For interest, a while ago I reviewed both the original book on Scrum and a clutch of XP books for the Java Ranch “bunkhouse”.

Agile and Offshore: Asking for Trouble?

Another post that resonates with our current working situation.There have been several attempts to make use of offshore software development in our company, and we are involved in one right now. The contrast between our “on-shore” agile, iterative, TDD, frequent check-in process and the approach used by our off-shore partners is very sharp.

InfoQ: Agile and Offshore: Asking for Trouble?

Should the Daily Standup Be Person-by-Person or Story-by-Story?

Mike Cohn raises an interesting and topical issue about how to indicate what you are working on at a daily stand-up meeting.

In our project we are currently working on an iteration where all the stories overlap and interact. Our usual approach is that each developer grabs a story and works on it until its done, then repeats until either the iteration ends or we run out of scheduled stories. In this case we need something a little smarter – some way of grouping the tasks for the iteration, regardless of which stories they “belong” to, so that developers can work on a chunk of related functionality rather than a story as such.

This is potentially risky, as some of the commenters on the above post point out, but at the moment I can’t see a way around the problem.

Should the Daily Standup Be Person-by-Person or Story-by-Story? | Mike Cohn’s Blog – Succeeding With Agile™

Automated story-based acceptance tests lead to unmaintainable systems

A fascinating counterpoint to Gojko Adzic‘s writings on acceptance testing in an agile process.

thekua.com@work » Automated story-based acceptance tests lead to unmaintainable systems

Update: here’s some more discussion on this topic, and how it is affected by the nature of user stories

User Stories are Just Schedulable Change

Pair Programming: What do we gain from it?

pair programming is often one of the hardest things to “sell” when implementing XP or an XP style approach to development. Mark Needham has written a nice summary of some reasons for choosing pair programming.

Pair Programming: What do we gain from it? at Mark Needham

Software testing on an agile project: How to get started

An article with some good tips on avoiding a clash of cultures between developers and testers on an agile project. (note, there may be a click-through ad on this link)

Software testing on an agile project: How to get started

Can Authors Use Agile Methods?

From time to time I toy with the idea of writing a book. One of the things which has put me off is the whole “big project” nature of the task. I am so used to test-driven, small-iteration, early-value working that slogging away for six months or a year on a single task seems particularly daunting.

An interesting possible solution to this is the idea of writing in an agile manner.

InfoQ: Can Authors Use Agile Methods?

When Working Software Is Not Enough: A Story of Project Failure

As we continue to slog onward trying to ease our overall product process into something more agile, adaptable and effective, we continually run into roadblocks. Typically these are legacy process issues, such as an existing “finger in the air” customer commitment suddenly appearing to bypass all the carefully structured estimation and prioritisation. Although irritating, this kind of problem is at least visible. Stakeholders can get into a shouting match with each other and come to some sort of decision.

Sometimes, however, the problems are out of our control. These are the tough ones. The following InfoQ article describe just such a situation, and serves as a cautionary tale for everyone involved in this kind of effort.

InfoQ: Presentation: When Working Software Is Not Enough: A Story of Project Failure

What to Do with Left Over Stories

Back to thinking about stories in the agile software development sense.

For the first time this iteration we have reached a situation where two stories were left incomplete at the end of the iteration. I could give a bunch of excuses about changing priorities during the iteration, but the point is that agile processes are supposed to be able to cope with this kind of stuff.

So now we are at the point of deciding what to do with these stories. Luckily, the guys at Elegant Code are also facing this problem, and discuss some options in a recent blog post.

Elegant Code » What to Do with Left Over Stories

In our case, the discussion is still proceeding. From an agile purity point of view the suggested approach of throwing the part-completed stories back into the pot for re-estimation, re-prioritisation, and re-scheduling is certainly compelling.

Fitting agile acceptance testing into the development process

It seems a comon problem. One of the first steps in implementing an agile process (such as scrum) is to put in place a fixed iteration cycle in development, but but then find difficulties fitting post-development testing (a.k.a “system testing” or “integration”) into the mix.

The main problem with testing after development is that any fixes to problems identified in the follow-on testing have a tendency to become tangled in upcoming work for the next iteration. This in turn can lead to no iteration ever being “clean” enough to actually release.

One possibility for a solution is to reconsider the development-led nature of an iteration, and instead lead it from a set of acceptance tests which are estimated, developed and executed alongside the scheduling and implementation of code changes.

Gojko Adzic, one of my current favourite bloggers on the subject of testing, has attempted to map out an iteration structure which incorporates this approach:

Gojko Adzic » Fitting agile acceptance testing into the development process

Planning using post-its and spreadsheets

A short article about planning and organising a project using post-its and/or a spreadsheet to associate tasks with phases. The interesting thing about this article for me is the explicit mention that the process is cyclic and iterative, rather than linear. Tasks are expected to move around the phases in a variety of directions, and special “evaluation” phases are provided as stopping points between other parts of the process.

Planning

Lego Is Not Just For Kids Anymore

Well. I already know (or maybe “hoped” is a better word) that Lego is not just for kids. But any article about both Lego and agile software development was bound to catch my attention.

This article is about the idea of using Lego bricks for time tracking and bug prioritisation/organisation. Personally I think the suggested use for time tracking is the better of the two, but the whole article opens up another avenue of using everyday objects to improve the process and environment of work.

InfoQ: Lego Is Not Just For Kids Anymore

…Now I just have to convince the hard-nosed company finance boss to invest in a bucket of Lego bricks :)

We Vouch For…

This is really interesting – an attempt to use the techniques of social networking to sidestep the problems of questionable certifications for finding out about real skills and capabilities of people involved in agile software development.

We Vouch For…

If you sign up, and you have evidence of my skills and abilities, feel free to vouch for me :)

Why would I want to sit with that bunch of nutters?

A nice article about the potential benefits of colocated working.

AGILE IN ACTION: Why would I want to sit with that bunch of nutters?

Bulding smart teams

An interesting article, apparently based largely on the keynote from Agile 2008. Some clever stuff about estimation, averages, and the wisdom of crowds in the context of software development teams.

Gojko Adzic » Bulding smart teams

Joshua Kerievsky about Industrial XP

At the moment, the company I work for is pressing forward on implementing an end-to-end agile approach to software production. With this in mind, I was intrigued to see an interview with someone who runs a company offering consulting and training in just this area, which they refer to as “industrial XP”. I found plenty of thought-provoking ideas in there.

InfoQ: Joshua Kerievsky about Industrial XP

Experiments in Agile Estimation: Planning Poker

Estimation for agile processes is a bit of an odd duck. One the one hand it needs to be done before work starts, but on the other hand, the more such stuff is done before work starts, the less agile the process becomes. To overcome this apparent contradiction, several people have tried to devise more “agile” ways of estimating work.

One of these approaches is Planning Poker. See also AGILE IN ACTION: XPDAY2006: Experiments in Agile Estimation

Agile Acceptance Testing

This looks interesting. The role of testing (at least, testing beyond unit-level regression testing and TDD) is the subject of much discussion in software development at the moment. Maybe I should actually attend this talk at Skills Matter in London on 18 September.

In The Brain of Gojko Adzic: Agile Acceptance Testing

Lasse’s weblog – Another Agile 2008 quote

This one made me laugh out loud.

Q: What do you call requirements that are not executable?
A: Specifiction.

via Lasse’s weblog – Another Agile 2008 quote

The Agile Coach Role

I’ve never worked on a team with an explicit Agile Coach – I know several people who have worked in that role, just never with me.

With that in mind, this article is an interesting exploration of what the role of “agile coach” actually entails.

thekua.com@work » The Agile Coach Role