The Hybrid SDLC

The purpose of this article is to provide project managers and business analysts an example of a hybrid system development life cycle (i.e., combination of agile and waterfall). Much discussion has transpired on the virtues of agile and waterfall approaches. Successes and failures can be claimed on both sides. Depending on the conditions of the project, advantages of one approach can be cited over the other. So enters the Hybrid SDLC that considers both approaches for all or portions of the project. Using a Business Process and Decision Model, a hybrid SDLC is provided as a blueprint to help project managers and business analysts in development of their own Hybrid SDLC.

A Project SDLC Story
Let’s imagine we work for a utopian company that accepts both the agile and waterfall approaches to system development. Project managers and business analysts collaborate on selecting the best approach for the system development life cycle (SDLC) on a project (i.e., both are familiar with agile and waterfall approaches).

In this company, all projects start with the business analyst facilitating a vision and scope meeting with the stakeholders. The result of the meeting is an “As-Is” and “To-Be” business model containing business requirements and rules, and a gap analysis consisting of features of a proposed system which may be for process improvement and/or software development; for the purpose of this article, we will focus on software development. The software features may be in the form of simple declarative statements or user stories stating user actions, benefits, success criteria, and constraints.

After the Vision and Scope meeting, the project manager and business analyst review the project conditions. For example:

• the need for formal documentation
• a vendor package being used
• amount of customer involvement
• physical separation between the customer and the development team

Per the conditions, they use a Decision Model (rather than a Rorschach Test) to consider what approaches or combination of approaches to use for a project. However, ultimately, the project manager decides on which approach will be taken for the entire project or for portions of the project.

Business Process and Decision Models
See the Business Process [1] and Decision Model [2] figures. The high-level business process is diagrammed using Business Process Modeling Notation (BPMN) using both choreography and collaboration pools; note most message flows are hidden for simplification. An “inclusive or” decision indicates that all or portions of a project could use either agile or waterfall or a combination of both.

Figure 1. Hybrid System Development Life Cycle (SDLC)

The Business Process model is linked to the Decision Model via an octagon in the “Review Project Conditions” activity. The project conditions used to form an SDLC conclusion for a project or portions of a project are stated in Family Rule Tables.

Figure 2. SDLC Decision Model Diagram

Figure 3. Solution Development Life Cycle Rule Family Table

Figure 3. Agile Team Conditions Rule Family Table

Post the SDLC Decision
Once the SDLC is selected, the business analyst acting as a liaison between the stakeholder and the development team either develops a Product Backlog or a Business Requirements Document (BRD). The stakeholders in turn participate appropriately as needed per the SDLC. Note that the Business Process depicts separate agile and waterfall development teams. This is in agreement with the lean principle of dedicated agile teams to meet the iteration time box goal. The waterfall team on the other hand may be multitasking between projects.

Recommendation – Develop Your Own
I recommend the readers develop their own Business Process and Decision Model on how SDLC approaches are selected at their company. You can use the above example as a starting point. Add process swim lanes, activities, and project conditions as needed. Hopefully this effort will lead to a productive conversation between agile and waterfall proponents alike and will result in an SDLC that everyone can support.

References
1. Silver, Bruce, (2009), BPMN Method and Style: A levels-based methodology for BPM process modeling and improvement using BPMN 2.0, Cody-Cassidy Press
2. Von Halle, Barbara, Goldberg, Larry (2009), The Decision Model: A Business Logic Framework Linking Business and Technology (IT Management), Auerbach Publications

About the 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 e-mail – mark.a.monteleone[at]sbcglobal.net.

For more information please visit www.kpiusa.com or www.thedecisionmodel.com.

Bookmark / Share This

Bookmark or share this with others.