Shifting from a Project-Oriented to a Release-Oriented Organization
4 January 2016
Before we understand why we need to make a shift in the project-orientation paradigm, let us consider the preexisting Waterfall model, reasons for its existence, and the problems with applying it. Then we can move toward the solution we provide for the problems through the Agile model.
The Waterfall world is entirely project oriented. A typical scenario for project completion: The client comes up with an idea, mostly a very unclear one, and tries to explain to us the product it needs. The requirements team tries its best, by various means, to figure out the exact definition of the project. Then the requirement team sends the requirements document to the project team, which estimates the budget and the feasibility of the project. When the project estimates are done, a development team is formed, and the product is built.
After 9 to 18 months, the client checks the product, suggests changes, and, according to the budget, has the product altered. After a series of changes are made, the product, which is close enough to what the client wants, is delivered.
The Waterfall considers all of these as deliverables: funding and approval requirements, allocation of resources, prioritization of business intents, effective change management, exclusive execution of development and testing, packaging and release of developed software, intervening lessons learned, and capitalization of the software. And when the focus is on so many elements, the main output of the solution delivery to the client is diluted to a more than tolerable state, and the projects fail miserably.
For this reason, an organization may move to Agile and its delivery mode. When it does so, it has to make a mindset shift from product orientation toward release orientation. In the release orientation, the major focus is on how to iteratively assemble the product increments from the various teams and appropriately package them for release productions. The organization concentrates on user stories, prioritizes the product backlogs, and then builds the increments using iterative Agile methods and assembling them into product releases. As the user stories are considered backlogs in advancing the increments, the delivery team need not really focus on the product solution. Instead, the team must focus on understanding the user needs.
Another important feature of the iterative process is a daily stand-up meeting whose mission is to answer the simple question: Is the release heading toward success? The impairments in product development are identified and eradicated by the next day. Most of the time, one team member is responsible for getting rid of the impairments found on this day and making the proposed amendments to the iteration by the next day's meeting. Also, if there is a particular team that is causing a complete delay in the increment's release, that team will be left out for this increment and will catch up with the project by the next iteration. This gives more scope for high-quality quick releases than nominally getting everything in place.
How to make the mindset shift?
The important step in making the mindset shift is to align the static allocation of teams with business intent generators (BIG). The list of requirements is always prone to iterations after the product development stage. Therefore, instead of developing a lengthy document with the list of requirements, the BIGs associate with the static teams to constantly define, refine, and prioritize a product backlog and further manage the newly evolved change. Development and testing execution are processes that involve numerous iterations that are particularly based on the user stories. The software is released with the increments that can fulfill the project requirements with each release and defer those with unclear deliverables to the next iterations. Project capitalization is determined by calculating the costs of each increment and releasing dynamically, and adding it as a whole.
With this approach, everything is aimed at the release and not on the project as a whole. Dynamism is incorporated into the product development strategy, with a flexible way for the iterative product release.
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.
Current rating: 4.6 (5 ratings)
The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.