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!
By Conrado Morlan
“Hybrid” is commonly used in biology to designate the offspring of two plants or animals of different species or varieties. For example, a mule is the hybrid of a donkey and a horse.
But the word has also been adopted in different contexts. Perhaps when you hear “hybrid,” the first thought that comes to your mind is a hybrid vehicle, which relies on two or more distinct types of power to stay in motion.
The world of project management has its own hybrids. New delivery approaches, frameworks and skills can come together in a hybrid form to create something different and valuable.
In different project management forums, I’ve recently participated in discussions about the hybrid project manager. Some proponents were concerned with the technical side of project management, focusing on which method or approach—such as waterfall (predictive) or agile—is better. Others interpreted hybrid as bringing together the best of two worlds to provide results for the organization.
Here are my takeaways from those discussions.
Some project management practitioners think about the profession in purely technical terms. They have devoted themselves to learning new methods, best practices and frameworks that they consider innovative, trendy and useful to support the needs of the projects in their organization.
But some project managers who approach their work in this way tend to think that the method, best practice or framework they most recently mastered is a "silver bullet," pushing previous knowledge they acquired into obsolescence.
Just like any other profession, project management is evolving. There is no escaping the fact that today, many organizations see portfolio, program and project management as the way to link projects with their overall strategy.
Therefore, project practitioners need to consider the heterogeneous elements from the business side of the house to better understand the inextricable link between strategy and execution—regardless of the method, practice or framework. This is how they will deliver unparalleled value to the organization.
This type of practitioner is paying more attention to the PMI Talent Triangle® to identify the skills they will need to be a successful hybrid project manager.
The Hybrid Advantage
Organizations with the right mix of hybrid project managers will:
Do you consider yourself a hybrid project manager? If not, would you accept the challenge of becoming one?
By Christian Bisson, PMP
As most of you know, scrum works in iterations called “sprints” that can vary in duration depending on the product. However, there is some debate about what people call a “Sprint 0”: a sprint used for planning or prework deliverables that will help launch Sprint 1.
There are no one-size-fits-all ways to work, but personally I believe Sprint 0 is necessary in many cases. Here’s why:
One big difference between waterfall and agile is how planning works. Waterfall tends to focus a lot (sometimes too much) on planning, while agile tends to be the opposite. For most projects with lots of unknowns, planning too much will be a waste of time because the project will evolve and most of the work done in advance will be wasted. That’s why you plan as you go in agile.
However, when you start a product from scratch (e.g., a website, software, etc.), there are many decisions that will affect the entire product development — some of which can block developers from coding on day one. For example, what is the best programming language/framework to use? Teams need development environments amongst several other tools. This setup can use up a lot of time and prevents work from gettting done if nothing is available. Sprint 0 becomes crucial to give the team time to prepare so they can code properly from the start.
Sprint 0 helps with that by providing a first iteration that allows the team to plan enough for Sprint 1, whether with analysis, wireframes, designs, etc.
Chances are, the team has never worked together before. The Sprint 0 approach can help the team set up and get to know each other, which will help them at the sprint planning of Sprint 1.
Other factors to consider are estimating tasks, timing of ceremonies, understanding everyone’s role and so on — all important elements that make or break a team’s efficiency.
It’s also a perfect opportunity for the scrum master to get the lay of the land and identify where to focus first to help the team.
Many would argue that value should be delivered at the end of a sprint. And Sprint 0 does not offer that to the stakeholders, which is true. However, not much real value will be delivered from a Sprint 1 that is wasted by the complete lack of preparation!
What are your thoughts on Sprint 0?