Project Management

Voices on Project Management

by , , , , , , , , , , , , , , , , , , , , , , ,
Voices on Project Management offers insights, tips, advice and personal stories from project managers in different regions and industries. The goal is to get you thinking, and spark a discussion. So, if you read something that you agree with--or even disagree with--leave a comment.

About this Blog

RSS

View Posts By:

Cameron McGaughy
Marian Haus
Lynda Bourne
Lung-Hung Chou
Bernadine Douglas
Kevin Korterud
Conrado Morlan
Peter Tarhanidis
Mario Trentim
Jen Skrabak
David Wakeman
Roberto Toledo
Vivek Prakash
Cyndee Miller
Shobhna Raghupathy
Wanda Curlee
Rex Holmlin
Christian Bisson
Taralyn Frasqueri-Molina
Jess Tayel
Ramiro Rodrigues
Linda Agyapong
Joanna Newman
Soma Bhattacharya

Past Contributers:

Jorge Valdés Garciatorres
Hajar Hamid
Dan Goldfischer
Saira Karim
Jim De Piante
sanjay saini
Judy Umlas
Abdiel Ledesma
Michael Hatfield
Deanna Landers
Alfonso Bucero
Kelley Hunsberger
William Krebs
Peter Taylor
Rebecca Braglio
Geoff Mattie
Dmitri Ivanenko PMP ITIL

Recent Posts

Project Management Lessons From Soccer Teams

Plan for the Velocity of Change to Keep Increasing!

A Lesson About Communication in Times of Chaos

Innovation and Design Thinking, Part One

The Misunderstood Scrum Master

Viewing Posts by Christian Bisson

The Misunderstood Scrum Master

Categories: Agile

By Christian Bisson

Inspired by The 8 Stances of a Scrum Master (a great read if you haven’t done so already), I want to focus this article on a few of the “misunderstood” stances of the scrum master.

Recently, I asked colleagues to share what they think a scrum master does, and the answers revolved around organizing scrum events (secretary) or note taking (scribe). It’s even expected that they make sure the office has coffee (coffee clerk).

Although there is nothing wrong in helping the team with any of the above—especially when it’s a brand-new team figuring out everything from setting up their work station to getting to know each other—there is a line between helping and not fulfilling your potential as a scrum master. This is important for you as an individual, but also for the team in the long term (even if they don’t know it).

So how can we fix this?

Stop Doing It

As a scrum master, you have to factor in everything when making a decision about whether or not to do something for your team. So, if the team is used to you doing a task and all of a sudden you stop, this might have a negative impact.

On the other hand, it might be what they need to break bad habits. If you do stop doing it, the team will have no choice but to do it themselves. However, in this case, you should warn the team or give them a heads up that you will stop by the next sprint, for example.

Never Start Doing It

If you are new to the team, or the whole team is new, you might have the opportunity to simply never start doing a given task in the first place. Although it seems counterintuitive to “not help” the team, you’ll avoid creating any habit that will affect them in the long term—and will be challenging to break.

In this case, you should explain to the team that it’s everyone’s responsibility to handle these tasks and to build good habits from day one.

I personally did this with note taking a few years ago. It was challenging at first, but now I go to meetings without any apparent ways of taking notes, making it obvious that I won’t be doing it. (I do have my phone in case something important comes up that I need to note for myself, of course). Now in meetings, I’ve gone from the note taker to being able to focus on facilitating the meeting and help the team get the best out of the conversation.

In Conclusion

It’s quite challenging to avoid all the “misunderstood” stances of the scrum master, but we have to do our best to be true to the real value scrum masters can bring to teams.

What misunderstood stances have you fought against? How have you tried to combat them?

Posted by Christian Bisson on: January 21, 2020 11:57 AM | Permalink | Comments (6)

Lessons Learned From an Inspiring AI Project

By Christian Bisson

When I was asked to write about a project that inspired me in the last 50 years, I didn’t have to look back further than last year. That’s when I had the chance to act as scrum master for a newly formed team.

The Challenge

We had seven weeks to build software from scratch that would be demonstrated at a conference and used by hundreds of people. Since the conference was centered on artificial intelligence, it was mandatory that our demo used AI. Our idea was a game where the player spelled words using real sign language. The game was displayed on a television hooked up to a camera, which filmed the player’s hand.

