This is my summary of Niclas Nilsson and Hans Brattberg’s “The Pair Programming Show”, a session I attended at ScanDevConf 2010. Please understand that, except for the notes at the top and bottom, this post reflects the opinions of the speaker, not me.

This session was a live play showing pair programming in action – done right, and done wrong.

My opinion: Fun and relatively well done, but pretty basic stuff. The only thing it gave me was a reminder of the different roles that the two people in a pair should have. One to focus on the small, immediate stuff; the other to focus on the bigger picture – Are we doing the right thing? Are we doing it right? Could we do something else?

This is my summary of Udi Dahan’s “Intentions and Interfaces”, a session I attended at ScanDevConf 2010. Please understand that, except for the notes at the top and bottom, this post reflects the opinions of the speaker, not me.

A core design pattern: intentional interfaces. Whenever you find yourself facing a design problem, tell yourself – “Make roles explicit”.

For example, a Customer class may be used to validate a customer before persisting it, for making customers preferred, and for adding orders to the customer. Making these roles explicit, the Customer class would implement IValidator<Customer>, IMakeCustomersPreferred, and IAddOrders. Now that these are in place, we may use them, for example, to implement different fetching strategies for #2 and #3 – lazy vs eager.

Another example: there might be a CustomerService class for those same three tasks. Separating out the three responsibilities, the class might implement IMessageHandler<ChangeAddressMsg>, IMessageHandler<AddOrderMsg> and IMessageHandler<MakePreferredMsg>. Now that this is explicit, we may split this into three different classes, which would (among other things) allow us to have several handlers for a single message, in a pipeline.

As a rule of thumb, define your interfaces starting from use cases. These tend to be a stable foundation to build on.

Often we think one interface – many implementations. With this pattern it’s the opposite: one implementation, many interfaces.

My opinion: This session is difficult to summarize without all the examples and step-by-step reasoning, so I’m afraid the blog post won’t do it justice. I found it useful, and the reminder to Make Rules Explicit will probably lead to better design with less sprawling classes in our code.

This is my summary of Chris Hedgate’s “Effective Retrospectives”, a session I attended at ScanDevConf 2010. Please understand that, except for the notes at the top and bottom, this post reflects the opinions of the speaker, not me.

Note: In Agile development, a retrospective is a meeting at the end of an iteration (which a period of work, usually 2 to 4 weeks) where the team reviews the iteration together, and discusses possible improvements to their process.

A bad retrospective is: ad hoc, not prepared, with no structure.

The goals of a retrospective are two:

• participation
• decide on actions, what should we change (this is what new scrum masters often focus on)

Keys:

• Facilitation = planning, leading, setting a goal. Gives us flow.
• Framing = setting up and ending, making it focused
• Structure = ensures balance, gets everyone’s input

Facilitation

• Use an external facilitator. The person leading the meeting should not have an interest in its outcome. It is difficult to lead and participate at the same time. If not possible: be very clear about when you’re leading and when you’re participating.
• Work with the energy and the dynamics of the group. Take breaks; split into smaller groups when appropriate.
• Prepare. Think about what activities to use; when and where to have the meeting; is food needed, etc.

Framing

• Modify the retrospective according to its purpose
• Define the goal and agenda
• Not every retrospective needs to be about “how can we get better”
• Try retrospectives with specific themes: QA, communication, etc – gets you away from boredom and routine
• Start with a check-in: everyone says/draws something about the iteration
• Make it safe to participate

Structure
A retrospective should have three phases:

1. What happened? Why are we here? – In this phase we share context
2. Why did that happen? – In this phase we diverge, by brainstorming
3. what should we do? – In this phase we converge again, and decide on actions

Sharing context can include:

• Looking at raw data: burndown chart, story list, bug count chart
• Creating a timeline: write post-its with things that happened and stick them on the timeline (all at the same time or with individual preparation)
• An emotional timeline (a line chart scaled simply from – via 0 to +, and everyone draws their own line between these extremes)

During brainstorming, people write ideas and thoughts on post-its.

During the convergence phase, you can cluster the post-its, vote on them, discuss them in smaller groups, etc. At the end, the team commits to actions that are

• possible
• valuable/important
• someone who wants to do it

Finally, summarize: what have we learned, what are we taking with us.

My opinion: This was exactly what I needed. Chris’s comment about how inexperienced scrum masters always focus on “what should we change” really hit home. And our retrospectives have become relatively boring. This session gave me lots of useful, practical tips. I believe our next retrospective will be much better than the last one.

