Step 1: Reduce project (product) size
All large transformations start with small success stories. Starting on a large, complex project as a trial run for Agile, a process that is new to your organization, is probably not the best idea.
A divide and conquer approach when introducing Agile to the enterprise is preferred. We select an initiative from the product portfolio and distill it to the smallest functional modules, allowing for the team to iterate on sub-components of the overall product. This gives the cross-functional team the opportunity to familiarize themselves with the workflow, experience the rhythm of agile rituals, and build confidence in each other.
The team is encouraged to fail. Failing on a small piece of delivery, a sprint, endorses collaboration, helps learning from mistakes, and limits the financial impact since the scope is not significant. Long term, the team grows to understand that failure is a natural part of software delivery and that the real indication of success is shipping the right product for the users. In fact, embracing failure also aids organizations in adopting a more innovative mindset. Not all ideas are meant to succeed, but you’re more likely to hit a jackpot if you allow your teams to experiment.
But, let’s get back to project sizing. What’s too small and what’s too large for getting started with iterative delivery? In short, anything less than 1,500 man-hours is probably too small, and anything over 5,000 is risky. Here’s how we get to those numbers:
A typical, small delivery team could include:
Product Manager - the individual responsible for building the right software for the users. The PM represents the business and establishes the minimal viable scope for the product to meet the customers’ needs. In classic waterfall delivery, a subset of the PM’s responsibilities is often handled by business analysts. The involvement of the PM in actual day-to-day delivery is limited, so let’s say they will have a 25 percent utilization of total productive weekly hours (i.e., the PM will spend roughly eight productive hours, helping the team define what they’re building on one product). These hours vary based on the size and complexity of the product managed.
Team Lead - responsible for distributing work across the team, grooming the backlog with the PM, and establishing high-level technical architecture. Let’s say that our team lead is fully allocated to this project and can spend 35 productive hours a week on this initiative. Some agile teams have dedicated Scrum masters, however, we’ve split this role between the Team Lead and the PM.
We may also need a designer, a quality assurance analyst (because we want to automate our testing throughout delivery), and an additional engineer for delivery bandwidth.
By the time we’re finished building our cross-functional team we are looking at roughly four full-time employees. There are more members in the team, but some are only partially allocated and/or shared across several projects. A team of four burns approximately 140 hours a week, or 390 hours a sprint (2 weeks x 35 hours x 4 FTEs).
The benefits of Agile surface when we can iterate over the product, building small, functional pieces of the overall deliverable, testing with customers, and revising as we go. Let’s give the team some room to fail and improve, setting our overall project length at six sprints. At 390 hours a sprint and 6 sprints, we can safely say that the smallest project that we can attempt to do with Agile is around 1,680 man-hours. It’s fine to start with the estimate your team prepares for waterfall delivery and then attempt to ship it using Agile.
You’re going to run into a lot of naysayers who will tell you that most enterprise projects are difficult to break down into smaller components. That’s simply not true. Dig deep enough and each product, each technical implementation, can be distilled into sub-components that are perfect fits for iterative delivery.