Get certified - Transform your world of work today


The Big Lever

7 September 2012

Brian Barr
AgileTrailblazers, LLC

Projects, projects, projects! You know you don't like them, but do you know why? Is there a better approach? In this article, I'll outline why we've chosen to be project oriented in the past and why pulling "the Big Lever" toward release orientation is so important in making the move toward Agile solution delivery a real success.

In the Waterfall world, projects were all we knew. Someone in the business would come up with a big idea, then gold-plate the heck out of it with even more ideas. Once the requirements document got bloated with enough pork-barrel ideas, business would hand the document to the development team. Business would ask development to provide estimates for the project, get funding, form a project team, and then have the team build it. After 9 to 18 months, multiple change requests, and numerous budget changes, the team might deliver something close to what the business really wanted — well, close to what they wanted 9 to 18 months ago.

OK, so now you remember why you don't like projects. But why does/did this project-orientation approach exist in the first place? In Waterfall, projects provide a container for many aspects of the system-development life cycle (SDLC). Let's call these delivery elements: funding and approval, requirements, resource allocation, business intent prioritization, change management, development and testing execution, software packaging and release, lessons learned, and software capitalization. With all these delivery elements on board, the project becomes the heavy anchor for sinking solution delivery.

When moving full steam ahead to lean and Agile solution delivery, your organizational mind-set needs to flip "the Big Lever" from project orientation to release orientation.

First, let's cover what it means to be release oriented. In release orientation, the entire organization focuses on how to iteratively assemble the product increments produced across all development teams into packaging appropriate for scheduled releases to production. The release schedule is predetermined and well known throughout the business and solution delivery teams. (Dean Leffingwell referred to this as the Agile Release Train.) Rather than projects being scheduled for specific releases, business intent is broken down into the granularity of user stories, prioritized into a product backlog, built into product increments in Agile iterations, and then assembled into production releases. Because the backlog has the granularity of a user story, the top of the backlog that the team pulls from could have stories representing a variety of related or unrelated business intent. Therefore, we don't have to have the solution delivery team exclusively focused on one "project" but rather on getting whatever the business deems to be important prioritized at the level of a user story.

Another aspect of release orientation is that the whole solution delivery team is focused daily on answering the question, "Is the release heading toward success?" When delivering at a large scale, this question gets answered in daily team stand-ups and daily escalation meetings (in Scrum, these meetings would be Scrum of Scrum [S2] meetings, and in daily S3/Sx meetings as needed, based on the size of the organization). At the team stand-ups, the team sees whether or not it's on track for its iteration goals and identifies whether there are any impediments to resolve. At each successive escalation meeting, the team summarizes its progress, identifies any outlier teams, and raises any escalated impediments. Most important, in some layer of the Sx meetings, someone is identified daily as the owner of every raised impediment and that owner feels accountable to eradicate that impediment before the next day. Also, if any team is potentially jeopardizing the release, they will be asked to drop stories from the current iteration in time to unwind their efforts on that story. So there is always a priority put on the timebox of the release over the content of any release -- i.e., throw features off the Release Train if necessary to make sure the Train stays on schedule with high-quality releases.

So how do you flip "the Big Lever" over to release orientation? The key is to empower the organization to eliminate the need for a project container for many, if not all, of the delivery elements mentioned above. The most important muscle needed is the static allocation of teams aligned with business intent generators (or BIGs). By creating and allocating static teams based on an enterprise-level priority of business intent, the BIGs can count on a fixed capacity of solution delivery and not worry about gold-plating their requirements — their team(s) will be there for them for the long haul.

Approval for funding solution delivery can be applied based on the team allocations for each of the BIGs informed by the enterprise priorities. Rather than packaging elements into large requirements documents, BIGs work with the static teams to continuously define, refine, and prioritize a product backlog and manage change through that. Development and testing execution happen in iterations against the user stories pulled into the iteration by each team allocated to the BIG. Software is packaged and released based on which shippable product increments the business and solution delivery teams believe are market ready (feature-viable) for production. Lessons learned get accomplished in each team's iteration retrospective and at a higher-level release retrospective aimed at making the process of packaging and releasing the assembled product increment better in the very next release. Software capitalization can be done incrementally by tracking the costs of producing the assembled and released product increments as part of the solution delivery execution. With all of the delivery elements covered in a lean and Agile delivery model, the need for projects can be entirely eliminated.

Unconstrained by a project container, continuous business value delivery (CBVD) and rapid solution delivery flow become possible.

So, if you are moving to Agile solution delivery, flip "the Big Lever," throw the idea of projects overboard, and make release orientation the course on which your Agile ship runs.

NOTE: Edited to include image

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 0 (0 ratings)


Rex Lester, CSM, 1/2/2013 2:45:04 AM
I enjoyed this article. It identifies a key issue in the change from projects to releases i.e. the static allocation of teams. In the PM world there seems to be some idea that if the project isn't using a team it has zero cost to the business when in reality you can't just hire and fire them. Any financial gaps (time when the team isn't on a project) are of course made up by charging a raised recovery rate to the project ;o)
Girish Chawla, CSM, 11/4/2013 7:45:24 AM
Great article. Some things to think about.
1) How do you measure the effectiveness of BIGs and hence the effectiveness of a release ? With projects you have a Business Case which is a living breathing document and which has the Cost/Benefit Analysis and Benefits Measurements.
2) Can you have multiple BIGs per release or mutliple releases per BIG ? I think these scenarios are plausible and can lead to a lot of complexity in the distribution and synchronization of work especially in the case of multiple BIGs per release.
Raghu Challapilla, CSP,CSM,CSPO, 12/2/2013 3:56:32 PM
Great article!

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up