Category: agile

No backlog

The backlog has lots of benefits in the software development process, but is it necessary?  Could there be more to gain by just trusting your crew will do the right thing at the right time?

It occurred to me while tracking Github commits on a project that I didn’t need to maintain a backlog or a burn down chart or any of those kinds of things anymore.

Everyone was watching each other’s commits, commenting on issues, and chatting when they needed to.  I could see what everyone had done the day before.

They were all in synch enough to collaborate on the output when it helped to collaborate or work independently when that was more effective.

What could I add? Remind them of all the things they haven’t done? That’s uninspiring for everyone involved.

How does everyone know what to work on next?

The devs know what’s important, and they know how to do their job efficiently…let them work it out. If they don’t know what’s important it will become obvious in their commits. Then you can just steer when the emphasis is wrong rather than mapping hours to tasks.

They may in fact want to maintain a list that works like a backlog.  But maybe that should be a personal productivity choice, not something that’s imposed by someone else.

What about all those things you want to do that aren’t getting done?

I’ve never had a feature that really mattered to me just fade from memory. In fact, having no backlog forces a sharper focus.

How do you know when things will get done?

Your devs will tell you, and they will be accurate if it’s a personal agreement between you rather than a number on a spreadsheet.  If you have a deadline that really matters, then just be clear about that.  That becomes framework within which to operate, a feature of the code.

What if the developer doesn’t understand the requirements?

Well, do you actually really need to spell out requirements? Aren’t your developers tasked with solving the need? Let them pitch a solution to a problem, agree on it, and then let them run with it.

Of course, I don’t know how well this approach would work in a team larger than maybe 8 people, or a large-scale project with multiple parallel streams to it.  And maybe the chaos does more harm than good over time.

Clearly, I’m exaggerating for effect a little here, but I wonder a lot about how far you could go with this approach and where it really breaks down.

I think a lot of folks want things like backlogs because one can establish a meaningful agreement and reduce tension between people who organize stuff and people who create stuff.  But it’s often used to protect one side from the faults of the other rather than join them up to create a stronger whole.

But all projects and teams are different.  And it can be very tricky working out what should be done, by whom and when.

I think what I’m suggesting is that rather than making decisions around time and resource where success is measured by how effectively activity maps to a plan, maybe the better way to lead a software project instead is to adjust decision making according to the appropriate abstraction level for the project.  That way you can value quality and creativity over precision of delivery.

For example, the resources required to build, say, a global transaction platform vs a web page are very different.  And your teams will not allow you to rank them together.  You have to zoom in or out to understand the impact of those two projects, and that will then affect how you allocate resources to make them each happen.

Once that discussion has been had and everyone has agreed on what they are supposed to be working on, make sure they have enough caffeinated beverages and get out of the way.

Keep an eye on their commits each day.  And drop the backlog.

It’s incredibly liberating.

Are big product launches necessary?

A commenter in Mark Glaser’s recent post on MediaShift about the USA Today redesign sheds light on a problem that Internet companies seem to struggle with a lot.

“I think there may be a lesson to be learned in how to roll these things out. Most of the problems people are having are usability issues that it is nearly impossible for designers/developers who are in the weeds to notice.”

Similarly, Scott Karp asked the right question:

“Could it be that it’s really the social media revolutionaries who “don’t get it” when they assume that what the people want is to rise up against the media autocracy and take control, when in fact what most people want is to get high quality information from a reliable source?”

Unfortunately, even if you do the user research the recommendations of the studies often don’t fit into tight product release deadlines. And the studies often just support product direction rather than fully investigate a user need.

But the problem isn’t the research, it’s the product roadmap. In order to deliver a big punch in the market and cut through the noise, you need to be bold. And big changes that get noticed by big audiences require a lot of planning and complicated scheduling. Big changes are expensive on many levels.

But do you really need a big punch?

Most of my favorite online services tend to evolve organically as if responding to the way people are using the tools. Last.fm, for example, subtely rolls out new features that can occassionally have a significant impact on my usage. They had a pretty crappy web-based player for a long time. Of course, they upgraded it, as I knew they would, and I found it when it was relevant for me to look for it. There’s no amount of marketing they could have done to make me upgrade, and if they had done heavy marketing I might have actually been annoyed with them and considered a competitor.

The online media market is way too fickle to annoy your loyal customers.

But what about reaching new customers? Subtelty won’t win market share.

Admittedly, when you have a hammer everything looks like a nail, but the lessons of the web services market can be instructive. When you empower people to build businesses (or audiences) with your core offering, then you create a multiplier effect and reach all kinds of markets that you might never reach otherwise.

Winning market share in online media can happen by giving people the ability to distribute your offering for you, to create loyal customers for you out of their own customers, to build their own buzz for your product because they have an incentive for it to succeed.

Building the kind of passion required for a distributed customer model like this will never come from big bang marketing. It comes from fostering trustworthy relationships, establishing meaningful brands, proving tangible value, and responding quickly to market changes.

