In order to ...

Lately I've been doing some story generation for a few projects, and I've really been focusing on the idea of putting value first.

Its a subtle, but powerful idea. I was introduced to it by Dan North during his tutorial on BDD at QCon London 2009 and it really clicked.

I've been doing quite a bit of process work involving Kanban, which really focuses on value - so it has a kind of synergy (pardon me while I wash my mouth out for using management speak). Liz Keogh also wrote a good article for InfoQ recently on Kanban and BDD.

So the format we've chosen is the same Liz describes in her article:

In order to ...
As a ...
I want ...

And its working really well so far. By putting the value first it makes more sense to our domain experts, who typically being non-technical in most cases got stuck on "As a", and "I want". And we've found that we keep our scope better contained as people stop thinking about "I want" and concentrate on the end value of "In order to".

So if you are working on stories I would really encourage you to try this one simple change. Hopefully you'll see the benefits.

Building your Village

On Friday the 24th of April I ran an Agile day for my team and others at the BBC, I managed to get some good speakers on a variety of Agile and Development topics - it turned out to be a really good day. The official blog post on it is almost ready to go up.

During the day my mind drifted on to the importance of interactions.

I tend to see a project team as a village, the village should be as self contained as possible - the butcher, the baker and the candlestick maker. Everyone in a village has their part to play in its success. And in a strong village everyone pulls together when times are tough, they come to a fellow villagers aid in times of trouble.

So whilst we may have a team made of specific roles and skill sets the team is greater than the sum of its parts. So as a project suffers challenges the team should pull together to meet those challenges.

I have worked in teams that do this naturally, and teams where its just never quite happened and teams where it never had a chance.

The teams where it worked had a few things in common:

Experience - in all cases the team was experienced, both in software engineering and the problem domain. Each team had at least one problem domain expert, someone who could answer or anticipate the questions.

Attitude - in all cases the team had a strong professional attitude. Not only did the teams strive to minimise technical debt, but all had generally strong work practices. That sense of professionalism actually was strong enough that the team was able to "stand up" to management at those times when it was really needed.

Motivation - in all cases the team was motivated. And typically the motivation came from the enjoyment of working with a great team doing great stuff. Something that is often overlooked.

Now if you had these things you could argue that pretty much any process would work, and I would agree - not all these projects were what we would call Agile today. But they were Agile in the sense of putting People and Interactions, before Process and Tools.

So if your team is not pulling together in troubled times, look at the three points above. Does your team have experience, attitude and motivation? If it doesn't you need to look at how to address it. And you don't need to be the team leader or manager to address it - its amazing what influence any member of the team can have if they are prepared to talk to their team members.

So how do you build your village?

Firstly, interaction. How well does the team communicate? All the members of the team need to feel that they can speak up, and all the members of the team have an obligation to listen. Do you all sit together? If you can't sit together do you use the same watercooler or coffee machine? How often do you have lunch or go to the pub as a team?

I wrote a little while ago about development being a social activity - this follows on that great teams subconsciously understand this. Now by social I don't mean going out and partying, but I mean interacting.

So why do I think interaction on these levels is so important?

Well a team that communicates well will be more fun to work with, it will improve team motivation, it will lead to improved attitude (management by example or culture) and it will encourage everyone to use their experience, encourage people to improve or better themselves.

Its not going to solve the problem of having domain experts, java experts, jvm tuning experts - but you in the end you get to be an expert by doing and learning. Ideally by learning from another expert, but that doesn't have to be from the team, it could be from conferences, blogs, mailing lists, geek nights, books, consultants or from another team in the organisation. Building the right village will encourage the team to learn, to rise to the challenge.

Why the term "Sprint" Irks Me

Apart from being inherently lazy, there are other reasons why the term "Sprint" irks me....

Agile development is supposed to be about sustainability - in fact the Principles of the Agile Manifesto states ...

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

The term Sprint in my mind does not describe a constant pace, it conjures up that desperate dash to the finish line, giving it your all in one go.

The argument is however that "sprints are short", however they are repeated. Do we expect the Olympic 100m runners to do a 100m dash, and then do it all over again, and again, and again? All in a relatively short time frame, after all how long do you rest between week long Sprints?

The other argument is "its just a name", however software development is in a large part about naming. Writing clean code is more often than not seeking the right name, something that describes intent - so why should we strive for anything less in naming our processes and their elements?

So until I find something better I will continue to prefer iteration as to me it better describes the intent of repeated time-boxed work.