Hybrid Projects. Approaching something that doesn’t exist.
Warning: The following article discusses approaches and opinions that are not CST approved. Special “Trigger Warnings” need to be observed for any Agile purists reading this article. Whilst we agree that hybrid projects shouldn’t exist and is a symptom of Agile implemented incorrectly, it does not change the fact that Scrum Masters all over the world are in these types of projects. This article can help guide our fellow Scrum Masters to try and make sense out of madness.
A note from the author
It’s important to state that “hybrid” projects shouldn’t exist in an Agile world. If you are starting up a new team, or your team is at the very beginning of your project journey, the word “hybrid” shouldn’t be entertained whatsoever. If you’re lucky enough to correct your team’s course at the beginning – please do so. This article is for the rest of us when it’s too late, and we must bravely soldier on.
It was the second day of my Certified Scrum Master training when the question popped up from another student: “What are hybrid projects?”. Our trainer, a brilliant guy, looked like someone had just asked him where to find a 3-legged man. He quickly replied: “There’s no such thing!” leading to confused faces throughout the classroom – mine included.
I’ve been working in Agile-based environments since 2015. Granted, back then the whole approach to Agile ways of working was very much in its infancy in most workplaces. So it comes as no surprise that most projects up until then were definitely rooted in old-school “waterfall” approaches to managing projects and teams. When the organization I was working in decided to shift to Agile ways of working, we saw a gradual shift in approaching projects with teams. It wasn’t an overnight “We are using Agile from tomorrow!”.
Many projects were still in flight. Projects were planned and designed around the waterfall method of project management and delivery. Those projects had set deadlines and budgets which were communicated to the stakeholders. We couldn’t just pause those projects, replan everything around Agile principles and then continue on without severely affecting the deadlines and budgets. But the direction was given by leadership teams that we had to start adopting Agile ways of working in our teams on new, and existing projects. That was when I first dealt with something, that according to many CSM trainers out there, doesn’t exist. A project planned and designed around waterfall methodologies but with a shift to Agile delivery methods. A “hybrid” project.
So “hybrid” projects do exist?
Yes, they do, and they are more common than you might think. You might even be working in one right now and not realize it. One of the reasons why I was so confused when my CSM trainer confidently stated that hybrid projects do not exist is that not only do they exist, but there are various reasons why they definitely should exist.
We’ve already touched on businesses adopting Agile ways of working because they realized the benefits Agile’s methodology would bring to their business and projects. Obviously, with such an undertaking there would be an adoption phase or a “transitioning phase” where current ways of working are modified or changed completely for the newer approaches to their project management. In-flight projects, those that were not quite landing yet but doing well enough, would start seeing influences from these new ways of working and so become hybrid projects. You could argue that those projects should be completed according to their designed approach, such as waterfall, but that can’t happen in most cases because not all projects are that short-lived. Some would take months or years to land and the business would have wanted to adopt Agile ways of working long before then.
Another, sneakier way in which hybrid projects have come into existence is by other methodologies and approaches being present from the start in even the most honorable Agile project startups. Approaches like Extreme Programming, albeit also an Agile methodology, have muddied the waters to such an extent that most projects utilizing scrum use terms that are not scrum-based at all. Ever called your retrospective or sprint planning a “ceremony”? That’s from XP (extreme programming). In Scrum, we “should” call them events. I put “should” in quotation marks because most of us, in the real world, have adopted these words as interchangeable and we all understand their meaning. So not only do hybrid projects exist, but they’ve become the norm in most cases.
As Scrum Masters, how do we approach hybrid projects?
To answer that question, we’ll focus on the most common scenario you might face as a Scrum Master; a project that was planned and designed using Waterfall but for some reason beyond your control, it was decided to use Scrum to deliver the work in Sprints – more than likely because others teams have moved over to Sprints as well.
Let’s assume you have the benefit of time (and budget) to try and switch from a Waterfall project to an Agile approach. Here’s what you can do:
Step 1: Assess the Current State
Begin by understanding the project’s current status, including its requirements, scope, timeline, and existing documentation. Identify the reasons behind the decision to switch to agile and gather insights from the project stakeholders.
Step 2: Formulate an Agile Plan
Establish a clear plan for the transition. Define the project’s new objectives, identify the key agile principles to adopt, and determine the specific agile practices that will be implemented. Collaborate with the project stakeholders to align expectations and ensure a shared understanding of the transition plan.
Step 3: Assess the Impact
Evaluate the impact of the transition on the existing project deliverables, timeline, and resources. Identify any potential risks or challenges that may arise during the transition and develop strategies to mitigate them. It’s important to manage expectations and communicate any necessary adjustments to the project stakeholders.
Step 4: Revisit Requirements and Prioritize
Review the project requirements and break them down into smaller, manageable units called user stories or features. Prioritize these based on their value and dependencies. Engage with the stakeholders to ensure that the revised requirements align with their needs and expectations.
Step 5: Assemble an Agile Team
Establish a cross-functional team that comprises members with the necessary skills and expertise to deliver the project using agile principles. Encourage collaboration, self-organization, and accountability within the team.
Step 6: Define Iterations and Release Plans
Break down the project into iterations or sprints, each focusing on delivering a set of prioritized requirements. Define the duration of each iteration and plan for frequent feedback and review sessions with stakeholders. Determine the release strategy to ensure that value is delivered incrementally.
Step 7: Adapt Project Management Practices
Adopt agile project management practices such as daily stand-up meetings, backlog refinement sessions, sprint planning, and retrospectives. Emphasize continuous communication, transparency, and adaptability throughout the project.
Step 8: Establish Feedback Loops
Regularly engage with stakeholders to gather feedback on delivered increments and incorporate their inputs into subsequent iterations. This iterative approach allows for flexibility and continuous improvement.
Step 9: Monitor and Track Progress
Use agile project management tools and techniques to monitor progress, track tasks, and manage the project backlog. Maintain visibility into the team’s velocity, which helps with forecasting and adjusting expectations.
Step 10: Learn and Iterate
As the project progresses, embrace a culture of continuous learning and improvement. Encourage team members to reflect on their processes and identify areas for enhancement. Adapt and refine the agile practices based on the team’s experience and feedback.
If all else fails, you’re going to have to make an Executive Decision
And just like Kurt Russel, you’re going to have the land this thing even though you’re way out of your comfort zone. Bad movie jokes aside, sometimes the solution will depend on you, as a Scrum Master, to operate outside of your Agile principles and adapt yourself to the project rather than forcing the project to change around you.
“But then it’s not an Agile project” I hear you scream. You are 100% correct – and the reality that you have to face is that very few projects are pure Agile projects. This isn’t something you’ll learn in your CSM certification. You’ll need to bring your experience with you and an open-minded attitude to work with projects and teams that function, and function well, outside of the principles preached by Agile evangelists.
Be the change you want to see
You’re stuck between a rock and a hard place. The project is hurtling along at a staggering pace, the team seems to be performing well enough but you, and everyone else in the team, is fully aware that this isn’t an Agile project – but logic be damned, this plane has to be landed using Agile principles. So what can you do, as a Scrum Master, to add value to your team in a project that defies our sacred Agile principles at seemingly every turn?
Take a step back, and breathe
You’ve been placed in the project because they needed a Scrum Master. You’re not there to wave a magic wand and erase every single obstacle that comes your way. What your team needs is someone to coach them on what Agile principles look like in practice, and, most importantly, someone who is a team player willing to get their hands dirty to get stuff across the line. What they don’t want is a micro-manager or someone who is so hell-bent on Agile principles that they try and reinvent the wheel every second day, slowing the team down or worse, bringing everything to a halt.
Bring strength to the common elements
Whether it’s Agile or Waterfall, there are commonalities between them that you can focus on to enhance within your team and project. This has the benefit of not changing anything drastic in your team, so you won’t make your team feel bewildered by new ways of working suddenly and it still adds a lot of value to enhancing what they’re already familiar with.
Some common elements between Agile and Waterfall projects are:
- Planning Activities
- Project Management Practices
- Documentation
- Quality Assurance
- Project Closure
Looking at the list of commonalities between the two methodologies, you can use your intuition and Scrum knowledge to tweak existing processes or introduce new ones to enhance those aspects of the project.
Planning activities, for example, are easy to tweak because your team would have already agreed on Scrum as its delivery method. So Sprint planning wouldn’t be an unfamiliar entry in your team’s meeting calendar. Your value-add as a Scrum master is to guide these sprint planning sessions to focus on the goals of the sprint. The sprint’s capacity might be tricky to adhere to and the word “velocity” may be blasphemy to your team, but goals are universal to all teams – so focus on that as a start.
Project Management Practices are easy to add value to. Your team probably has a project plan or some “idea” of what needs to be delivered and the deadlines involved. Create a sprint roadmap for your team outlining the major features and the planned sprints where they’d be likely to fall based on predetermined deadlines. Miro boards are amazing for this.
Documentation could be enhanced by making sure your team has a common place to add their documentation based on the project. You’d be surprised how many teams don’t have agreed-upon methods for activities like documentation and communication. Add value to the team by creating a scaffold for them to work with that serves everyone in the team. I have a preference for Atlassian’s Confluence, but there are many online documentation solutions. The important part is that the team uses the same solution in the same, consistent manner.
Quality assurance is a vital part of any successful project. While the execution and timing of quality assurance activities may differ, both waterfall and agile recognize the need for testing, quality control, and validation to ensure that the project meets the desired quality standards. Add value to your team by asking your testers if they have what they need to complete their tasks in a timely manner. Testers usually fall under a lot of pressure due to inefficient processes within the team and work handed over from developers near the very end of a sprint.
Project closure is easy to adapt to. Whereas most big waterfall projects have one big-bang release, Agile practices such as Scrum have Sprints that release at the end of every Sprint cycle. Help your team by ensuring that everyone understands what will be released at the end of a sprint (if anything) and that the release process is documented and communicated to all parties involved.
Be patient. Be consistent and stay positive. The worst thing you can do, as a Scrum Master, is to introduce sudden and jolting changes to a team that is already operating at pace. Small, corrective changes will help guide your team to their destination over time without capsizing the boat. This is a long race, even if it’s based on “Sprints”.
In the end, remember the Human
Your team, hopefully, consists of a bunch of people all working together towards the same goal. Like any other person, they have stuff going on in the background of their personal lives and they’re working to make a living. Scrum Masters have a fantastic opportunity to look after their team, in terms of project (sprint) performance and individual performance. Even when a project is doing technically well, your team could be in desperate need of someone willing to listen to the people in the team and help promote the team’s mental health and morale.
I’m not telling you to listen to your team’s individual mental problems. Let’s face it, we’re in IT. We have many mental problems of varying degrees every day and there is professional, medically trained help for that sort of thing. However, as a Scrum Master, you are obligated to observe your team and recognize the signs and symptoms of underlying issues and provide help in making things easier. Whether it’s enhancing a process, connecting people with the right stakeholders or simply spreading the workload between your team.
A perfect opportunity presents itself in Sprint Retrospectives. I’ve always been gobsmacked by how many teams simply skip over their sprint retrospectives because they’ve either not been introduced to them before, or, they were facilitated by “scrum masters” who didn’t care for them. I ensure that my teams always have a retrospective after every sprint. How I facilitate successful retros is an article on its own, but the fact is that I never allow the team to skip them because they provide extremely valuable insights that would never come to light otherwise. Sometimes a team would raise an important issue that they never knew was hampering them until they were given the opportunity to talk about it and present it through team communication.
Retrospectives are really a topic on their own. They allow any team to grow meaningfully and go from strength to strength. An amazing Agile Coach once told me that for every thousand teams rustling the tree-tops, there’s only one team picking at the root. What it means is to get into those deeper conversations with your team during retros. But I digress, that’s a topic for another time.
Don’t forget, Servant Leadership is at the heart of every true Scrum Master. Put on your EQ shoes and give your team members someone they can rely on. Someone who can cheerlead trust in the team and whom they can trust to approach when things become a little too pressured or if they simply become annoyed. Your role as a Scrum Master is to remove obstacles for your team, and even if you’re caught up in a project that is the exact opposite of what Agile principles recommend, remember, you’re still dealing with people – and that stays the same whether you’re in an Agile project or not.
