Some of you may recall that back in June we had some big news around here … not a baby, not a wedding, but an acquisition!  In June, Cox Target Media (the provider of Valpak) acquired Savings.com, a leading online source for coupons, deals, and expert savings advice.  As a result of the acquisition, I’ve been heavily involved in a series of synergy projects between Valpak and Savings.com which has allowed me to get to know their products, process, and people much better.  First off, they have a great product with over 100,000 coupon codes for top national merchants (Now, I am officially addicted to searching for coupon codes before I online shop!).  Second, I was thrilled to learn that their process is heavily rooted in both Agile and Lean. Third, their people are quite frankly the best in the business and super cool too.

Four months into this relationship and I’m now ready to share with you more about Agile and Lean at Savings.com through the words of their CTO, Joe Zulli.  What follows are Joe’s responses to a series of interview questions I presented him with.  I thought I’d end up doing some editing of his responses but after reading them, they are so worth sharing in their original format.  I hope you enjoy as much as I did!  My favorite quote is the very last sentence … “If it’s not fun, you’re doing it wrong!”

If you want to connect with Joe, he’s on Twitter @JoeZulli .

What Agile methodologies (XP, Scrum, Kanban, etc) do you use mostly?

We follow the Scrum methodology (daily standups, planning meetings, story pointing, etc…) pretty closely. We have also integrated bits and pieces of XP into our development process, but we stopped doing the parts that weren’t working for us (such as pair-programming).

How have you adapted that Agile methodology to suit the needs of your organization?

I try to be as open-minded and non-dogmatic as possible when it comes to any methodologies we use. We’ve tried a lot of different things over the years, kept what worked, and dropped or modified what didn’t. One example of where we have had to modify the “typical” Agile process is in the fact that we practice continuous deployment at Savings.com. In other words, we deploy to production multiple times a day. Before we started doing continuous deployment, everything fit much more neatly into the ideal Agile package. We had two week sprint cycles, with every sprint capped off in single, big release. With moving to continuous deployment, we’ve had to decouple the planning schedule from the release schedule. This brought about significant challenges, such as how to do acceptance testing when software is going so quickly into production.

How many Agile teams?  How many team members? What are the roles on your Agile teams?

We have a varying number of Agile teams depending on how many core initiatives we have every quarter. A “core initiative” is our name for the big projects that we decide to tackle that quarter. We usually have between three and 5, including an “Operations” initiative which is generally a bucket of smaller changes that need to be made to keep the core business running smoothly while we experiment with other growth opportunities. Each team typically has about 3-4 engineers, 1 product manager, and 1-2 business owners. Even though the teams are separate, we do planning, demos, and retrospectives as one big group. This is to help keep everyone in the loop with what’s going on across the initiatives, and facilitate knowledge sharing. Just how much should be kept to the smaller teams, vs. shared with the larger organization is something we’re still tinkering with.

How long have you been doing Agile and/or Lean?  What benefits have you found?

I’ve been doing Agile personally for the last 10 years. There are too many benefits to name, but if I had to choose one, I’d say that the most important benefit is that it’s much easier to change strategy and pivot a project. This makes experimentation and risk taking much more feasible. Being able to try out new ideas and turn on a dime is critical, not only for startups, but for larger companies as well that do not want to become obsolete.

What makes you a Lean Start-up?

Lean Startup and Agile really go hand-in-hand. I can go on forever about Lean Startup, but for our purposes here, I’ll discuss it in reference to Agile. Lean startup is a scientific and systematic approach to turning an idea, or vision, into a viable business. One way to think of it, is as the scientific method for startups. Most recent scientific breakthroughs were achieved not as one singular stroke of genius, but rather as a series of smaller experiments to prove or disprove a single hypothesis. The beauty of the scientific method is that you always win. Even when your hypothesis is disproven, you still come out better off because you’ve gained valuable knowledge that will make your next hypothesis that much better. Repeat-process enough times, and you will have the breakthrough you were hoping for (assuming you don’t give up first). In Lean Startup, we believe the same concept can be applied to business. After all, what really is a “vision” other than a collection of hypotheses? If you can break a vision down into a prioritized set of assumptions, then efficiently test those assumptions, you will have much more success, in much less time, for much less money, than if you just build everything whole-hog without testing your assumptions along the way.

