Why We Are an Agile Shop

Last week we had a lively discussion about Agile development at Carbon Five. It was fun telling the story of how we got started with Agile nearly a decade ago. We discussed how it helps us deliver value and deal with the challenges we face as a services company. Here’s a summary of that conversation…

How does Agile help us to do better work for our clients?

To answer that question, I think it’s important to reflect on what makes building a product hard. Here’s a clue: Everything.

There are technical challenges, but those are the least of your worries in practically every case (especially early on). There are product questions: who are you building for? what features do your customers really want? how can we validate our hunches in a meaningful way? what incarnation of those features will be both useful and a delight to use? There’s time pressure. And to add fuel to the fire, the team is made of people. You know… with ideas, egos, personalities and feelings. It’s amazing successful products happen, period.

We wanted a process that’s effortless when it’s working awesome while also giving us signals when something is broken. We’re not interested in process just for process’s sake. It turns out that Agile can help navigate these challenges and gives us pretty clear warning signals.

At the Core

In trying to distill out the most important parts of our Agile process, I came up with my take on the essential ingredients. I’m not saying other aspects aren’t important too, just that these make a strong foundation.

  • Small units of work
  • Optimize for value
  • Iteration
  • Product owner involvement
  • Feedback
  • Honesty and trust

If any one of these is missing or broken, the project has a much higher risk of running into trouble. That doesn’t necessarily mean complete failure, but it does mean the project and overall experience will fall short of its potential.

Small units of work keep the team focused and allow for greater flexibility when planning. We write user stories and every one of them captures single workflow framed from the user’s perspective. A story should be whole, meaning it delivers value to the user on its own. Stories normally take a couple of minutes to a couple of days to deliver. When they’re small it’s easy to move them around and make tactical decisions during planning. It’s also easier to avoid needless yak-shaving when the stories are small.

Small units of work aren’t enough, they must deliver Value. We typically measure value in terms of user-facing functionality. We know that some amount of infrastructure, architecture, meetings, etc needs to happen to build a product. However, that’s not what first draws a customer to a product. It has to solve a customer’s problem. Getting everyone on the same page about value is crucial, otherwise folks may be optimizing for different things.

Software products evolve over time through the addition of new features, the enhancement of existing features, and removal of unused features. It’s inherently Iterative. We start the process of iteration from week one. By the time a product sees its first ray of light, the team has executed the process of planning, designing, building, and deploying many times. The structure of the process is in place and the team has enough experience with it that it can be repeated confidently.

Knowing that there’s always an opportunity to iterate on a feature allows us to build the right-sized version of the feature for where we are in the lifecycle of the product. Not every feature needs to have all of the bells and whistles when it’s born. The time saved can be spent on something that is more valuable.

Every one of our projects has a Product Owner who’s part of the client team. Our goal is to guide and empower the product owner so that they can direct the team’s focus on what’s important. Some product owners are very involved and others minimally so. The low bar of involvement includes two important activities: prioritization of stories and acceptance of the stories once they’re complete. Without these, there’s no one at the helm and the chance that the client isn’t going to be happy with the engagement goes up a ton.

There’s internal and external Feedback. External feedback on the product can be collected via a wide array of techniques. Until ideas are validated by customers, they’re just assumptions. Building features on top of untested assumptions drives up the chance that we’re building a dud. It might be high-quality code with an extensive set of automated tests, but who cares if no one wants to use it. Building a product without integrating external feedback is like betting everything on your first hand of poker when you haven’t yet learned the rules.

Internal feedback comes from the team and improves the process itself. Reflecting on how it’s going and making changes to better suit the reality on the ground is critical to keeping the process a good fit throughout the lifetime of the product. Otherwise, the process starts getting in the way when things are going awesome or it starts failing to give signals when it should.

It should go without saying: Transparency and trust are key to building a team that can overcome the challenges of building a product. If there’s bad news, we want to deliver it early so that we’re in the best position to do something about it and reap the benefits. Without trust, it’s hard to stay psyched about the people with whom you’re working. When every action comes from a place of honesty and your intentions true, trust grows naturally.

Signals

Here are a couple of the common signals that suggest something’s up:

Low velocity – Velocity is the rate at which the team is completing stories that deliver user-facing value. Really low velocity can be a sign that stories are too big, there are inefficiencies in how work gets done, or the team is spending a lot of time on “infrastructure”.

Erratic velocity – Often the result of inconsistent planning. When the backlog is well thought out, things move fast. When the team gets to stories that are poorly written or vetted, productivity grinds to a halt.

