How Release Complexity Develops Over Time

Your organization starts with a simple mode - a single project will have two week “sprints”.  Every two weeks you are going to aim for a release to production.

This model works well up to a certain scale.  Teams of 4-5 developers working alongside a 1-2 QA testers on a small project are able to keep up this two-week cadence, but once the complexity of your project and the size of your team reach a certain size your two-week sprints turn into something like this.

“Two” week sprints now take three weeks.  As software becomes more complex “Dev complete” never really means that development is “complete” it just means that initial testing can begin. Timelines start to become compressed towards the end of your release cycle because you still operate under the assumption that your sprints are two weeks.

As your team grows you realize that you need more than one team to parallelize effort and get software to market faster. Your simple, one-team schedule then turns into this:

This is when organizations really start to feel the challenge of release management.  When there are multiple teams working on multiple tracks simultaneously there’s more overhead. Coordination becomes time consuming.

Individual teams may have dedicated QA resources, but in this multi-team schedule you’ll see that integration testing is performed by a central Quality Engineering team and releases are funneled into a central Release team.   As development shifts to a multi-team approach you’ll also notice that the timelines increase.  What took two weeks to release now may take up to six.  Timelines are longer and there is more risk associated with the development effort.

This model scales up to a certain point, but it has limits.  Project and release managers across multiple teams have to understand the internals of other projects.  Team A has to coordinate closely with Team B and as this model scales to more than 40 developers and three teams the interdependencies become unmanageable.

This is when most organizations start to shift to multiple departments or application development groups grouping similar teams together.  Here’s a simplified view of this approach:

This is a model of a large organization with multiple, independent departments each consisting of multiple, internal teams.  Consider a large organization such as a major retailer or a large telecommunications company.  In these organizations you’ll have hundreds or thousands of developers distributed across multiple departments.

Each department will manage a separate, independent release timeline for the projects it contains, but the organization may also define specific milestones.  Take a company like Apple as an example  - while the department responsible for iPhone software development is distinct from the department that is responsible for oneline e-commerce, both must collaborate and unit test as the holiday season approaches.  This is where multiple, independent departments need to collaborate and coordinate to achieve organization-wide milestones.

And, this is the where having a unified view of release timelines and environments is a requirement. If you find yourself in an organization like this without a tool like Plutora you understand the impossibility of this management challenge.  At this stage you either use a comprehensive tool that can give your manage a snapshot of release status or you oversimplify and accept inefficiency.

We’ve skipped a few stages in the development of a release timeline, but when you’ve been involved in a software project that has grown over time you understand that these transitions can happen very quickly.

One day you might be looking at a team of 10 that can reasonably expect to release software every two weeks, three months later you might be in the middle of a complex, multi-team development environment. In some organizations in only take a year or two to grow to point of having departments.

Plutora works with a range companies some with a handful of projects and many that have 30 or more major application development groups spread across multiple departments.   Our software provides you with the ability to model different kinds of releases and our design goal is a tool that can support your releases, your milestones, and your internal process.

We’ve designed our tool with this range of complexity in mind because we’ve seen it all.  Every project is different and every organization has a unique approach to software releases. The secret to running efficient, repeatable releases that manage risk is to understand that different releases require different models.