This is my summary of Bill Wake’s “To Make a Long Story Short – Splitting User Stories”, a session I attended at ScanDevConf 2010. Please understand that, except for the notes at the top and bottom, this post reflects the opinions of the speaker, not me.

Why split user stories? A story may be too big to manage. Or different parts of it may have different value. Or some parts may be better understood than others. We’re looking for bargains: best value for least cost.

There are 4 categories of splits:

• high-level splits that get rid of lots of work
• “ilities” – non-functional splits
• UX splits – simplify the user experience
• behavioral splits – simplify behaviour

Technical splits are not recommended. Stories still need to make sense and be valuable to users.

High level splits include: research; partly manual process (instead of full automation); buying instead of building; deferring features.

“ilities” splits include: static data instead of dynamic (a “refresh” button instead of constant automatic refreshes); simplified persistence; lower fidelity; lower reliability; lower performance.

User experience simplifications include: batch processing instead of immediate response (generate reports off-line overnight); single user (instead of multi-user); API only (UI can wait); simplified UI style; a generic UI (textboxes in a grid instead of nicely aligned dropdown boxes etc).

Behavioural splits include: happy path first (ignore alternative flows and exception cases); fewer choices (0 or 1 instead of many, e.g. fonts in a text editor); base case first (wait with a more general solution); collect less data.

My opinion: Pretty basic stuff rather dully delivered. I could have just taken the one-page handout and not missed much.

This is my summary of Brian Marick’s “Artisanal Retro-Futurism crossed with Team-Scale Anarcho-Syndicalism”, a session I attended at ScanDevConf 2010. Please understand that, except for the notes at the top and bottom, this post reflects the opinions of the speaker, not me.

There is a core in agile that is going missing now that Agile is going mainstream and crossing the chasm.

A problem with Agile is its name. Of course everybody wants to be agile. Look up the opposites in a dictionary: sluggish, torpid, immobile. Who wants to be sluggish and torpid?

So I came up with a description of Agile that is weird enough that nobody is going to immediately, before they’ve had time to really understand it, react with “oh yes, that’s me”: Artisanal Retro-Futurism crossed with Team-Scale Anarcho-Syndicalism.

1. Anarcho-syndicalism:
   • Worker self-management – no managers
   • Direct action. To take an example from the original anarcho-syndicalism, say you have a strike, and those opposing the strike are attacking you with clubs and guns. The standard approach would be to vote to elect a congressman who passes laws that prohibit violence against strikers. The AS approach is to get your own clubs and guns and protect your strikers. Don’t try to get into management to fix your problems, fix them now.
   • Worker solidarity: the team fails together and succeeds together, we’re all in this together
2. Team-scale: we’re not revolutionizing society, just helping your team
3. Artisanal: people on the team care deeply about the product and its users, sometimes more than the business. Counteracts the risk of becoming so infatuated with our process that we lose sight of our aim.
4. Retro-futurism: 1930s futurism pictured all sorts of nice things for the future, i.e. for now. Orbital cities, clean cheap urban transport, underwater cities, personal jetpacks. We didn’t really get much of any of that. The same happened with Agile. In the early days agile projects were few and far between, but everybody hoped that the idea would spread and make all developers happy. Instead we now have lots of teams doing Agile in name only. People on “agile” projects are saying “at least my job doesn’t suck as much as it used to” instead of “this is the best project I’ve ever worked on,” which is how it should be. Retro-futurism reminds people of the possibilities. Don’t accept things as unchangeable, change your circumstances to get where you want, keep that gosh-wow spirit.

To summarize the spirit of Agile:

• scrappy – we are trying to do something here, get out of my way
• care – for the product, the users, the process
• naive optimism

My opinion: Inspiring! Brian was an enthusiastic, passionate speaker who delivered a thought-provoking speech. New ways to think about old things. Conference sessions tend to fall into two categories: those where I learn new facts, and those that simply energize me and make me want to get back to work and improve everything. This is a prime example of the latter kind.

If you find this interesting, there is a bit more information at ARxTA.net, including a video of Brian delivering a similar talk some years ago at some other conference.

This is my summary of Erik Lundh’s “Making Sense of Lean and Agile with Getting Things Done (GTD)”, a session I attended at ScanDevConf 2010. Please understand that, except for the notes at the top and bottom, this post reflects the opinions of the speaker, not me.

GTD and lean both aim to offload your mind. Instead of lots of wishes and worries, you have a defined list of things to do. At any point, you can just pick the next thing off the list.

Worry is waste.

