Category: agile

Agile is Dead! Long Live Agile!

I keep seeing headlines on various programming news sites saying something like “Agile is Dead”. When I do, I know immediately that the author has missed the point. Agile is not a methodology to be slavishly followed. It is a philosophy of software development. It is a collection of best practices that may help the developer solve his customer’s problem. It is a starting point from which to open a dialog between the customer and the developer.

As such, it makes statements about tradeoffs that can be made in order to achieve goals. For instance, agile doesn’t prescribe that you should have sprints of two week duration. Rather, it suggests that bounding the time between milestones where you have demonstrable working code will help keep your customer’s confidence in the team high.

Observing that users rarely know exactly what they want at the beginning of a project, even when they think they do, agile suggests focusing on some small number of features at a time that can be demonstrated to the user at the end of each sprint. This has the added advantage of constraining the amount of time that you spend developing a given feature so that if the customer ends up not liking it as well as they thought when they actually see it implemented you have not wasted anything more than the minimum amount of time discovering that fact.

In short, agile is a tool bag of techniques for improving communication between the developer and the customer and insuring that the developer spends the maximum amount of time possible working on the things that the customer values most.

The practices of many agile teams have the benefit of having repeatedly demonstrated their effectiveness in actual practice  but they are not some kind of magic formula. If the customer refuses to communicate with the development team as they develop, agile is not going to work. Not because it is dead. But rather because it is not accomplishing the underlying goal of facilitating communication.

Communication is difficult in the best of situations. When one, or both parties fail to communicate, agile practices become less and less effective. There is no such thing as a silver bullet. Software development is hard. It is always going to be hard. And the hardest thing about it is for the customer to clearly communicate to the developer how he wants the software to work. This is made even harder by the fact that he often doesn’t know.

So the next time you see the headline, “Agile is Dead” remember, that agile is just a collection of suggestions that may (or may not) be helpful in communicating about the customer’s desires and expectations regarding the software that you want to build for them. Anyone that tells you any different is selling you a bill of goods.

Sweet dreams, don’t forget to tell the ones you love that you love them, and most important of all, be kind.

An Agile Team of One

I am developing some software at work by myself. I have worked on several different styles of Agile team in the past, e.g. Scrum and XP, and I decided to think a little about what Agile practices are appropriate for a team of one.

First up, the daily tag-up, otherwise known in some circles as “the Scrum”, doesn’t serve the same purpose that it does on a larger team. You probably should set aside a moment, perhaps first thing in the morning, to review your progress from the day before, identify any obstacles you need to address to proceed, and make note of what you intend to do today. That should take very little time since you don’t have to explain what you mean to anyone else. Communication is the benefit and the major time sink, of the Scrum.

Next, a backlog is useful. I consider it another name for my todo list but it is a little more formal than some todo lists. I keep it sorted in order of highest priority first. I mark each major item with a status, e.g. ready, in-work, waiting on <resource> etc. I also use an outliner to keep track of my backlog so that I can easily represent subtasks.

I have added a practice that I learned from Dave Winer, called Narrate Your Work. It is particularly useful for me since I don’t have the benefit of a colleague to discuss my project with. By narrating my work, I get down the essence of what I’m doing and why so that I can remember what I’m trying to accomplish and the decisions that I have made along the way.

I haven’t had to do any estimating yet so I haven’t done anything like the planning game. I have a suspicion that you need three or more team members for the planning game to work very well. I also haven’t divided the work up into sprints. That seems like over kill for the one person team.

I will be doing periodic evaluations that will correspond somewhat to the end of sprint retrospectives. I think the key here again is that since I don’t have anyone to discuss it with, it is just a matter of taking a moment to think about what I’ve learned to date in the project.