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