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
- Product owner involvement
- 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.
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.
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).
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.