I Don’t Want to Be Agile, I Just Want to Create Value

3 Comments

Goldstar spent a few months at the end of 2009 revamping its project management system. We were previously managing everything in Mingle by creating a large number of lanes and moving cards left to right. Some cards were huge features. Other cards were tiny bugs. The system was one-size fits all, which is the same as one-size fits none. There was no concept of velocity or iteration, though we tried to measure that separately with a wet finger in the air.

We—and by we, I mean Chrissy Deters, Pat Maddox, BJ Clark, and I—made a series of changes switching out of Mingle into what we have today, a Kanban-style system that is 1 part physical cards on board, 1 part Basecamp and 1 part Pivotal Tracker. It’s not 100% Agile or Kanban (or waterfall), and that doesn’t bother me right now. My goal—my team’s goal—isn’t to be Agile, it’s to create value. Any means to an end should not be confused with the end. Of course, there’s differing opinions among us about this new process. Each of us has suggestions or tweaks that we’d like to make, inadequacies that we see. But, for now, this new process has proven to be more effective for us. It’s a big step in the right direction.

So what is our process:

The physical board is the “idea board” with all the features we “want”. Using a sharpie and a 3×5 card, you can request a feature… if there’s room on the board. There are big ideas and small ideas on the board, but you can’t get more detailed than a sharpie and a 3×5 card allows, and you can’t add a new board. It’s not convenient, which is a good thing, and it’s not infinite, which is a better thing. It is physical which is awesome—you’re physically limited to not being able to do much with a new idea. On the idea board are 5 spaces for “ideas” that are in Basecamp and 5 more for things in Pivotal Tracker being coded. Everything else is just in the pool not being worked on. It’s a three-lane super-simple Kanban board. True Kanban is different, you have enqueue and in progress lanes. If you want you can consider the Idea Pool to be the queue for Basecamp, and Basecamp to be the queue for Pivotal Tracker. The important part is that we’re capping the number of things that can be in progress.

Idea Board -> Basecamp -> Pivotal Tracker -> Done Done

Some ideas from the board are simple enough that they skip right over Basecamp, but many become Basecamp projects. There they are discussed, refined, wireframed, mocked-up, tweaked and ultimately moved in PT tracker. Initially we looked at Basecamp as a replacement for Mingle. I didn’t like it. I didn’t get it. I didn’t feel like I could express the priorities of the company with it. That was something that I needed PT for. But with PT’s forced granularity, I thought we were getting too detailed too fast and we didn’t have a forum to discuss some of the larger concepts of an idea like branding and the flow between related features. Deciding to put Basecamp on top of PT filled the void. With Basecamp, it’s so easy to communicate and collaborate on tasks, designs and decisions. You can’t break those tasks up into iterations or measure velocity inside Basecamp (maybe with a plugin, maybe?), but from its collaboration features we get beautifully designed features with ease.

As parts of an idea come out of Basecamp and are ready to be coded, they go into PT. This may seem awkward to some but what we’re doing is getting more granular in each phase. One idea on the board becames a project in Basecamp, that project becomes a series of to-dos, and each to-do task then becomes a bunch of stories in PT. We’re also free to skip any steps that aren’t applicable. This makes perfect sense to me given how we work. We start with a idea, we break it up once, and we break it up again. We’re not writing up massive requirement docs that become outdated before they’re even read. One idea from the board will become dozen of PT story cards and span a coupel iterations. It’s also important to note that if we’re being granular enough, a single feature will be in basecamp and PT at the same time. It’ll be iterated multiple times in an agile way.

Pivotal Tracker doesn’t offer a lot of choices (feature!), so we use it as everyone else does. We have stories. They are features, chores, and bugs. The developers estimate them, start them, finish them, deliver them. The customers (product managers) prioritize them, accept them, reject them. We work in weekly iterations and mark releases. We try to keep the backlog small–ideally we have nothing but an iteration’s worth of stories. The icebox should be empty because that’s what the Idea Board is for, but for now we use it as a bug tracker.

PT enforces a lot of agile practices on us. We have to estimate. We have no choice but to track velocity. We have to keep the stories small. We deliver things in pieces and get immediate feedback. We also pair programmer and do BDD most of the time, so we’re getting more agile outside PT too.

