The purpose of this article is to provide project managers and business analysts an example of choosing a hybrid solution development life cycle (i.e., combination of agile and waterfall). Much discussion has transpired on the virtues of agile and waterfall approaches. Developers have claimed successes and failures using both approaches. Depending on the project and team conditions, there are advantages to using one approach over the other. Some firms have developed a hybrid Solution Development Life Cycle (SDLC) that incorporates both approaches in a project. Using a Business Process Modeling and Notation and the Decision Model, this article provides a model to help project managers and business analysts develop of their own Hybrid SDLC.
Note this is an expansion of an article I published in 2010 under the title “The Hybrid SDLC” at www.bpminstitute.org.
The Project “Kick-off”
Imagine a progressive firm that engage in both agile and waterfall approaches of system development. Their Project Life Cycle (PLC) includes a Hybrid Solution Development Life Cycle – not only allows for agile and waterfall, but a mixture on the same project. The goal of the project managers and business analysts is to select the best development approach based on the characteristics of the project and the team.
In this company, all projects start with a project request (charter) from a stakeholder (sponsor). The business analyst “kicks-offs” the project by facilitating a vision and scope (boundaries) meeting with the project manager and stakeholders. The details tasks of this meeting are to develop a project description with risk sources and economics (as needed), construct “As-Is” and “To-Be” business model and then conduct a gap analysis with the following deliverables:
-
process improvements (source of benefits)
-
software features to facilitate those improvements
-
risk register consisting of assumptions, dependencies, constraints, and expected resistance
-
staff competencies needed
-
initial assessment on the appropriate SDLC [1]
During the vision and scope meeting, the project manager collaborates with the business analyst makes an initial assessment of the appropriate solution development life cycle (SLDC) for the software features based on the nature of the project. If it is a tame project or a messy project (i.e., a technical challenge rather than definitional), the initial assessment points to waterfall. However if the project is wicked or even a wicked mess (i.e., challenge is more definitional), the initial assessment points to agile. Note this is only the initial assessment; the project manager and business analyst have yet to review the development conditions of the project and team:
-
the need for formal documentation
-
a vendor package being used
-
amount of customer involvement
-
team development experience with agile approach
-
dedicated or part-time team members
-
physical separation between the customer and the development team
After creating the vision and scope, the project manager and business analyst review the project and team conditions to determine what SDLC or combination of SDLCs to use for a project. Note that, ultimately, the project manager decides on the approach(es) for the entire project or for various portions of the project.
Modeling the Selection of an SDLC
Figure 1 depicts the high-level tasks (
) of a hybrid SDLC selection and implementation process using a Business Process Modeling and Notation (BPMN) orchestration and collaboration [2]. The first pool represents the process “Develop Requirements.” It consists of two swim lanes with Business Analyst and Project Manger as actors. The second pool is a black box and does not represent a process, but only a swim lane with Stakeholder as the actor.
The Stakeholder triggers the Develop Requirements orchestration by sending (
) a project request message. Upon receiving the project request (
), the Business Analyst executes the task Create a Vision and Scope. The process flow (
) then has the Project Manager executing the task Review Project Conditions. During this task, the Project Manager decides on the SDLC: waterfall, agile or a combination (i.e., hybrid). Displayed on the Review Project Conditions summary task is an octagon (
) that links the task to a Decision Model [3].
The Decision Model (Figure 2) contains the criteria used to make the SDLC decision. In this case, the decision criteria consist of two Rule Family Tables (Figure 3 and 4). Note that the tables interrelate. The Solution Development Life Cycle table uses the conclusion of the Agile Team Conditions table to form its own conclusion. Using these tables, the Project Manager makes one SDLC conclusion for the whole project or different SDLC conclusions for portions of the project. The “inclusive or” gateway (
) after the Review Project Conditions task depicts that all or portions of a project can follow a SDLC of agile, waterfall or a combination of both.
The Agile Whirlpool
The agile pathway depicts the development of an Initial Product Backlog from the solution features identified in the Vision and Scope. The Business Analyst sends (
) the Product Backlog (
) to the agile team, represented in a separate pool “Develop Agile Software” and maintains it until the there is no remaining backlog. Upon receiving the Product backlog (
), the agile team builds the software in an iterative incremental cycle (
) while receiving feedback and approval from the stakeholder. When the product backlog is exhausted, the agile software is complete (
).
The Waterfall Pool
The waterfall pathway depicts the development of a Business Requirements Document (BRD) from the solution features of the Vision and Scope. After the stakeholder validates the BRD, the BA sends () the BRD (
) to the waterfall team represented in the pool “Develop Waterfall Software.” Upon receiving the BRD (
), the waterfall team constructs a technical specification and implements the software per the spec. After verifying with the spec and validating with the stakeholder, the waterfall software is complete ().
Back to Defining Requirements Process
Note that with both SDLC approaches, there is traceability back the software features identified in the vision and scope even though the scope under agile is much more flexible than under waterfall. In addition, the “Defining Requirements" process ends () when the BRD is complete and/or ( ) there is no remaining Product Backlog.
Figure 1. Hybrid Solution Development Life Cycle (click image to enlarge)
Figure 2. SDLC Decision Model Diagram
Figure 3. Solution Development Life Cycle Rule Family Table
Figure 4. Agile Team Conditions Rule Family Table
Recommendation – Develop Your Own
I recommend the readers develop their own Business Process and Decision Model on how to select SDLC approaches at their company. Use the above example as a starting point. Add processes, actors, tasks, and project / team conditions as needed. This effort hopefully will lead to a productive conversation between agile and waterfall proponents alike and will result in a Hybrid SDLC that everyone can support.
Author: Mr. Monteleone holds a B.S. in physics and an M.S. in computing science from Texas A&M University. He is certified as a Project Management Professional (PMP®) by the Project Management Institute (PMI®), a Certified Business Analysis Professional (CBAP®) by the International Institute of Business Analysis (IIBA®), a Certified ScrumMaster (CSMTM) and Certified Scrum Product Owner (CSPOTM) by the Scrum Alliance, and certified in BPMN by BPMessentials. He holds an Advanced Master’s Certificate in Project Management (GWCPM®) and a Business Analyst Certification (GWCBA®) from George Washington University School of Business. Mark is the President of Monteleone Consulting, LLC and can be contacted via www.baquickref.com.
[1] Monteleone, Mark, (2011), The Tame, the Messy, and the Wicked, www.modernanalyst.com
[2] Silver, Bruce, (2009), BPMN Method and Style: A levels-based methodology for BPM process modeling and improvement using BPMN 2.0, Cody-Cassidy Press
[3] Von Halle, Barbara, Goldberg, Larry (2009), The Decision Model: A Business Logic Framework Linking Business and Technology (IT Management), Auerbach Publications