The hand’s position was then recognized and matched to a letter of the alphabet. The player received points based on the speed at which he was spelling the words displayed on the screen.

The Team

We had a great team composed of two developers, a designer, two AI researchers, a product owner and me (scrum master). Our small, dedicated team would empower us to deliver the software we needed to build from A to Z.

Although concerned about the short time available, everyone was motivated and excited to build this amazing software, knowing the visibility it would get.

How We Would Work

Since the scope wasn’t fully defined and the user experience was key, we needed to deliver usable increments to test. We needed a framework that would allow us to deliver quickly and adjust to the requirements as they were refined. Scrum was the obvious choice, even though most of the team was completely new to it. The majority of the team came from a software background, so they knew what it was on paper. However, for the AI researchers, it was completely unknown.

Where it All Came Together

Many start off with the team they need, but then obstacles come their way and prevent them from moving forward. These could be anything from unavailable stakeholders to people being pulled off the team to poor requirements.

However, in this case, it was everything you would want from agility/scrum:

  • A team collaborating together without anyone coordinating them
  • Busy stakeholders making themselves available for us to collaborate
  • Everyone following scrum, even though it was new to them
  • The team working at a sustainable pace
  • A usable increment of the game delivered every sprint
  • Continuous improvement through the retrospectives
  • A healthy backlog that was properly refined by the team

It was amazing to see the collaboration when we needed users to test; after a quick Slack message to everyone in the company, we would suddenly have a lineup of people available to play the game.

 

What Inspired Me

When I think back on our success, all I remember are the people working together to create something great. It wasn’t even about being “agile.” For the team it was, “Let’s get this done!” and for everyone who supported us, it was “Let’s help our colleagues!” There was nothing more, nothing less—exactly how it should be.

 

I’d love to hear about the most inspiring project you’ve worked on in your career. Please share below!

Posted by Christian Bisson on: November 13, 2019 03:13 PM | Permalink | Comments (6)

Put Your Users First—Here’s How

by Christian Bisson, PMP, PSPO, PSM

In agile, users are everything. So it only makes sense that users—anyone who will use or interact with your product—should be a team’s main focus. In order for the product to be viable, whatever is produced must bring them value.

But it’s perhaps too easy to forget users when you build your backlog. We often jump too quickly to features, assuming “the users will use this.” But what if we took a step back? Consider taking the following steps:

Identify Your Target Audience

First, for whom is this product intended? Identifying a target audience will help you determine who you’re building for.

For example, if you expect users who aren’t tech-savvy, then you need to be mindful of how complex the interface or even the wording are throughout.

It’s important to describe these users. One common practice is to create “personas,” which are fictional characters that represent the users. These will help you better understand your audience.

Understand Their Goals

Now that we know our audience, what are they trying to achieve? Instead of jumping from personas to features, stop and think about their goals.

Are they trying to purchase something online? Are they trying to fetch information? Are they trying to plan a trip? The answers to these questions will shape your direction.

Predict Their Path Forward

We know who is trying to achieve what. The next key step is to define “how” the users are going to achieve their goals.

Let’s assume the user wants to purchase a toy. That user will most likely need to:

  • Search to find toys
  • Be able to view the toys
  • Add a toy to a cart
  • Make the official purchase

Let’s keep it simple. We can extrapolate that this user might be interested in items related to this item, or many other scenarios, but for now, the above is our user’s steps.

Once this is clearly defined, it is much simpler for:

  • Our product owner to create user stories clearly stating what the user needs and for what: “As a customer, I want to search for products by categories so I can more easily find what I am looking for.”
  • Our development team to understand why this (these) features matter, and how we’ll architect them, because we understand why we are doing it.

Keep Users Top of Mind

I’ve seen too many teams skip these important steps. Often, people are so quick to execute what is instructed by managers, or by assumptions from the team, that they forget to think about who they are building the product for. The user, of course, will ultimately decide the product’s success. That’s why it’s so important that our product brings value to users.

What do you do to focus on users? How do you verify if you are bringing value to them? Share!

Posted by Christian Bisson on: June 19, 2019 09:36 PM | Permalink | Comments (6)

Free Your Team With Liberating Structures

By Christian Bisson, PMP