We replaced Mingle with 3 tools and one of them is something we have to touch…with our fingers! Having so many tools, is bad right? Well, I once knew a contractor that only had a hammer… no, that’s a lie. It’s absurd to think that a professional contractor would only have a hammer. In every professional, you have many tools and you use them for different tasks. Using a Kanban-esque physical board, Basecamp, and Pivotal Tracker isn’t using too many tools when they’re the right tools for the job. In fact, I think we’re still missing 1 tool (a topic for another post).

In the end, we’ve accomplished a couple things:

We have fewer things in progress with Kanban-style forced lane limits. Mingle had an infinite backlog and we wasted a lot of time filling it, organizing it, only so that we could efficiently ignore it. Some of those Mingle cards that we ignored had documents or mock-ups attached… powerpoint presentations on why we should do them. All wasted work. One of the purposes of Kanban is to move things quickly from start to finish, not to get more done, but to simply reduce the time from when you begin investing effort to when you receive rewards.

We don’t get too detailed too soon. When we moved a card through the lanes of Mingle, the card never changed. If we wanted to be detailed in our estimates, we have to be detailed creating cards, which meant putting efforts into things that would never get built. By moving things from the Idea Board to Basecamp to PT, we get more detailed when we need to, and it’s obvious when we should–each tool demands the appropriate amount of granularity for that development phase. You start with 3 words written on an index card and finish with 20 feature stories accepted in PT.

We get better, more efficient collaboration on features upfront in Basecamp. We talk more but only when we’re ready to talk. Basecamp is all about commenting and collaborating. It’s easy to get input from a various stakeholders upfront. We learn more. We vet more. And when we move things into PT, we’re more prepared.

We’re forced with PT to estimate stories, track velocity, and prioritize everything. Stories have to be accepted, and there’s no confusion about what’s done. It’s done, when the customer says it’s accepted.

This has made a significant difference in the development cycle at Goldstar. Yet, it remains a work in progress. There are at least two areas that I want to address with our team, and I hope to cover them in future posts too:

  1. Why bugs are usually about psychology when they should be about economics.
  2. The folly of rewarding velocity while hoping for value.

In the end, I’m not suggesting that you use our process. Maybe you should be 100% Agile. I am saying that you should never, never, never start with the goal of being Agile. You should start with the goal of creating value, and you should look at Agile as a tool to achieve that.

3 Comments (+add yours?)

  1. Simone
    Aug 07, 2010 @ 10:04:56

    Hi Robert,

    really interesting blog post, funny enough I was thinking about writing a blog post on how we’ve structured our development process.

    Btw I don’t think you are using too many tools, if they work for you use them! :) I don’t believe there is a perfect process to adopt if you want to deliver value because it depends on lots of factors (the team, the project, the customer, contracts, resources etc.) .
    I like your “Idea board” idea , I think using a physical board reminds you better what is your long term target and what needs to be done, while if, say you have all your ideas in a digital format, it’s easy to forget about them because you don’t really bother looking them up constantly.

    You were also talking about setting limits, could you explain better what are the limits you adopt?
    We also ended up setting limits, especially for Chores (we are using Pivotal Tracker as well), and we’ve decided that only one member of the team can work on a chore at one time, because chores (even though are essentials) usually don’t really produce business value.

    ah I almost forgot, I’ve developed a chrome extension for Pivotal Tracker so to be able to visualize the current iteration like a card wall. Maybe you can add it to your set of tools :)

    here it is:
    https://chrome.google.com/extensions/detail/iegbkljacgfochoondhgibofiijnedjd

    vizio

    Reply

  2. tosh
    Jul 30, 2011 @ 12:30:30

    Your article is spot on. I’ve come to the same realization about the importance of different granularities (features, tasks, …) and the fact that basecamp itself isn’t a good fit for granular tasks and pivotal tracker is too detailed to be used as single tool for planning development. A combination of them to achieve different granularities definitely helps a lot in terms of overall organization and enables to reduce waste and makes delivering value easier.

    Still I wished these tools would integrate better and I also found the combination of several tools somewhat expensive (am I cheap?) so I started to work on http://www.blossom.io

    Ping me if you’d like to check it out. I would really appreciate your feedback on it and whether you also think it does a good job regarding the challenges you mentioned.

    cheers,
    tosh

    Reply

  3. Brett
    Feb 01, 2013 @ 08:27:12

    “It’s not 100% Agile”

    * Create Value
    * Remove Waste
    * Reviewing and Improving Processes
    * Better Communication

    It sounds like you are more agile than the people who think agile is a specific set of processes that MUST be followed. Agile is really all about achieving a set of goals.

    http://www.agilemanifesto.org/principles.html

    Reply

Leave a Reply