Two good videos

Monday was a bank holiday, so I found a little time to catch up with some of the web videos in my queue.

First I watched an inspiring session from TechCrunch Nordic which likens achieving an “exit” for a startup company to dating. Fun, and with a strand of truth.

TechCrunch Nordic – Tommy Ahlers from Mike Butcher on Vimeo.

Anyone running a startup, or thinking about it, should watch this one.

Second I watched a presentation ostensibly about Kanban and “single piece flow”, but really about much wider issues in planning and managing software development. I found the approach presented particularly interesting as it correlates very well with where my thoughts are at right now.

This video is best watched at infoq, to see both the presenters and the slides

Anyone working in software development, or managing a software project really needs to watch this one.

Pair programming with multiple mouse pointers and keyboard foci

On the one hand this looks like a neat technology. On the other hand it could be more “extreme”.

Cuberick: Pair programming with multiple mouse pointers and keyboard foci

Sure. It removes the bottleneck of fighting for control of a single keyboard and mouse, but there is still only a single screen. So why not use a version of this where each user also gets their own screen. It’s easy, familiar and cheap and works with any operating system – it’s called a separate computer.

While this may seem sarcastic, my point is really that one of the key reasons pair programming works is that it allows each partner to take different a role. While one is “driving” and concerned with the details of keyboard and mouse the other is free to consider larger issues.

I may be wrong, but it seems that allowing both to drive loses that benefit, and plunges both partners into the fiddly world of move, click and type.

The problem with Scrum

A pleasantly witty yet insightful post about how different processes and methodologies can suffer similar problems, and how this relates to the individual learning journeys of practitioners.

lizkeogh.com » The problem with Scrum

Pair Programming: Pair Flow

Pair programming can be one of the hardest things to get right when attempting Extreme Programming (XP). It’s very common to give it a try and quickly find a whole bunch of problems. Mark Needham has written a thoughtful article full of tips on making pairing work. Well wortha read even if you don’t do it (much) yourself.

Pair Programming: Pair Flow at Mark Needham

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

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

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

The Simplest Thing That Could Possibly Work

A continual source of discussion is the XP/agile admonition to do “the simplest thing that could possibly work”. What is simple? How do you know it could work until it is done? What if part-way through you spot a “simpler” solution? “simpler” for who? And what does “simple” mean, anyway!!

Here’s an article which looks at this old chestnut from the point of emphasis – is it the “simplest” or the “possibly” which should carry the most weight?

Jay Fields’ Thoughts: The Simplest Thing That Could Possibly Work

Another commentary on the same article from Ian Robinson can be found at The Simplest Thing That Could Possibly Work :: iansrobinson.com

Ways to split user stories

Constructing sensible and effective user stories is a vital and sometimes surprisingly tricky part of XP-style agile software development. There are plenty of ways to choose a less than optimal story breakdown.

Lasse Koskela has put together a thoughtful blog post about this topic.

Lasse’s weblog – Ways to split user stories

InfoQ: Does Sustainable Pace mean a 40 hour week?

The Extreme Programming practice of “40 hour week” (a.k.a “sustainable pace”) is always one to provoke argument. Here’s a summary of some discussion at infoq:

InfoQ: Does Sustainable Pace mean a 40 hour week?

InformIT: Interview with Donald Knuth

the idea of immediate compilation and “unit tests” appeals to me only rarely, when I’m feeling my way in a totally unknown environment and need feedback about what works and what doesn’t. Otherwise, lots of time is wasted on activities that I simply never need to perform or even think about. Nothing needs to be “mocked up.”

That’s just a provocative snippet, of course. The article ranges much wider than that, and contains a lot of interesting stuff from one of the giants of software engineering.

Read the whole article at InformIT: Interview with Donald Knuth