It’s not about noise. It’s about relationships.

I tend to agree with most online media insiders who appreciate the conceptual breakthrough for USA Today online and the balls to act on it, but I would be surprised if any of the positive comments in the blogosphere came from USA Today readers. And if USA Today damaged their relationship with their readers with this redesign, then they have made an incredibly costly mistake.

Online services need to roll out important new features constantly. But the days of hitting the market hard with a new product launch are fading. It works occassionally for major releases of things that are really new and require a reeducation of the market, like the iPhone. But fewer and fewer things fit into that category.

At the risk of invalidating everything I’ve said here by quoting a man who’s social and political beliefs go against just about everything I believe, Eric S. Raymond’s “The Cathedral and the Bazaar” included many astute observations about the way Linux development was able to scale so efficiently. Among the lessons is the classic “Release early and often” mantra:

“In the cathedral-builder view of programming, bugs and development problems are tricky, insidious, deep phenomena. It takes months of scrutiny by a dedicated few to develop confidence that you’ve winkled them all out. Thus the long release intervals, and the inevitable disappointment when long-awaited releases are not perfect.

In the bazaar view, on the other hand, you assume that bugs are generally shallow phenomena…or, at least, that they turn shallow pretty quickly when exposed to a thousand eager co-developers pounding on every single new release. Accordingly you release often in order to get more corrections, and as a beneficial side effect you have less to lose if an occasional botch gets out the door.”

Product Managers and Marketers need to bake these concepts into their thinking as well or risk missing the wider opportunity, the ultimate in marketing and distribution efficiency — customers as partners.

Photos: marble2, ccarlstead

Indicators of the Ruby on Rails trend

Here’s a fascinating market indicator. I was looking for a Ruby book on Amazon, something for lightweight coders, perhaps a beginner’s guide to Ruby on Rails. What did I find? I found a total of 23 books. 9 of them are hitting the shelves within weeks. All of the others were published within the last 6 months.


Here’s a sampling of what’s coming out soon:

The blogosphere saw the Ruby on Rails thing coming a while back. Now the book publishers see it, too, and they’re all racing to get a piece of the action.

There are other interesting indicators like the fact that Dreamhost offers it preinstalled as part of its hosting package. And you can’t ignore the recent adoption of Agile project management which feeds nicely into the Rails approach, even sharing language and concepts at the same level of abstraction.

Yesterday, I asked Jeremy Zawodny how his experiments with Ruby on Rails are going, so far. He replied,

“It’s frighteningly productive.”

I wonder if the venture and acquisition machines out there will learn how to plug into this market architecture. In 1999, startups did the Sand Hill march using PowerPoint as their weapon of choice. The right buzzwords in the right order and charts pointing high and to the right put many on the IPO course before engineers had been hired.

Investors today are looking for working ideas with real customers.

There’s a perfect storm forming.

“Iterate and release” has its problems, too

One of the teams I’m working with has adopted a sort of customized agile-style development process. I really like it, but a few problems are coming up:

  1. Just like after a heavy workout, you need a warm down of some sort. You can’t just suddenly stop and declare victory after a sprint. There are always a few more things to do, and your brain muscles need to flush out the acids that built up during the race. And just like that feeling the day after a good work out, it’s hard to actually get momentum going again, and a cheerleader only makes you bitter.
  2. Collaborating with other teams in the company is very tricky. Team independence is crucial to the agile process, but that means no two teams are ever in synch. It’s like IM’ing with a friend in Europe. You can catch them for a few minutes in the morning if you get into the office early enough, but by the time you’re ready to actually say something, they’ve logged off and hit the pubs.
  3. Similarly, business operations quickly get out of synch with what’s happening on the ground. The roadmap review or the hiring planning or the marketing communications or the performance reporting should all operate with the same “rapid iteration, frequent release” methods.

    For example, in my previous jobs I kept a big whiteboard marked up with all the key metrics of my business. I stared at it all the time. Patterns emerged with each new line row of data which made the short-term decisions much easier to identify. The 3 year plan was then an abstract vision with tangible month-to-month goals. Of course, we weren’t able to act on many of the short-term needs because the planning for the current year was already locked down.

  4. It seems hugely important to have an abstract framework to work within as a guiding light when you’re chasing 30 to 60 day goals. But agile development doesn’t necessarily have an end point. The goal needs to feel like a BHAG, yet it needs to be as measurable as the end date of your development cycle.

    For example, a news media site may want to chase down a long term goal of “High customer loyalty”. That goal then needs to be measured in terms of things like repeat visits. And so the result of each sprint should be an understanding of whether or not that sprint had an impact on repeat visits.

There are lots of great things that come out of the agile process including an intense focus on a goal that everyone can work towards and the freedom to postpone things that block progress, among many others. However the process is not without flaw.

At some point, all the IT solutions you can purchase and project management processes you can adopt will hit a ceiling. That ceiling is most likely a need to fundamentally alter the goals and direction of the business itself.