We shouldn’t be breaking down requirements, we translate them into things to do.

My opinion: An interesting parallel to draw, but the presentation was confused and rambling. I do not know what he really wanted to achieve with this talk. And he spent way too much time talking about how great he is and what successes he has had. I had the same problem with his presentation at Agila Sverige 2009, but unfortunately I didn’t recognize his name until I saw him on stage. I will be avoiding this guy’s presentations in the future.

This is my summary of Michael Feathers’ “Reinventing Software Design” which was the keynote speech for day 1 of ScanDevConf 2010. Please understand that, except for the notes at the top and bottom, this post reflects the opinions of the speaker, not me.

In the last 5 to 7 years there has been a lot of talk about process and not so much about design. When you raise the profile of one issue (process) all others tend to fall by the wayside. There’s also been a lot of focus on technologies. Developers in the .NET world discover things that were known in the Java world already 3 years ago, and vice versa. Design knowledge that was around has been getting lost in the generational shift. People think that they know design, but they don’t really. The design books people read tend to be 5 years old. Where are the new books?

There’s been a kind of a “design winter” – but we’re coming out of it now.

There is also a focus on things like TDD and emergent design. But these don’t mean that design is no longer needed – they require a tacit knowledge of design.

Trends worth looking at, regarding design:

• Software development is becoming more of an engineering discipline. We’re bumping into constraints.

  Hardware design has always been surrounded by constraints: heat, power. Software has mainly been constrained by our ability to make sense of it. No constraints means we do just about anything. We have capacity for unbounded complexity.

  Now software is beginning to run into hardware limits. Hardware is going to affect software; software will become more tightly coupled to hardware. Hardware will shape business. (Google was made possible by cheap hardware. Software that utilizes GPUs.) Hardware will lead to new business models that we haven’t even thought of yet.

• “It’s ergonomics all the way down.” User experience design used to be thought of as something off to one side, a separate discipline, a separate community with a separate nomenclature. But what we call “software design” is really “user experience design” where we are the users. That is one of the reasons why software design often sucks: we don’t take ourselves seriously as users.

  Design guidelines are all about ergonomics. Small classes and methods are easier to read. Cohesion and coupling have a cognitive basis.

Design will grow at the pressure points of hardware and user experience.
We’re entering an era with more constraints. Constraints will drive design. Design thrives in constraints.

My opinion: Not too impressed. I can relate to Michael’s point about the links between design and user experience. But software bumping into hardware constraints? In some parts of the industry I’m sure this is true, but I believe it’s something that affects a tiny minority of developers.

I like programming. When I don’t get to program for a while, I feel a certain restlessness. It’s the same with reading books, and physical exercise: when I get too little of it, I feel it.

Most of the time my work fills that need. When I get home and Ingrid’s gone to bed, I’d rather blog, read a book, etc. My hobby programming projects languish untouched. I haven’t done any work on my Rails app for over a month.

But this week I have barely touched a line of code at work. Instead I’ve been installing a new build-cum-version control-cum-database server, migrating all of those things from the old server to the new one, plus getting our new developer up to speed, doing various administrative tasks, and handling customer support issues.

By Thursday I was definitely feeling the pangs of abstinence, and my Rails app finally got some attention again. Luckily it’s a small app so it isn’t too hard to pick it up again. The hard part is remembering whether I had some unfinished task lying around, or whether I can just start on the next interesting-looking piece. I’ve taken to checking in a “next step.txt” in order to keep track of where I was.

An unconference similar to the previous ones I have described has been scheduled for September 12th. Read more here and join us if you can.

We’ve started work on a new help system at work. The old one uses a CMS from 2001 and we all loathe it. “Updating the help files” is the least popular task of each release. We’ve had enough; we’re starting afresh with Drupal.

So I’ve spent today setting up a Linux VPS, configuring the web server, installing Drupal and all sorts of plugin modules for it. And it’s a painful experience. Every step I take is based on something Google tells me. I have no feeling for what I’m doing, no intuition as to whether it’s dangerous or not. So with every other step, I’m wondering – if I get this wrong, how much of the system will blow up?. How wrong am I allowed to get my changes in httpd.conf before the web server will stop responding at all?

It gives me an all new perspective on what it must feel like to be an inexperienced computer user. Afraid to click on anything, afraid to change a setting, just in case they make the computer blow up.

Another perspective on this is if it hurts do it more often. It was not meant quite in this sense originally but it still makes sense. Unfortunately it’s very rare that I have a meaningful need to tinker with Linux sysadmin tasks or web server settings.