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 Kevin Korterud
Once upon a time, projects were just projects. They were simple, had small teams and quite often finished on time. Projects were viewed as a path to operational improvements that reduce manual labor and free up people for other tasks.
As time marched on, the notion of a project began to increase in scale and complexity. Technology projects, for example, began as modest hardware and software initiatives. Over time, the technology project landscape has changed to include network, servers and cloud infrastructure. Software projects began growing into systems, software packages and complete end-to-end solutions.
As the quantity and business focus of project work increased, they became packaged into programs. Programs were created to help orchestrate myriad projects into cohesive outcomes. These were governed by an expanding slate of waterfall methods designed to both enable and oversee delivery.
With the advent of agile, a different form and pace emerged. Product delivery moved toward quicker and more frequent outputs, with delivery cadence driven by what an organization believed was best for customers and consumers.
Today, organizations have a delivery ecosystem of project, program and product delivery work based on internal and external dynamics. As the ecosystem changes over time, the balance of projects, programs and products does as well.
With project, program and product delivery all moving in different directions and at different speeds, how can an organization prevent these efforts from crashing into each other? Here is an approach I follow to help define, oversee and enhance the natural delivery ecosystem:
First, ensure that definitions are in place. These should be clear and concise portrayals of the work to be performed. Having these definitions commonly understood will go a long way in matching the correct policies, processes, controls and people to the form of work.
Here are some sample definitions:
These definitions also serve to identify the portfolio proportion of these different types of work, which helps determine the right people and supporting structures for success.
The ecosystem can change and flow to meet the needs of organizations, market forces, suppliers and people. Given this ebb and flow, one practical reality of this ecosystem is that any one form of project, program and product work cannot exist as 100% of the work.
2. Govern the Ecosystem
Any delivery ecosystem left to its own resorts will result in chaos with teams having different perceptions of how project, program and product delivery should be executed. This chaos will result in delays, additional costs and sometimes stalemates as teams negotiate over the execution of work efforts.
There needs to be balancing forces in place that help direct delivery. A delivery ecosystem governance model sets the boundaries for delivery work from ideation into formation and through execution. The governance model implements policies, processes and enabling artifacts that create predictable and repeatable attainment of desired results. This governance model is typically overseen by an enterprise delivery management office.
For example, one process within this model sets the venue to identify, confirm and release for execution the proper delivery process for a type of work. A portfolio review board based on input from the sponsor would analyze the characteristics of the work and determine whether it is a project, program or product. The outcomes from this portfolio review board promote consistency, ensure impartiality and avoid costly re-work due to poor decision-making.
Even an effective delivery ecosystem needs to have a “tune-up” every once in a while. As changes in business strategy, support for new regulations, market expansions and technical innovations come into play, the delivery ecosystem needs to change accordingly. These drive the need for a function to continuously harmonize and improve the delivery ecosystem. An EDMO will be the primary vehicle to both harmonize and improve the delivery ecosystem within an organization.
Improvements can include initiatives to reduce mobilization time, avoid resource contention and improve supplier integration. These initiatives are universal in nature and can be consistently applied to improve project, program and product delivery.
With the increased complexity of work and differing approaches for projects, programs and products, you need a means of harmonization to prevent misalignments, conflicts and collisions between work efforts. Harmonization processes can include release, dependency, data integration and test environment management.
Embrace the New Normal
Organizations need to recognize and embrace the different forms of delivery that are now the new normal. By adopting a structured approach to the definition, oversight and enablement of projects, programs and products, they can be delivered in a synergistic manner to lower costs while improving time to market and quality.
How do you balance the project, program and product initiatives at your company to avoid weather problems?
Debunking Six Misconceptions About Agile
For those of us in the project management community, agile is a familiar term. But despite its prominence, it’s often misunderstood.
All too often, teams and organizations focus on the wrong things or are misinformed. And eventually, agile takes the blame.
Here are six common misconceptions that can lead to an anti-agile mindset:
These are six misconceptions I’ve seen about agile. What are the common ones you’ve encountered?
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.