I recently had the privilege to participate in the 9th Montreal agile coach gathering. Along with meeting great people and having a chance to exchange ideas with them, I had the opportunity to learn about “liberating structures”, a concept developed by Henri Lipmanowicz and Keith McCandless.

Liberating structures are 33 alternative structures for facilitating meetings, work sessions or retrospectives. Unlike conventional structures, such as status reports or presentations, liberating structures are meant to distribute control of the conversation so that all participants are part of shaping direction. This ultimately helps everyone work together while feeling more in control. According to Lipmanowicz and McCandless, conventional structures are either too inhibiting or too loose and disorganzed to achieve this.

Within your organization, liberating structures can be used to organize and facilitate work sessions, retrospectives or other types of meetings. These structures range from simple and fast exercises to those suited for more structured and longer meetings, giving a diversified toolset for various circumstances.

One evening during the 9th Montreal agile coach gathering, everyone gathered into small teams, picked one of the liberating structures randomly, and took 25 minutes to understand and discuss it with the objective of presenting it to everyone else afterward within a three-minute timebox.

Our team picked “critical uncertainties”, which makes you focus on essential and uncertain realities, and then plan strategies according to different possible futures. Among brainstormed ideas, you need to identify the most robust strategies (i.e., the ones that would work with the most possible futures). You can then plan action items based on what was discussed.

Another one that caught my interest is “1-2-4-all.” It is simple and can be used in so many circumstances, yet it is efficient to help a group of people (small or large) communicate and share great ideas.

For anyone out there who is a fan of liberating structures, I’m curious to find out which ones you used, in what context, and how was the result. Please share and discuss!

Posted by Christian Bisson on: March 15, 2019 06:39 AM | Permalink | Comments (16)

Debunking 4 Misconceptions About Story Points

Categories: Agile

by Christian Bisson, PMP


Story points, while an essential component of agile, are often misintrepeted.
And that’s a problem, as story points are are a vital unit of measure to help
estimate user stories. And stories, in turn, help teams plan their next sprint.
When they’re misinterpreted, story points lose their effectiveness, and they
can even hurt teams because of how they are used.

For the sake of my examples below, I assume teams use the Fibonacci sequence.
Let’s run through a few common misconceptions:


1. It’s about the complexity.

Some teams will mistakenly focus only on the complexity of the user story,
as measured by the required level of training it takes to complete a given
task. If a task is simple but time-consuming, they will assign it a “1.”
This is misguided because in addition to complexity, story points also take
into account effort and risks.

It’s important to factor in all three of these aspects of user stories to make a
proper estimate.

2. It’s about the business value.

Simply put: no.
When prioritizing their backlogs or even deciding to move forward with a
user story, it’s important for product owners to understand that story points
have nothing to do with business value.


A “13” could bring no value while being costly, and a “1” could be a golden
opportunity (a.k.a. a “quick win”).


Some Product Owners assign a “Business Value” to user stories (for example: A, B, C), although not mandatory, it can be used along with story points to help make key
decisions about priorities.

3. One point is one day of work.

Story points are not days, nor hours—they are a separate unit of measure. If
using “days” to estimate user stories works well for your team, then by all
means keep going, but call them days as opposed to story points to avoid
confusion.


4. Story points can be used to compare teams.

This one is a dangerous trap, especially if used by someone who can
influence people below him or her. It’s important to understand that story
points are relative to each person. Even within a team, it can be a challenge
to align initially until they have a few user stories to compare with.

A “5” can mean something different for Team A than for Team B, so
comparing each team’s velocity gives absolutely no value whatsoever. In
fact, it can mislead you into thinking one team is more efficient than
another, which in turn might result in unjustified negative feedback or
pressure to “have high velocity.”


In Summary

Story points are a tool, and like all tools, they’re only as good as how we use
them. If we fall into common trap, using our story points to plan our sprints
will lead us to disaster. It’s important that every member of the team
understands the concept, and that you also take the time to educate anyone
outside the team who has influence over your work, such as upper
management or customers.


Do you know of any other misconceptions around story points?

Posted by Christian Bisson on: January 26, 2019 01:44 PM | Permalink | Comments (12)
ADVERTISEMENTS

"Bad artists always admire each other's work."

- Oscar Wilde

ADVERTISEMENT

Sponsors