Category: process

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.

Media As A Service

Much like print and tv are becoming marketing vehicles to drive people online, the domain name for an online media service is becoming sort of an abstract utility or maybe just a brand address for media services rather than the real estate upon which the core activity occurs. The service a media vehicle provides matters more than the vehicle itself.

And this isn’t only happening in the content space. Every aspect of the media business is pointing to a services model. Here’s what the key pieces look like, in my mind:

  1. Data is infinitely distributable. All data…not just editorialized words. The RSS standard opened the doors for vast distribution networks, and services like Yahoo! Pipes and Feedburner figured out how to make the distribution methods meaningful. There’s an endless supply of microchunks flying around the Internet, most of them unattached to any domain or URL except as a handy reference point.
  2. Data can be visualized in meaningful ways. AJAX and the many freely available widget kits and javascript libraries such as YUI are rendering these microchunks in the right place at the right time in the right way for people which, again, is not always on a web site. The Internet user experience is no longer held back by the limitations of HTML and the packaging a site owner predefines for their media.
  3. Media is created by everyone. Whether written in long form by a reporter or researcher, captured as video by a mobile phone owner, or simply clicked by a casual web site visitor, expressions of interest are shared, measured and interpreted in many different ways. This results in a seemingly neverending stream of media flowing in and out of every corner of the digital universe.
  4. Distribution technologies are increasingly efficient and inexpensive. Personal media services like instant messaging, blog tools, podcasting and collaborative media services like Wikipedia, del.icio.us, Flickr, etc. are easy to use and often free. Web services and open source software enable people and companies to scale distribution and production functionality for large audiences or groups of users with negligeable costs. Most importantly, these tools enable people to be influential without ever owning a domain.
  5. The distance between buyer and seller is shrinking. There are more and more ways for buyers to find sellers and sellers to find buyers from search engines to recommendation tools to coupon rss feeds, etc. Distributed ad markets like Right Media are enabling marketers and service providers to negotiate both the methods and the value of a marketing message. Advertising can operate as a service, too.

After re-reading this description myself, it looks like I’ve just echoed much of the whole Web 2.0 thing yet again. That makes me think I didn’t articulate the concept properly, as I believe there’s a very different way to visualize how data get created, packaged, distributed and remixed and how the various parts of a media business can be coupled both within the organization and across the wider network. Maybe that’s Web 2.0. Maybe it’s edge economics. SOA. Whatever.

The important thing is to think of how your media business can create for yourself or leverage how others offer Marketing As A Service, Sales As A Service, Operations As A Service, in addition to your editorial and community building efforts. Here’s a quick chart of how a media business might look that hopefully gets the point across:

Staffing Model Source Data Coopted Data Distribution Services
EDITORIAL Reporters, Community Managers, Assemblers (formerly known as ‘Producers’) Original News, Analysis, Columns News Wires, Paid Data Feeds, Free RSS Feeds, Links, Comments, Votes, Ratings, Clicks RSS Feeds, Content API (Read and Write)
MARKETING Customer Service, Evangelists, Event Organizers SEO, SEM, Paid Inclusion, Sponsorships, Staff Blogs Partner Promotion, Customer Evangelist Blogs Customer Help, Usage Policies, SLAs, Traffic/Referrals to favored partners
SALES Sales Engineers, Business Development Customer Data, On-site Inventory Partner Inventory, OEM Partner Services Ad Service API (Read and Write)

We’ve seen Journalism As A Service evolve with a little more clarity, particularly recently. Mark Glaser provides a step-by-step guide on how to structure a community-driven news organization:

“Reach out to the community for bloggers, muckrakers and go-to experts. Each topic area would require more than just reacting to news. The Topic Chief would be sure to enlist as many experts as possible not only to be sources but to also be contributors, commenters, and word-of-mouth marketers. Anyone who possesses the skills that go beyond basic participation can be hired on as freelancers or even full-time staff.”

Similarly, Doc Searls’ “How To Save Newspapers” post also lays out what needs to happen on the editorial side. Here’s step #5 in his list:

“Start looking toward the best of those bloggers as potential stringers. Or at least as partners in shared job of informing the community about What’s Going On and What Matters Around Here. The blogosphere is thick with obsessives who write (often with more authority than anybody inside the paper) on topics like water quality, politics, road improvement, historical preservation, performing artisty and a zillion other topics. These people, these writers, are potentially huge resources for you. They are not competitors. The whole “bloggers vs. journalism” thing is a red herring, and a rotten one at that. There’s a symbiosis that needs to happen, and it’s barely beginning. Get in front of it, and everybody will benefit.”

There is lots of guidance for the newsroom, but all parts of a media business can become services.

For example, the ultimate in Marketing As A Service is the customer evangelist. It’s not about branded banners, as Valleywag points out,

“When paid-for banner ads lead to another site that’s supported by banner ads, you know that something’s wrong. Anyone who relies on that circular spending is asking for trouble.”

Marketing should be about enabling customer evangelists whether your customer is simply promoting your stuff for you or actually distributing and reselling it. Fred Wilson thinks of this in terms of “Superdistribution“:

“Superdistribution means turning every consumer into a distribution partner. Every person who buys a record, a movie, reads a newspaper, a book, every person who buys a Sonos or a Vespa becomes a retailer of that item. It’s word of mouth marketing, referral marketing, but with one important difference. The consumer is the retailer.”

None of this needs to happen on a single domain. The domain chain in any of these actions probably should be invisible to people, anyhow, except maybe to ground the events in trusted relationships.

Now, there are many domains that can create wonderfully useful and valuable destinations once they reach a certain critical mass. Invoking another over-used dotcom jargon word, this is what happens at the head of the long tail. And there are obviously lots of nice advantages of being in that position.

Most media companies want to be in that position and fight tooth and nail for it even if it just means being at the head of a niche curve. But instead of or maybe in addition to competing for position on the curve, most media companies need to think about how they provide relevant services outside of their domains that do something useful or valuable in meaningful ways across the entire spectrum.

Posting articles on your domain isn’t good enough any more. The constant fight for page views should be positive proof of that. There’s a bigger, deeper, longer term position out there as a critical part of a network. Sun Microsystems’ mantra “The Network is the Computer” is still meaningful in this context. What is your role if “The Network is the Media”?

Similarly, is Marshall Mcluhan’s widely adopted view that “The Medium Is The Message” still true? Or, like many have asked about the IT market, does the medium matter anymore?

If we are moving to an intention economy, then those who best enable and capture intention will win. And that doesn’t have to happen on a domain any more.

Decentralizing journalism and everything

Dave Winer said something the other day during the latest “Newspapers are dead” meme that I can’t get out of my head:

“In the future, every educated person will be a journalist, as today we are all travel agents and stock brokers. The reporters have been acting as middlemen, connecting sources with readers, who in many cases are sources themselves. As with all middlemen, something is lost in translation, an inefficiency is added. So what we’re doing now, in journalism, as with all other intermediated professions, is decentralizing.“

I remember the whole disintermediation discussion from around 1998 when people debated which markets would be crushed by the Internet first. It was obvious then that just about any job that functions like a broker or agent would at least be challenged if not destroyed completely. It was amazing to watch the travel agency business disappear as fast as it did.

But there are subtleties to the form of disintermediation playing out today that seemed impossible 10 years ago. Umair Haque and John Hagel have suggested in their investigations of edge economics that any job function that makes money off the friction of distribution of information is threatened.

This kind of ends the whole debate about whether or not content wants to be free. That doesn’t really matter. The question is more about how else can we remove friction in the flow of information. What other kinds of information will be decentralized and when?

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

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