If you’re a developer, designer, project manager, or anyone who spends any time around software development, you’ve probably worked on a team that practiced (or claimed to practice) “Agile” project management methodologies. Even if you haven’t, it’s almost impossible to hang out in the developer community without seeing think-pieces and tweets either singing the wonders of Agile or slamming it as another buzzword-cloaked, middle-management scam.

While Agile has its critics, many of them seem to take umbrage with its bad implementation rather than the idea itself. Lots of organizations claim to be Agile, but to quote rapper Isaiah Rashad, they souls was never in it.

“While Agile has its critics, many of them take umbrage with its bad implementation rather than the idea itself.”

I think much of the blame for bad implementation of Agile comes down to one of two root causes:

  1. A company is either attempting to shoehorn Agile methodologies into teams for which they are not well suited, or
  2. They are attempting to execute Agile workflows without implementing Agile foundations.
Best Practices for Implementing Agile

The most common mistakes of implementing Agile can be easily avoided by following two best practices:

1. Give your teams a primary focus.
In waterfall development, it seems easy to have a bunch of individual employees or freelancers working on many separate projects simultaneously. Just get the designs from the designer and pass them off to the front-end developer, freeing the designer up to work on another project.

I say it seems easy because, in practice, there are often unforeseen iterations required when what the designer delivers isn’t exactly what the developer needs (or what the client wants). This leads to rapid task-switching, waiting on blocked tasks, re-work, and a multitude of other waterfall sins that cause bad work and team burnout.

Building teams that can handle a product from start to finish—and focusing them primarily on one project at a time—leads to much better estimates, less wasted time, and simpler math on pricing and time allotment.

2. Align your billing structure accordingly.
Waterfall teams are used to billing on a contract basis. The whole system of RFP/RFA/RF[whatever] is based around clients enumerating what they think needs to be done in a several-page PDF, from which consultants bid for the contract. An uncomfortable dance ensues over what is “in scope” and “out of scope” and often results in either the consultants or the client feeling like they got the short end of the stick.

“Our Product Development process at Polymath is based on a 3-month cycle.”

Agile projects should be just that—agile. This means that requirements (and scope) should change. If we really care about delivering the best product to our clients, we shouldn’t feel like we have to punish them financially for changing their minds. We want to welcome open-minded thinking about the future of the product. In the end, allowing clients to discover their own “best way to go” makes us infinitely more valuable than any “Scope of Work” ever could.

To achieve this goal, it’s important that the topic of money not have to be brought up every time a client wants to add a new feature to the project. My advice, having tried everything I know of so far: bill by time period.

Billing this way can be as simple as 1–2–3:

  1. Determine your hard costs for each team. Let’s imagine a 3-person team that with a total cost of $20,000/month.
  2. Determine your required markup. Let’s say to cover taxes, administrative costs and a modest profit margin, we need to net $35,000/month from our 3-man team.
  3. Determine your starting velocity. How fast does your client need to move? How much other overlapping work is going on inside the company? At Polymath, we always strive to dedicate individual teams 100% to a specific project (especially for the first few sprints). For the sake of this example, let’s assume we need to reserve 20% of our team’s capacity for long-tail support on the previous project, leaving us with 80% to dedicate to our new client, who wants to move at maximum velocity.
$35,000/month x 80% = $28,000/month
$28,000/month ÷ 2 sprints/month* = $14,000/sprint

*1 month = approximately 2 sprints (and, yes, we ARE going to use those extra 2–3 days later)

Given the numbers above, we can confidently approach a new client with a good picture of what it will look like to work with us.

Making Agile Work

The most basic version of our Product Development process at Polymath is based on a 3-month cycle I like to call …. (dun dun daaaaaaaaaa) The Iteration Loop.

If we’ve taken care of the two best practices I mentioned above, we’re in good shape to get working! I’ve gone ahead and made a little diagram of our iteration loop below. Yours may differ:

Polymath Iteration Loop

We start the engagement out with a five-week contract for the price of four weeks. (Remember the extra 2–3 days per month that we rounded off before? This is where it gets used.) The first week of our engagement features a Design Sprint, which we use to determine general expectations and ambitions, plot out a “minimum viable product,” identify crucial features, and do a little interaction design. The Design Sprint process is repeated at the beginning of each 3-month cycle, so that we can be sure to keep refining our vision and strategy for the product.

At the end of the first week, we have a big list of features, the most urgent and important ones of which have been prioritized and estimated (for length of time). This is our “backlog.”

Based on our experience from past projects, we’ll use these time estimates to determine what we can do in the first two-week sprint. During the first sprint, the client has the option to decide to either cut off development after the second sprint or commit to another 2 sprints of development. They will have this decision (essentially, to “hit or stay,” in Blackjack terminology) every 4 weeks for the duration of the project.

I hope this gives you a good idea of our basic schedule. Agile can be done well, but under the right conditions. Do you agree? Send me comments or suggestions (or tell me that I’m dead wrong) on Twitter @DCoulbourne.