Slow acceptance – The product owner isn’t providing the team with the feedback it needs to know it’s doing a good job. Sure, developers move on to the next story, but they may be building on building blocks that miss the mark. It can be a real drag on morale and velocity.

Big bug fix session before a release – Rather than finding and fixing bugs continuously, the team is delivering stories that are buggy. That debt has to be paid down before the software gets into the hands of users. This creates a false sense of velocity which is knocked down periodically before a release.

Others: Running out of stories, stories are frequently blocked, need for big refactors.

The more experience you have the easier it is to pick up on the signals and figure out what to do about them.

What about the Developer Practices?

I’m leaving developer practices out of this conversation deliberately. Testing, continuous integration, pairing, sustained schedule, etc are all second nature for us. There’s enough content there for a another article (or several).

Conclusion

My experience has shown that if the process includes the above components, we’re able to rapidly build valuable features. When something isn’t right and we’re being perceptive, it becomes apparent quickly and we’re able to reflect and make the changes necessary to fix the problem. In the end, Agile lets us welcome feedback that inspires course correction while also making it really hard to overlook issues when they come up.

About Christian Nelson

Christian is a software developer, technical lead and agile coach. He's passionate about helping teams find creative ways to make work fun and productive. He's a partner at Carbon Five and serves as the Director of Engineering in the San Francisco office. When not slinging code or playing agile games, you can find him trekking in the Sierras and playing with his daughters.
This entry was posted in Process and tagged , , , . Bookmark the permalink.

10 Responses to Why We Are an Agile Shop

  1. Sr523 says:

    Great article. Thank you for sharing. Regards, Scott

  2. Brian Ng says:

    This is a great overview and pretty much sums up how I think about agile ;)

  3. Jared Carroll says:

    Excellent overview Christian, I’m on board with all of this.

    On a recent project, I’ve seen “small units of work” taken to mean “no stories over 2 points (using a Pivotal Tracker powers of 2 or fibonacci scale)”. A story larger than 2 points is broken down into several smaller stories. This has worked good because the product owner is very technical and is comfortable accepting stories as small as adding a method to a class. However, this does result in a lot more granular stories, so the product owner needs to be constantly accepting stories. Definitely an exceptional case.

    I’m also a big proponent of iterative development. I prefer to just get some very basic test passing quickly; committing as many “sins” as necessary. I find that my pair will often get hung up on implementing the full feature on the first pass, thinking too much, and thinking too far ahead. Taking tiny steps is a great way to keep the pair’s momentum up.

  4. Neil Killick says:

    Excellent stuff. The product owner role is the one usually neglected or its importance overlooked in transitioning companies, or ones whose software delivery arm is practicing Agile methods. Always good to see articles like this hammering home the importance of someone to be owning the vision of the product and directing the team in terms of feature delivery.

  5. Pingback: Why We Are an Agile Shop | The Carbon Emitter | Brent Sordyl's blog

  6. PM Hut says:

    Hi Christian,

    From this article one understands that you guys are those of the very few who are practising Agile the right way. We have published an article by the way on the Agile metrics (it’s written by Esther Derby), and in it it highlights some points very similar to yours listed under the “Signals” section (with the exception of low/erratic velocity, which his a good point).

  7. Anna says:

    Great artice. As a member of a team that both is and isn’t Agile, but which mostly strives to be so, this is a great article to bring into a discussion about how we’re working and what we can tweak in our process and approach. Thanks for the expert insight and details.

  8. Grueber says:

    Thanks for sharing this valuable insight Christian. As a small fledgling startup we are trying as best we can to follow agile methodologies while building our product but are struggling with what software platform to use to manage everything. I was wondering if you would provide some insight into what applications you use or have used successfully in the past to manage your day-to-day agile development. Thanks in advance.

    • Hi Grueber –

      We use Pivotal Tracker (http://www.pivotaltracker.com) for our Agile project management. You can create and edit user stories, as well as estimate and prioritize them. And you can put each story (feature, bug or chore) through the lifecycle of started, finished, delivered, accepted/rejected. We use it on all of our projects and it’s excellent.

      We also use Github for source control, including pull requests quite often, as well as Github issues sometimes.

      We use various continuous integration solutions. We have been using TeamCity for a while, but it’s expensive. We like Jenkins and Travis as well.

      If you do any remote collaboration, you might also want to try a product that we built for ourselves, but make available to others. It’s called BoardRoom, and it’s real-time collaborative sticky notes. http://boardroom.carbonfive.com

      I hope this helps!
      -mike

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>