Many times, managing a Hybrid-Agile project with a sole Lean-Agile approach doesn’t meet the needs of an organization, the expectations of stakeholders, required delivery frequency of customers, or address uncertainties associated with engineering work. In certain cases, it may be necessary to employ multiple Lean-Agile approaches to manage hybrid projects.
For example, in some projects, it’s possible that you are employing a traditional or predictive (i.e. Waterfall) approach for certain phases of the project, followed by an Agile approach for subsequent phases. In the phases with an Agile or adaptive approach, you want to have a combination of adaptive approaches – say a combination of Scrum and Kanban.
Such a model would be called a Hybrid-ScrumBan project. This is because you used the frameworks of Waterfall, Scrum, and Kanban within a single project! I’ve derived the word ScrumBan by combining Scrum with Kanban.
To best understand our Hybrid-ScrumBan scenario, we will proceed using MS Project.
Hybrid-ScrumBan Scenario
In our scenario, a construction organization is building a “Smart” home. This project is built-upon a previous article in which I explained the management of a Hybrid-Scrum project. I strongly suggest that you read that one first to understand this piece better.
This project is largely focused on development, employing both Waterfall and Agile. The security related features are to be delivered in a number of Sprints, following the Scrum framework. The features completed will be first delivered to a team of internal customers within the organization. This group will get the first opportunity to check the features and raise their concerns, expectations, or issues, before it goes to the actual customers.
When features are delivered to the internal customers, they will raise tickets. These internal customer tickets will be fixed following the Kanban framework. As you can see, in this case, we’ve already employed Waterfall, Scrum, and Kanban making this a Hybrid-ScrumBan project. It’s represented in the following figure.
In this Hybrid-ScrumBan project:
- The first few phases, such as Start-up and Planning, occur only in the Waterfall or Predictive mode.
- The large Developmental phase employs both Predictive and Agile approaches. Specifically, I’ve set up a Scrum framework which will run in parallel to the Predictive development work. The security features will be developed in the Scrum mode.
- Subsequent to the Development phase, there is another Kanban phase, where the Kanban team will fix all the tickets raised. Note: It’s possible that there will be some overlapping between the development work and ticket fixing work.
- Towards the later part of this construction project, we have phases such as Test, Deploy, and Close, which are again following a Predictive mode.
Let’s start with planning for the Traditional part!
Begin with the Traditional
This part of the project is somewhat straight forward with all the possible phases and associated tasks arranged. As you work on it, we have the following view in MS Project Online Desktop Client, which contains the Agile features.
As you can see in the Development phase, we have two sub-phases:
- Predictive Home Development, which is in Waterfall mode with all tasks clearly defined.
- Scrum Home Security Development, which is in Scrum mode (a placeholder for now). We will build this portion next.
Build the Scrum Part
The security related features are to be delivered over the Sprints and so, I’ve added the features under the Scrum Home Security Development sub-phases. The word “Feature” prepends each of these tasks to distinguish them from other task items in the project.
The fundamental block in Scrum is the Sprint, which actually sets the heartbeat of Scrum with its weekly/biweekly (or any other) cadence. Hence, we will plan for the Sprints by going to the Project tab > Properties group > Manage Sprints command.
As shown, I’ve created five Sprints for this project, each with a two-week duration.
Next, we have to break-down the features into tasks, and associate the Sprints with the features and tasks. We also need to add all the Scrum events, which results in the following view:
Note the following:
- Features for Sprint 1 have been broken down into tasks and associated with the first Sprint.
- All Scrum Events such as Sprint Planning, Daily Scrums, Sprint Review, and Sprint Retrospective are available for the current Sprint. To understand more about how to build a Sprint Backlog, you can refer to this article.
- Scrum related items are associated with the IsAgile custom field, which informs if the work item is Agile related or not. To understand how this field is going to help in a Hybrid-Agile project, you can refer to this article.
- The Show on Board built-in field has been associated with the needed items for the Scrum part of this Hybrid-ScrumBan project.
- Other features, such as Feature – Smart App Integration, Feature – 24*7 Monitoring, etc., are associated with other Sprints such as Sprint 2, Sprint 3, Spring4, and Sprint 5.
The featured items to be delivered over the Sprints can be seen in the Sprint Planning Board view.
At this stage, our project is still a Hybrid-Scrum project, not a Hybrid-ScrumBan project! For that, we have to follow some more steps, which we will do next.
Build the Kanban Part
As explained earlier, the internal customer raised tickets will be addressed in Kanban mode.
Let’s assume the current Hybrid-ScrumBan project has progressed for some time and we have completed one feature within Sprint 1: Feature – Smarty Entry.
This is the current situation within our project on the status date, which is set to Monday, 17th October’22. The status date is in red color coding and it’s highlighted.
As shown in the above figure:
- The Scrum team has completed Feature – Smart Entry, and all its associated tasks. It’s showing 100% complete in % Complete built-in field.
- Events such as Sprint 1 planning and a few Daily Scrums are completed. This is shown with the tick mark in the indicator column.
- A number of Phases for the Predictive/Waterfall part – the Start-up and Planning phases – are also complete.
As this feature was completed, it was delivered to the internal customer team. The team raised a number of tickets, which have to be fixed by the Kanban team. Hence, we have to add those tasks and plan for them in our project.
For this purpose, I’m going to add another phase in the current Hybrid-Scrum project, named as Kanban – Internal Customer Review. In this phase, we are can plan for all the tickets and assign the Kanban team members accordingly.
As shown in the above figure:
- There have been five tickets raised by the internal customer team, which are under the Kanban – Internal Customer Review phase. These have been assigned to Kanban support engineers.
- None of the tickets under this phase have any Sprints associated with them because the team is fixing the issues on-demand—and, of course, Kanban doesn’t have a concept of Iteration or Sprint. This is highlighted as “No Sprint” under the Sprint column for the ticket items.
Next, we are going to add another custom field to distinguish between the Scrum and Kanban work items of this project. This will be needed for further visualization, grouping, filtering, tracking, adjusting, monitoring, among others.
The custom flag field will be a IsKanban field, which will be enabled only for Kanban work items. With it, the view is shown below:
Note: we have enabled the IsKanban field only for the Kanban related work items.
In addition, here some important points:
- Show on Board field has been enabled for Agile related items, including both Scrum and Kanban work items, except a few, depending on the need.
- The IsAgile custom flag field has been enabled for all Agile related items – both for Scrum and Kanban work items.
- Sprint Start and Sprint Finish dates are included because it helps to parallel plan (features’ planning in Scrum mode and tickets’ planning in Kanban mode).
Integrated Hybrid-ScrumBan Project
Now our Hybrid-ScrumBan project is ready! This is shown in the below figure with clear segregation between the Waterfall, Scrum, and Kanban parts of the project.
At this stage, you might be wondering:
- Can one visualize only the Scrum part of the project in Scrum Board and Sheet views?
- Can one visualize only the Kanban part of this project in different views?
- Are there really any separate Kanban views to visualize?
The answers to the above questions are: yes, yes, and yes!
To visualize only the Scrum part of the project, you can use Sprint Planning Board and Sprint Planning Sheet views. You can also use the Current Sprint Board and Current Sprint Sheet views. Below is a depiction with the Current Sprint Board view.
To see it in a spreadsheet representation, you can use the Current Sprint Sheet view. In the below figure, I’ve applied a custom grouping with Sprint and Task Summary Names.
To visualize only the Kanban part of the project, you can use Task Board and Task Board Sheet views. You can also use Backlog Board and Backlog Sheet views. Below is a depiction with the Task Board view.
Do note that I’ve applied the custom Kanban filter in this Task Board view. This is highlighted in the above figure. The Kanban filter takes the previously created IsKanban field and ensures only Kanban related items are shown in this view.
You can also see the work items in the Kanban part of the project in the Task Board Sheet view. This is explained in more detail in the below videos.
In the above figure, I’ve applied the built-in Board Status group, which informs on the Kanban work items falling under individual workflow states of the Kanban board.
Analysis and Key Points
Now, let’s have the analysis, followed by some important points to manage Hybrid-ScrumBan in the below videos, which I’ve prepared for this article. The content is taken from my new course: Certified Hybrid-Agile Master.
Because Hybrid-ScrumBan projects are quite complex, I’ve divided this content into two videos to cover multiple key points. The first part is explained in [duration: 6m: 18s]. For the best experience, you may want to go full-screen in HD mode and plug-in your earphones.
The second part [duration: 4m: 29s] elucidates further key points and is in continuation of the previous video. This part emphasizes a mindset change as you traverse through the Waterfall, Scrum, and Kanban parts of the project.
Conclusion
Organizations do combine multiple Agile approaches (for example, Scrum with Kanban), but such are most often considered to be a Blended Agile model, not exactly a Hybrid one.
While such Blended Agile projects can be managed, when it’s a Hybrid-Agile project with a single Agile framework, the complexity goes-up. For a project employing multiple Agile approaches, along with predictive mode, the complexity goes even further.
This is because of a wide array of principles, practices, artifacts, roles, responsibilities, and associated events. In addition, as you work to create a hands-on tool, you also need to have a sound understanding of the software tool being used to manage such Hybrid-Agile projects.
It’s my sincere hope that you got a fair understanding of managing a Hybrid-ScrumBan project with MS Project. As always, your comments, feedback, and suggestions are welcome.
References
[1] NEW Certification Course: Certified Hybrid-Agile Master with MS Project, by Satya Narayan Dash
[2] NEW Online Course: Mastering MS Project 2019 Agile (Scrum and Kanban), by Satya Narayan Dash
[3] Online Course: PMI-ACP Live Lessons, Guaranteed Pass, by Satya Narayan Dash
[4] e-Book: I Want To Be A PMI-ACP, Second Edition, by Satya Narayan Dash
Eric Uyttewaal
Hi Satya,
You have stitched together Waterfall, Scrum and Kanban in one schedule in an interesting way. You state that you did this because the stakeholders involved required it. I see several important disadvantages of this blended approach as well:
1) As you indicate yourself: combining multiple approaches in one schedule makes the schedule more complex than it perhaps needs to be. The way you have planned the scrums could have also been done in a predictive way. The way you have planned the Kanban tickets could have also been done in a predictive way using Rolling Wave. Sticking to one approach keep the schedule a lot simpler. Alternatively, you could have done the entire project using Scrum.
2) The Manually Scheduled tasks in the Scrum and Kanban sections will make it impossible to display a Critical Path (since there are no dependencies and no dynamic rescheduling). So, the predictive part of your schedule has lost its main technique to analyze the schedule and to monitor progress.
3) Combining multiple approaches makes everyone loose the overview over the entire project. How are you going to report on the entire project once you have set up your schedule in this way? Predictive typically reports using the Critical Path. Scrum has its own burndown charts, and Kanban reports using the Boards. What type of report will provide the status on the entire project?
So, I have to ask the obvious question: With these disadvantages, what is the added value of this Hybrid-ScrumBan approach?
Satya Narayan Dash
Thank you Eric for your comment. I understand that you want the entire project in predictive/waterfall manner. Though predictive approach has its value, Lean-Agile approaches are taken up based on a number of factors, not just stakeholder need. I’ve written an article – Why and When to Go for Agile Life Cycle.
Coming to the perceived disadvantages, let’s see:
The principles behind Scrum, Kanban, Waterfall are all different. Kanban is delivery on-demand and deliver as quickly as one can, if capacity available. There is no iteration end to wait for. Rolling wave planning is a different concept. Tickets when raised are to fixed with high priority and as quickly as possible. Rolling wave planning doesn’t fit in.
The critical path (or paths) has no intrinic value for the Scrum Master. So, displaying critical path for the Scrum part of the project is not needed. The fundamentals are different. On other hand, depdencies can be there if needed for the manual tasks. In a recent article for building the Scrum Backlog, I’ve noted that.
For the 3rd one – reporting, of course, will be different with a number of possible reports, as it’s a hybrid project. Reports can’t be generated using Kanban board, rather using the underlying data. Board, however, follows an important part of Kanban, visualize the flow. There will also be multiple roles (looking at those parts and generating reports) in this project. With multiple reports, it should be consolidated at the manager level leading the entire project.
I’ve outlined one scenario here. There can be multiple scenarios for Hybrid approaches, some of which I’ve outlined in my earlier article related to Hybrid-Agile (specifically Hybrid-Scrum) project.
Hope it helps. And appreciate you commenting.
Kish Ranai
Hi Sathya
I am new in using Hybrid Project. My question is there a similar concept of Critical Path Analysis in a hybrid project using traditional predictive method and Agile/Scrum method? Basically can I find my critical path in such a hybrid model?
if there is none how do project manager monitor the whole project that things are moving along fine and there is no task that is delaying the final end date of the project?
Look forward to your kind reply.
Best Rgds
Kish