Viewing Posts by Christian Bisson
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.
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.
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.
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.
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:
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.
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!
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:
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.
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.
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:
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:
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!
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!
Debunking 4 Misconceptions About Story Points
by Christian Bisson, PMP
For the sake of my examples below, I assume teams use the Fibonacci sequence.
The Traps of Textbook Scrum
By Christian Bisson, PMP, PSM
The Agile methodology is quickly becoming the standard for IT projects. More specifically, most organizations are using the Scrum framework to bring their software development to the next level.
But it’s implementation often remains a challenge and that’s because Scrum is not one-size-fits-all, and if you follow the manifesto too rigidly you can fall into a few traps.
Here’s a look at two:
1. Lack of Team Experience
If you’re coaching a team new on Scrum, take baby steps. Imagine if you’re teaching someone to play basketball for the first time. You will most likely teach them how to dribble before you teach them how to dunk a ball.
It’s the same with Scrum. If you throw everything in the Agile Manifesto or Scrum Guide at your team at once, chances are the results will be poor, the team will be confused and ultimately they will not enjoy the methodology.
For example, when assigning complexity, start with T-shirt sizes (small, medium, large) instead of the Fibonacci scale. When the team grasps this concept well, adapt accordingly.
2. Potential Waste of Effort
An active sprint is considered sacred for a team. Its scope must not be modified, and any new requests/requirements should be factored into future sprints.
Be that as it may, sometimes there are extreme circumstances where the sprint must be stopped or modified due to new requirements.
For instance, say an amazing opportunity presents itself three days into the sprint, making the current scope of the sprint obsolete. Fixating on the fact that a sprint cannot change and having the team work for the remainder of the sprint on something confirmed to be useless would be a waste.
If this sudden change creates downtime for the team while the new requirements are written and refined, the team could focus on testing new technologies, or working on a proof of concept that could help with the new requirements.
Or sometimes a project faces issues and due to the importance of the client, those issues must be prioritized. People may be pulled out from one team to help another. That will mean that an active sprint’s committed scope may have to be reduced, which is when you have to put aside the textbook for the sake of the organization, and to help out colleagues in need.
Have you ever had to steer away from initial expectations for a project or team’s benefit? Share your story!