Above all, Lean Startup is a redefinition of what it means to make progress. The Agile Manifesto states that “Working software is the primary measure of progress.” Leans Startup, on the other hand, defines the primary measurement of progress as validated learning. After all, what good is working software if it doesn’t move you forward as a business by making your customers happy. Sure, you may have thousands of lines of beautiful code, but did you really make progress if your company is no better off? Probably not. When you follow this new definition of progress, you stop worrying about “velocity” and how much code gets delivered, and start focusing on how you can learn the most the fastest. Sometimes a simple phone interview with a half a dozen prospective customers will get you a lot closer to where you need to be as a company than writing half a million lines of code.

What have been you greatest challenges to using Agile and how are you overcoming them?

In the early days, the greatest challenge was in getting everyone to buy into such a big change in how we were doing things. People get stuck in their ways, and telling someone that the way they’ve been doing things for years is wrong (or at least not ideal) is hard to swallow. It took a bit of persistence, but eventually everyone saw the light.

Nowadays, our biggest challenge is the fact that our team is distributed geographically. Our main tech center is in Santa Barbara, while most of the business folks are in LA. Add to that, the fact that we also have a team in the UK, and various consultants all over the place, and it adds up to a pretty distributed team. Not being able to just walk over to a person and ask a question forces us to be a lot more disciplined in our approach to Scrum. We really need to get as much as we can out of things like standup calls, because they are one of the few times a day information is exchanged across the whole team. When you have the luxury of having a local team, much more information gets transferred via osmosis.

What sorts of Agile technical practices have you adopted (CI, automation, etc.)?

We’ve invested very heavily in automation. We do CI, automated builds, and have a fully automated deployment process, which includes taking backup snapshots of the database, etc… We use JUnit and Selenium as out primary testing tools. Being able to automate everything that you possibly can is obviously really important when you’re deploying all the time :).

Describe a typical iteration in your Agile process?

Our sprints last one week. Coding starts on Wednesday and ends on Monday. A typical week looks like this:

• Friday: The executives and stakeholders meet to agree on goals and discuss priorities for the upcoming sprint. The backlog is reprioritized one final time, and the top X number of story points are pulled out and made into the next sprint.
• Tuesday: Big meeting day. No coding happens on Tuesday, but rather the day is dedicated to process and design. Tuesday’s meetings contain:
  • A retrospective of the previous sprint with a Start/Stop/Continue meeting
  • Demos from tech and product of all the new stuff created in the last sprint
  • An update from the business owners on all on how features released in prior sprints are performing.
  • Breakouts and design sessions for all of the tickets in the upcoming sprint. This is where all of the tickets get broken down and tasked out.
• Wednesday – Monday: Heads down coding for the tech team (as much as possible).

What was your world like before Agile?  Would you ever go back to that?

Everything was far slower paced and less efficient. I definitely won’t be going back to the Dark Ages before Agile. Even more so, I would definitely not go back to the days before we did continuous deployment. And even more than that, I wouldn’t go back to not being a Lean Startup.

What’s the key for you and your teams in being more and more Agile each day?

Two things: The first is to be dedicated as a team to constant improvement. That’s not always as easy as it sounds. You have to build a culture where constructive criticism is not only allowed, but is expected from every person on the Agile team. Solving a problem is often quicker and easier than identifying the problem in the first place. You need a team that is dedicated to breaking through bottlenecks and fixing “broken windows.”

The second is the need to constantly experiment. You need to get out of your comfort-zone and try new things process-wise. Most ideas won’t work, but some will, and the ones that do will make all of the others worth it. Bite off change a little at a time. I remember vividly when I first heard about continuous deployment. We were deploying every two weeks at the time, and I thought the ideal of deploying 20 times a day was the stupidest thing I ever heard! But then I started to hear some great success stories, so I decided to try it out by taking baby steps. First, we went from bi-weekly deployments, to once a week. Everybody loved it. Then we went to twice a week. Again, everybody loved it. Then we started deploying every day. I’ll never forget the first time I heard someone complain because they missed the daily release train by 5 minutes and had to wait a WHOLE 23 HOURS AND 55 MINUTES!!!!!!!! to deploy their awesome new feature! This was unacceptable! We needed to deploy more often! It’s funny how addictive it gets, and that’s how it should be. Improving the process of your daily job should be addictive. It should be fun. If it’s not fun, you’re doing it wrong!