The year is 2005, and I have just uncovered a problem that was affecting 22 million people on our mobile prepaid network. After the momentary panic and managerial drama subsided, I was left with a list of approximately 4000 mobile accounts that needed to be reconciled with small individual amounts. The spreadsheet was handed to me by my senior engineer with a grin on his face, saying, “These need to be done before you go home today.” It was 4:30 in the afternoon. That was my first week as a VAS Support Engineer at a mobile telecoms company.
The next morning at the office, I reported back to my senior that the list had been completed by 8 PM the previous evening. He was impressed by my determination and proceeded to show me a very short shell script that could have reconciled the same list in 30 seconds. Seeing the blood drain from my face as he showed me this magical tool, he quickly explained that he didn’t want me to use that shell script because it was more important to learn exactly what, how and why things are done the way they are. I’m sure there was some level of sadistic pleasure involved, but the lesson was valuable nonetheless, and I don’t hold a grudge at all, Josh. Using that script incorrectly and without a proper understanding of the mechanics involved could have produced 4,000 mistakes just as easily as it could have fixed 4,000 problems, ultimately making things worse for all those clients and negatively impacting my career prospects.
Fast forward to today, and we live in an age where AI-enabled tools enable us to dramatically reduce the turnaround time on tasks that previously took days to mere minutes or even seconds. The questions are: Do we know what it’s doing? Do we know how it’s doing it, and the ever existential “Why” it’s doing it? Should we even care? (Spoiler: Yes, we should)
These are important questions to ask because they fit perfectly with anything else that forms part of a business. Anything of value operates on a What, How and Why level. Businesses, in their simplest form, can be categorized into layers of those three key areas. The “What” of the business. “How” a business goes about achieving its goals and, most importantly, “Why” it’s doing it in the first place.
It stands to reason that when we introduce resources or personnel into a business, they must operate in harmony with those levels and align with the business values. So, how risky is it to introduce a tool at every level of a business where we don’t fully understand how, what and why it operates?
Let’s take a quick look at the facts.
What does it do?
Taking the most popular AI tool on the market as an example, Chat GPT is a Large Language Model (LLM). It is designed to provide coherent and relevant responses to the input it receives. Most commonly, it engages in conversation with the user, helps with tasks, generates text (not unlike this blog entry, but I assure you, this blog post is fueled by late-night chocolate and ice tea and not AI), and more recently can even generate images that are getting more and more realistic and accurate. Essentially, it attempts to make you “feel” like a human is interacting with you from the other side of the screen. A very smart and well-read human.
How does it do it?
Machine learning. You’ve heard that term thrown around the office (or boring dinner parties) with reckless abandon. More specifically, though, these LLMs are trained using something branched off of that called “Deep Learning”. In a nutshell, it absorbs a vast amount of text-based materials from various sources, such as the Internet itself and then calculates the statistical patterns in the language. Things like which words follow others, which concepts appear together more often, and how tone changes based on context.
Based on all of that, the LLM can “learn” which words are statistically more likely to follow each other. That learning is then further refined by warm-bodied people and tweaked to ensure that it comes across as less machine and more “human”. So, when you type a question into this LLM, it searches its databanks and generates a coherent reply based on what it has been exposed to. There is no thought behind the reply. It is a repeat of information that it has assimilated with a massively impressive game of “rock, paper, scissors” to generate a reply that is coherent and grammatically correct.
Why does it do it?
There is no “why” in AI. It’s that simple. The closest a LLM such as ChatGPT can come to explaining why it “thinks” a suggestion is a good idea is that it references the number of suggestions made on that question or something similar, and it pushes the suggestion that is stated more often. That’s why Google AI infamously suggested eating rocks as part of a healthy diet, to glue pizza together and to use petrol to make a spicy spaghetti dish. These are (funny) AI hallucinations, but as much as they create a good laugh, they should also remind us that this new technology has flaws and could, potentially, result in a business crashing faster than my brain after midnight chocolate, or at the very least, some questionable spaghetti. It’s the old adage of “garbage in, garbage out”, but even in cases where the LLM has been provided the most relevant and correct information sources, it still manages to come up with questionable responses from time to time, and to date, no one has figured out precisely why. No pun intended.
Where is this going, Peter?
Circling back to how this information is relevant to the use of AI tools in our industry, and what it means to us, we need to ask why. As an industry that carries the interest and livelihood of millions of people globally, our “why” is our most important level in which we operate. People have a “why”. Machines do not.
Machines are amazing in the “how” and “what” space. We can analyse the data from farms and generate insights that were never possible before because machines use complex algorithms to spot patterns and reference thousands of white-papers and other academic resources in a millisecond. It can do something as trivial as summarising our meeting minutes, or it could save a life by spotting heart irregularities faster and more accurately than any cardiologist can by simply being better at calculating the numbers and odds. It can write a piece of code that generally does what you asked it to do.
But there are things that AI cannot do: It can’t efficiently write a piece of code with flair and ingenuity. AI provides code with massive inefficiency, and it cannot even fathom coming up with new and innovative ways to write that piece of code. It cannot respond to questions in a way that takes a person or their circumstances into account, because it cannot empathise or pick up on subtle emotional clues that everything might not be OK. It is completely incapable of following intuition, again, because it cannot think and does not have a gut-feel about anything.
Most of today’s iconic businesses exist only because their founders had hunches. They did something that no one thought was a “good idea”, and they turned left when everyone else was turning right. If those people relied on AI back in the day, we wouldn’t know about Microsoft, because it was a wacky kid interested in computers at a time when computers were a niche… and in his parents’ garage no less. We wouldn’t have known about Apple, because AI would have suggested Wozniak build a Chevy truck in his garage instead of a computer. Because a Chevy truck had a statistically higher chance of selling and making money. The stats, and by extension, an LLM would have said that’s a ridiculous idea.
There are other considerations to take into account, too. Many entry-level jobs are being replaced by AI tools. That’s great news for the business’s bottom line and its shareholders, but if you remove entry-level positions, how do you get new people into the industry and your business? University students will find it harder and harder to get their foot in the door because the bar to enter has been raised way beyond the ability of a “newbie” out of university. How do you enter your first job with 5 years of experience?
Studies have shown that people are getting dumber by the day because they’re relying on tools like ChatGPT to provide them with answers to almost everything. Critical thinking isn’t a thing anymore. People are using Google less and are simply asking their questions in ChatGPT. There’s less research happening and more copying and pasting from whatever ChatGPT spits out. If what I’ve seen driving on our public roads is anything to go by, we cannot afford to get any dumber. Don’t even get me started on what AI tools have done to our education system. Let’s just say in about 10 years, your doctor’s or lawyer’s certification may not be “well-earned”.
Let’s not forget about the impact the use of LLMs has on our carbon footprint, with AI data centres expanding exponentially and bringing massive energy consumption requirements with them.
Before you walk out
Don’t get me wrong. I love LLMs like ChatGPT and I use them fairly often. Without image generators like Midjourney, I would have no hope of ever creating illustrations that are usable in any way. I am not an advocate against the use of AI tools. I understand that they hold the potential to change our world, and it can swing in either direction, good or bad. I’m known for using the line “AI won’t replace you, someone who uses AI will”.
Like the internet back in the day, I know that AI technology is here to stay, and businesses need to adopt an AI strategy to remain relevant and competitive. Even in my role as a Scrum Master, I am constantly looking for ways to leverage AI in ways to boost my value to my teams and my clients, and I share that knowledge with my colleagues because I’d rather see us surfing the AI wave to new horizons than being swept away and drowned by it. Working smarter, not harder, is the way to go, after all, and I appreciate that after fixing 4,000 accounts manually. One by one. Josh.
We need to be vigilant and safeguard our ways of working and protect our “why”. We need to be cautious about which levels of our businesses we allow tools such as AI to gain a foothold. We need to ensure that we gain from AI instead of being replaced by AI. The only real way to do that will always be with people. Because people serve people best, and people understand why.
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.
If you’re working in an Agile environment, you’re probably thinking about two roles: the Scrum Master and the Project Manager. Both are vital to the success of a project, but they have different responsibilities and areas of focus. Today, we’re going to talk about the Scrum Master and the Project Manager, and I’ll tell you why they can’t be the same person, and how to spot recruiters and companies that don’t have a clue.
What is a Scrum Master?
Let’s start with the Scrum Master. This person is the facilitator of the Scrum process, but don’t mistake them for a Project Manager. No, no, no. The Scrum Master is more like the quarterback of the team, helping them work more efficiently and effectively. They do this by facilitating daily Scrum meetings, coaching the team on Agile principles and practices, and ensuring that the team is following the Scrum framework. Some of the key responsibilities of a Scrum Master include:
Facilitating the daily Scrum meetings
Helping the team to remove any obstacles that are preventing them from making progress
Coaching the team on Agile principles and practices
Ensuring that the team is following the Scrum framework
The Scrum Master is a servant leader who works with the team to help them achieve their goals. They are not responsible for managing the project, but rather for ensuring that the team is able to work effectively and deliver high-quality work.
What is a Project Manager?
Now, let’s talk about the Project Manager. This role is responsible for planning, executing, and monitoring a project. They’re the ones making sure the project is completed on time, within budget, and to the required level of quality. They plan and schedule the project, manage the project budget, monitor progress, manage risks and issues, and communicate with stakeholders. Some of the key responsibilities of a Project Manager include:
Planning and scheduling the project
Managing the project budget
Monitoring progress and ensuring that the project is on track
Managing project risks and issues
Communicating with stakeholders and managing their expectations
They’re responsible for the overall success of the project, and that means they’re accountable for ensuring that the project is delivered on time, within budget, and to the required level of quality.
Key Differences between a Scrum Master and a Project Manager
While both roles are important for the success of a project, there are some key differences between a Scrum Master and a Project Manager. Here are some of the key differences:
Focus: The Scrum Master’s focus is on facilitating the Scrum process and helping the team to work more effectively. The Project Manager’s focus is on the overall planning, execution, and monitoring of the project.
Responsibilities: The Scrum Master is responsible for ensuring that the team is following the Scrum framework and helping the team to remove any obstacles that are preventing them from making progress. The Project Manager manages the project budget, monitors progress, risks and issues, and communicates with stakeholders.
Authority: The Scrum Master is not a manager and does not have the authority to make decisions for the team. The Project Manager is a manager and has the authority to make decisions for the project.
Approach: The Scrum Master uses an Agile approach to software development and focuses on collaboration, flexibility, and responding to change. The Project Manager may use a traditional approach to project management and focus on planning, controlling, and executing the project.
Can a Project Manager also be a Scrum Master?
The short answer here is; No.
Project Managers tackle projects and objectives from very different perspectives to Scrum Masters. Whereas Project Managers focus on deadlines, Scrum Masters focus on the team’s delivery and the team’s overall well-being. Project Managers look after the business stakeholders, Scrum Masters look after the team. They usually work together in harmony, but simply cannot be the same person because it directly conflicts with their focus.
Many recruiters and businesses these days advertise for Scrum Masters and Project Managers in the same role. If you see those job advertisements, ignore them with enthusiasm. They more than likely are only looking for a Project Manager, but have added “Scrum Master” to the title because it’s something new and they want to seem relevant.
