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”.
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?
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™
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
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
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?
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
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.
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
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
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 
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
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
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
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
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
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
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