Agile principles and Roles Tutorial 2019
Organizational roles and their functions are part of transforming to Agile. This tutorial focuses on the Agile values and principles.
Product Owner Constellation
APO works within a set of ideas that come from many places. Many ideas come directly from customers and others come from those within the company. To bring customer value ideas together, a PO should form a product owner (PO) constellation, consisting of employees who help the PO focus on customer value.
While the PO is the person ultimately responsible for prioritizing and owning customer value, it is good to have a PO constellation that includes other roles and functions that provide input to decision making for determining customer value. Other roles that can provide input are business analysts, management, salespeople, marketing experts, and field engineers.
Less Obvious Agile Roles
There are the role and functional areas that are often missing from the Agile galaxy. These roles and areas need to be more engaged and adapt to an Agile mindset and practices to make for a more thriving Agile customer-value-driven enterprise. Given that early Agile processes tended to focus on the team level, this is not surprising.
However, in order to have an end-to-end and top-to-bottom enterprise focused on the engine of customer value, all those within an enterprise need to adapt and play their role.
For those in this group, I often start by offering an Agile 101 session, which includes an emphasis on the Agile values and principles and a view of the Agile galaxy highlighting both axes.
I focus on what it means to be customer-value-driven. Next, in the spirit of self-organizing, I ask the participants how they think they can adapt their role to align with the Agile mindset and the incremental nature it brings and how they can contribute to delivering customer value. The roles or functional areas that tend to fall into the “less obvious” grouping include:
[Note: You can free download the complete Office 365 and Office 2019 com setup Guide for here]
Executives and Senior Management
Executives and senior management establish company goals, strategies, and objectives, and they provide leadership and guidance.
When moving toward Agile and customer focus, senior leaders must initiate a strategic shift in how the enterprise works. The senior leader should become the sponsor of the Agile initiative, encouraging buy-in to Agile.
They must play a continuous role in advocating for Agile via emails, company meetings, and celebrations. Executives learn the language of Agile and customer value and become more conversant with those they lead.
Executives should support the concept of customer-value-driven enterprise, advocating for a discovery mindset where customer feedback loops are used to incrementally gain an understanding of what is valuable to the customer.
They should also advocate for metrics that gain insight into learning what the customer value is and the fastest possible speed for delivering that customer value.
Senior leaders should adopt the enterprise from hierarchical to self-organizing. When employees feel they have more ownership and decision-making accountability, they apply more brainpower and bring passion to their work.
This should include hiring direct reports who have a discovery mindset while retraining current directs who have a certain mindset.
Finance employees are primarily responsible for the fiscal health of an organization. They are focused on the financial side of funding decisions, facilities support, and staffing and, as a result, they manage the supply-and-demand system of the organization.
A specific activity undertaken by finance is managing the annual budget process and periodically reporting and monitoring the financial health of the enterprise.
When moving toward Agile and customer focus, budgeting departments should adapt to continuous Agile budgeting or at least a quarterly budgeting cycle. Finance needs to understand the importance of customer feedback and how it can change the direction of customer value to better know where to invest the enterprise’s money.
Since the demand for certain products and services can change quickly, finance needs to establish a system that can adapt supply according to the demands of the customer and market conditions.
For healthier decision making, finance should participate in two activities related to the value of ideas. The first is to challenge the assumptions and certainty thinking being demonstrated when people say an idea is of high value.
The second is to advocate for Agile budgeting where the company funds only increments of an idea to place smaller bets and ensure that feedback is collected before any further funding.
In addition, finance should adapt to reporting toward a more incremental and outcome-driven manner. Finally, finance should learn Agile and what it means to be a customer-value-driven enterprise. For more on finance and their role in Agile budgeting.
Portfolio management (PM) teams focus on identifying what work is deemed valuable to an organization. These teams are found near the early part of the delivery axis of the Agile galaxy. In a more general sense, PM is a group within an organization that defines the standards of how the portfolio or work is managed.
Traditionally, these employees are often involved in having the authority and making decisions on what work gets done. PM often supplies metrics and reporting on the progress of the work.
When moving toward Agile and customer focus, PM should move toward a servant leader role. These employees adapt from being a key decision maker to enabling effective decision making by the business side.
They set up an enterprise pipeline of ideas being considered or those that are already underway, focusing on the value of the work instead of the status. Information on the enterprise idea pipeline should be publically available.
PM can be instrumental in supporting a customer-value-driven organization by providing transparency on how the work has gotten prioritized, what prioritization methods have been used, what assumptions have been made, what customer feedback loops have been applied to validate customer value, and what team(s) have or may be involved in the work.
The PM should also encourage discovery and incremental mindset that, instead of moving a large idea into development, promotes the activity of decomposing an increment of the idea to validate its value.
It should also adapt reporting toward recognizing the value delivered, the rate of delivery, quality of delivery, and business outcomes of revenue generated. Of course, PM should learn Agile and what it means to be customer-value-driven.
Healthy Employee Relationships
A big part of building an Agile enterprise is evolving roles to better connect people together. Promote activities where employees can interact, build empathy, and collaborate. Sharing each other’s delights and concerns is a meaningful way to build understanding and trust.
In Agile, there are many related practices that promote people working together (for instance, pair programming, story mapping, and grooming). Informal activities, such as eating and socializing together, can further the connection.
Strong connections occur when two people bond in a face-to-face manner. Since nonverbal communication makes up a major portion of all communication, face-to-face communication helps people better understand each other and how they are feeling about a discussion.
While physical face-to-face contact is preferred, there are online applications that bring you face-to-face. Consider using a virtual alternative when physical face-to-face is not an option.
It is not uncommon in a distributed organization to have members at the remote site visit and bond with team members at the local site. This is a way to get team members to know each other, which promotes collaboration and builds trust. When members return to their designated site, the trust that has been built will promote stronger relationships.
Healthy Manager-to-Employee Relationships
As a manager, consider ways you can get to know team members and they can get to know you. Key ingredients in building trust are transparency, listening, integrity, and growth.
Transparency is about sharing information regarding the company, division, and group so employees know what is going on. This may include sharing the latest changes, strategy, group goals, and anything else that has an impact on employees. When trust is established, transparency becomes a two-way street.
As a manager shares more, employees will share more with the manager about what is really going on around them.
Listening is allowing employees to lead the agenda in a one-to-one encounter. By being an active listener, you have the opportunity to learn about the employees and what they care about.
Another example of listening is walking the gemba (in other words, the real place where work gets done) where employees are sitting. Stop by and say hello. Ask them if there is anything they need.
Integrity is about being fair and honest about the way you treat employees and avoiding favoritism. Deliver on commitments to employees and only promise something when you mean to do it.
If you ask employees to take risks, provide them with a safe environment to do so. If you respond negatively to an employee failure, this will be a sure way to lose trust. Instead, address what was learned (focus on the positive) and how that learning can be incorporated for better results in the future.
Growth is about showing employees that you care about their personal goals and career growth. This goes well beyond the notion of promotions by providing them learning opportunities both within the workplace and outside. Periodically check in to discuss their goals to see how they are doing.
When considering how to evolve roles to align for the changing needs of customers, you may look at the holocracy model. Holocracy can be defined as a different way of operating an enterprise that moves power from a hierarchy management structure and distributes it across autonomous teams.
In holocracy, teams are the basic components and building blocks of an enterprise. Teams are given a consequential purpose and then self-organize around the work and determine how to best achieve the need. Teams are not part of a business unit. This allows for dynamic movement of teams and individuals toward the work of perceived high customer value.
From a customer-value perspective, teams have customer value as their driving consequential purpose. As customers’ needs change, so do the teams. Because team members have a number of skills and experience, they may move from team to team to where the highest value work is occurring.
Holocracy leverages a number of concepts. Transparency is applied where strategy, policies, and decisions are made public so you don’t need to rely on the politics of who you know to get information. Self-organizing teams are responsible for their work, decide how to do their work, and determine who will do the work without any managerial input.
Lightning-bolt-shaped teams ensure team members have a primary, secondary, and tertiary skill set, experience, or ability to work on different types of work to make it easier to move from team to team.
Bounded authority is applied where ownership and decision making is moved to where the most knowledge lives, which is often at the team level. Also, the concepts of open source, Agile processes, and lean enterprise are often seen as part of holocratic organizations.
Enterprises that move to a holocracy model will see their organizations’ structure adapt to allow for more teams working on customer value and more employees who are closer to the customer. The two- degrees-of customer-separation rule (where every employee is no more than two degrees of separation from the customer) almost becomes automatic.
It may be challenging for some employees, including those in management, to move to an holocracy model. I suggest first experiencing self-organizing and applying lightning-bolt -shaped teams before considering holocracy.
For more insight, consider exploring Holocracy by Brian J. Robertson, The Evolutionary-Teal Paradigm by Frederic Laloux, and the Agile mindset on how an organization may evolve to be better aligned with customer value.
Have You Evolved Your Roles Yet?
It does take an enterprise and the whole Agile galaxy to move to Agile and the focus on customer value. Every role should evolve to become closer to customer value.
If you are an Agile enterprise, you should see new roles, adaptation to existing roles, and the minimization of other roles. Avoid optimizing on the title of the role and instead optimize on what is needed to more effectively deliver customer value.
Principle: Building a Learning Enterprise
This is an enterprise that understands that it is the people (both employees and customers) that will make them more successful. The Agile manifesto reminds us of this by emphasizing “individuals and interactions over processes and tools.”
A continuous learning enterprise also understands that you can learn from a variety of different sources in a variety of different ways. This enterprise believes that there is no end state for being Agile just as there is no end state to learn what is valuable to the customer.
Just as teams should have a con-sequential purpose to help them focus on their work, an enterprise should have a consequential purpose to help it realize the variety of education that can help with that purpose.
The consequential purpose of achieving customer value helps an enterprise focus its culture, process, skills, and roles in education. Since Agile is an enabler to delivering customer value, Agile topics form the core of the education needed to deliver customer value.
Because Agile requires a cultural shift in the way you think about work, you need to first read your mind by learning the Agile values and principles and the importance of focusing on positive business outcomes.
You also need to understand the cultural shifts necessary for the Agile journey. Then you must learn the various Agile processes, practices, and skills needed to make the journey.
Finally, you need to be joined by a guide (that is, a coach) who can help you transform to an Agile mindset as your experience and learn what Agile feels like. Of course, as you work through continuous learning, you need to gain feedback and adapt to people’s educational needs.
Principle: Agile Education Universe
There is a wealth of topics that can be covered in achieving an Agile mindset and customer value. In an Agile galaxy context, you can learn about the early part of the delivery lifecycle where ideas get articulated and prioritized, processes are applied, and motivation and trust become a priority. What you can learn is limitless.
Since learning is a journey, you may apply different education elements, depending on the topic. For some Agile topics, looking at a topic from several different angles enables learners to fully digest and understand it.
Also, there are certain core topics that can be building blocks in achieving an Agile culture. This is why I strongly recommend avoiding process and role topics up front and instead focus on topics that can ready the mind for an Agile culture.
Principle: Agile Education to Ready the Mind
Since Agile requires a cultural change, consider starting your Agile transformation by focusing on the current culture of the company. Begin reading the mind by educating employees on Agile values and principles and the behavioral changes needed.
When you start with Agile mechanics of processes or roles, people may think Agile is first about mechanics and then the achievement of an Agile mindset.
I often start an Agile transformation by offering an Agile 101 session that emphasizes the Agile values and principles. I ask employees to rank order the Agile values to initiate discussion and thinking.
Then I’ll walk through each Agile principle and ask them if they agree, are neutral, or disagree with it. If people are neutral or disagree, discussion and debate will ensue. I’ll only spend five minutes on each principle as the purpose isn’t to persuade employees but to have a discussion. Sometimes a mindset shift takes time, so don’t rush it.
After Agile 101, I continue with a session that focuses on the Agile galaxy with an emphasis of both axes, and what a customer-value-driven enterprise means. I’ll ask where on the galaxy most people are applying Agile today so the participants better understand the state of their Agile galaxy.
Next, I’ll discuss the discovery mindset and behaviors that may be expected. This will include a focus on self-organizing and bounded authority.
You may notice in the early Agile education, I have not once mentioned education on an Agile process or Agile role. Instead, focus early on reading the mind for Agile with Agile mindset education.
Importance of Work-Based Learning
Work-based learning is an approach to education where for every topic that you learn, you must apply the knowledge. This supports the discovery mindset and provides a deeper level of learning for students. The first-hand experience gained by students provides a deeper learning environment.
Within the Value, Flow, Quality (VFQ) education, Alex Adamopoulos includes the work-based approach to education, which helps organizations learn Agile and business topics and then gain immediate business benefits from applying them.
Students learn a topic, exercise the topic in class, and then apply the topic with their team members in their actual working environment.
A similar approach is a learn-apply-share model, which includes learning a topic in the classroom, applying it in exercises, using it in a real work setting, and finally sharing and explaining the topic to others. When you have to explain a topic to others, you more fully understand the topic, which deepens your learning opportunity.
When you expand the notion of continuous learning, not only do you learn Agile topics, you also “learn your way to customer value.” A learning enterprise goes beyond learning processes and tools.
The type of enterprise that uses this approach recognizes that you learn from each other and you learn from your customers. Just as it takes a discovery mindset with multiple customer feedback loops to zero in on customer value, it takes multiple types of Agile topics to operate in an Agile manner to achieve customer value.
Agile Education Vision
Agile is a cultural shift that is often larger than most people realize. As you look to change your culture and gain the business benefits, you have learned in this blog that there are hundreds of Agile and customer value related topics. You have also learned there are many ways to become educated. So, how do you organize Agile education in a manageable way?
Enter the Agile Education Vision. This vision is an adaptive education roadmap where you can iteratively plan and apply the repertoire of topics and educational elements to support your transformation toward an Agile culture. The vision can be applied to an employee, a team, and/or an enterprise.
You may consider an Agile education vision as a prioritized product backlog of education topics based on needs. In each iteration, some form of education is provided that builds Agile knowledge, skills, and capabilities toward achieving an Agile mindset. At the beginning of each iteration, topics may be added and reprioritized for what is most important at that time.
• When applied at an individual employee level, ask what education may help a person develop the skills, process, and experience to better grasp Agile and understand how to achieve customer value. An employee may have personal learning goals such as gaining more knowledge of story point sizing and gaining new experiences by meeting actual customers.
• When applied at a team level, ask what education may help employees improve Agile teamwork and the flow of their work? A team may have goals focused on collaboration or learning to decompose work from user story to the task. In the spirit of self-organizing teams, the Agile education vision is meant to be self-organized by the teams and their education needs.
• When applied at the enterprise level, ask what education can help the organization shift toward an Agile mindset and be more customer-value-driven by aligning roles more closely to the customer.
This may start with basic Agile education that all employees should have such as Agile values and principles. An enterprise may then focus on applying self-organizing teams and applying the discovery mindset to meet customer needs.
As an added tip, any time an education item is time-consuming (one-day training, reading a blog, and so), consider including it as a story with a story point value.
As the owner works on this item, the story card can get moved across the board to indicate the progress of the education. This highlights that education is considered valuable and illustrates the progress made in completing the education work item.
Building an Agile Community
Another form of education involves engaging the broader Agile community. Building an Agile community creates a continuous online and physical presence of Agile support. It provides a platform where employees collaborate with and educate each other. The platform encourages sharing of progress and success stories.
It provides employees with the opportunity to share knowledge and give back to their community. Some building blocks for a healthy Agile community may include the following:
• A website to share practices with the community. When an Agile culture has been established, information such as culture, processes, glossary, pointers to education, and more are placed on the company Agile website so that teams have ready access to this information moving forward.
• Avenue for online social collaboration among the community. This provides an online space for those on the Agile journey to pose questions to that outside of their teams to hear their thoughts, ideas, and lessons learned as well as to provide answers to others who are posing questions. This space provides an opportunity to discuss and collaborate on a variety of topics. It is also a place to share internal blog articles.
• Avenue for live forums for the community. This is a place to host the latest advances in Agile by Agile coaches or where Agile champions can give back to the local community. These venues may include seminars and webinars as platforms to share the latest progress or support for Agile by leaders.
Applying a Discovery Mindset
A discovery mindset is a belief that acknowledges uncertainty and applies a variety of thinking approaches to continuously learn through incrementally gathering knowledge of what lies beyond.
This includes a combination of curiosity to learn and a drive to innovate. A discovery mindset isn’t one where you voyage haphazardly about, but, instead, apply methodical concepts that lead to a more informed journey.
A discovery mindset leads to establishing behaviors of learning as we go, focusing on what we don’t know, and using various thinking approaches to gain knowledge toward the direction of customer value. A discovery mindset avoids certainty thinking as well as upfront and big-batch approaches.
From a business perspective, the discovery mindset ensures that you are not using your funding and investment toward a path of false certainty, but rather heading toward a path where you learn the direction. You course-correct when you discover that you are headed in the wrong direction.
Using a discovery mindset has four primary benefits. The first benefit is that it helps you adapt toward the direction of customer value and (hopefully) product success. The second is that it helps with innovative work because less is known at the beginning so the discovery of customer value becomes more important.
The third is that, in relation to a transformation (since discovery involves working in increments), it can be much easier for people to commit to a short-term experiment than to commit to a long-term, often unknown, future. The fourth benefit is that it helps move an enterprise toward an empirical and disciplined approach to work.
Leading with a Discovery Mindset
Imagine that you started your Agile transformation with a discovery mindset and thinking approaches instead of mechanical practices. The advantage of leading with a focus on mindset is that it sets the tone for the behaviors that you are looking for in people.
Additionally, it avoids the trap of people thinking that Agile is about mechanically applying Agile processes or practices.
A mechanical implementation of Agile processes and practices tends to ignore the cultural aspects of Agile. Agile is a cultural change, consider starting your Agile transformation from a cultural perspective with a strong focus on the discovery mindset.
Reading the mind with the discovery mindset, thinking approaches, and Agile values and principles conditions the mind so that when processes and practices are applied, they are done so with the right behaviors.
What are some of the various thinking approaches that enable a discovery mindset? They are incremental thinking, experimental thinking, divergent and convergent thinking, feedback thinking, and design thinking. What shouldn’t surprise you is that these concepts are often applied in tandem to achieve the best results.
For example, design thinking involves incremental and divergent thinking. Experimental thinking includes incremental thinking and feedback thinking. The discovery mindset embraces them all.
Incremental thinking is an approach where you embrace thinking in small pieces and in short timeframes. Instead of making big bets with limited knowledge, you take smaller bets and use what was learned in the current increment to course-correct your direction for the next increment.
This reduces risk and prevents investment from going down the wrong path for too long.
In Agile, there are concepts of iteration and increment. These two concepts are confusing for some in that they are often used interchangeably while they are in fact different.
An iteration is the period of time a team works to build something. In Scrum, the concept of a sprint is used to provide a team with a period of time (for instance, one to four weeks) to produce a deliverable. The deliverable from an iteration is termed an increment.
An increment is the outcome of an iteration and, if aligned with the Agile values and principles, should produce working software or product.
As it relates to incremental thinking, the goal is to move away from big-batch delivery and instead think in smaller batches aligning with the Agile principle of “deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”.
Incremental thinking supports the concept of learning what the customer finds as valuable. Incremental thinking allows us to shed the dangerous attitude of pretend or arrogant certainty and instead explore what the customer needs.
Instead of fixing customer needs up front, you iteratively learn your way to what the customer finds valuable by building increments of product that the customer can inspect and provide feedback for.
Experimental thinking is an approach where you embrace a more systematic way of navigating toward certainty. Instead of guessing, this type of thinking uses a scientific approach where you hypothesize your next move. It is meant to provide more rigorous methods for identifying customer value.
As you consider customer needs at the beginning of a project, you are at the time where you have the least information or evidence of the need. Instead of guessing, you establish a hypothesis for the next increment of work based on the information currently available and what may be the right direction.
you conduct your experiment and apply measurable data and feedback loops (that is, validating with customer demonstrations and more) to identify what you have learned.
The results provide you the knowledge and help you determine where to go next by either affirming or rejecting the hypothesis. Then you take what was learned into the next incremental experiment where adaptation occurs.
In the context of a business or new product idea, a discovery mindset helps you systematically learn whether an idea has value to your customers. Each change—whether a new feature, a change to an existing feature, or removal of a feature—should start with a hypothesis.
Power of the Hypothesis
A hypothesis is an idea or supposition based on current evidence as to your starting point. The ingredients of this hypothesis are a hypothesis statement related to a customer need, time-boxed iteration, and customer feedback to prove or disprove a direction. In other words, it should no longer be good enough to guess which direction you should move.
Any affirmation or rejection of a hypothesis is not meant to be a judgment. Instead, it should be looked at as a course-correction toward customer value.
If you have hypothesized correctly, you may invest further effort into continuing with the hypothesis. If you have not, create a new hypothesis based on the feedback received.
Drilling down, the elements of the hypothesis statement should include the change you are trying, the impact you expect from the change, and who should be impacted. The “change” should include the name of the change (feature, app, and so on). The “impact” should be quantifiable and data-driven involving an increase or decrease in a current measure.
The “who” should include a persona or market segment that is being targeted. You may also add a time-frame for how long the test will run. Here are three examples:
The new feature will be liked by 60% of our current user base in the next demonstration event.
The new checkout design will decrease drop rates by 30% for shoppers who have goods in shopping carts over the next 30 days.
The new app will increase revenue by 10% for mobile app users over the next four weeks.
You should consider certainty-building activities as an experiment. It is important to have a discovery mindset in all of the work you do, particularly when it comes to moving in the direction of customer value.
Divergent and Convergent Thinking
Divergent thinking embraces an approach that promotes collaboration to generate ideas and numerous solutions with no censoring of ideas. Once an allocated time box to share and discuss ideas and options is concluded, divergent thinking is paired with convergent thinking to more quickly come to a consensus.
A traditional divergent technique is brainstorming, which focuses on generating ideas in an unstructured manner.
But due to the fast pace of most companies, we are quick to shut down brainstorming by criticizing the opinions of others (including our own). Because of this, I recommend ten minutes of silence for all brainstorming activities to ensure all ideas get a chance to be revealed prior to any discussion.
People generate their ideas with no discussion so no one’s ideas are dismissed by people who are more assertive. As you may guess, often the quiet team members (that is, introverts) have great ideas and a divergent “quiet” period allows the talented introverts to get their ideas on the table. The key to divergent thinking is that there is absolutely no censorship of ideas or solutions coming forth. All ideas are valuable.
Once the divergent time box is concluded, it is time to commence with convergent thinking. Convergent thinking is an approach to systematically limit your options and focus on one direction. From divergent thinking, there are often more ideas and possible solutions than can be handled.
In convergence, various techniques can be applied to bring together ideas. This may include looking for affinities where common themes may arise from some of the ideas.
It can also include red-dot voting, a non-confrontational prioritization technique where people quietly place their dots on what they think are the top ideas for solving the problem. Ideas with the largest number of dots are discussed until a top option is selected.
The value of divergent thinking cannot be underscored. Spending as little as a few hours of collaborative brainstorming coming up with ideas is a drop in the bucket compared to the thousands of hours spent in building a solution. The tiny investment is worth ensuring that many options are made available.
Also, the divergent and convergent pairing can occur in a continuous manner. For every customer need expressed in a user story in the beginning of an iteration or sprint, divergent thinking can be used in sprint planning to consider options prior to jumping into the sprint where you build the customer need.
When the next iteration or sprint begins, you move back to divergent thinking to consider options for the next set of user stories prior to embarking on the sprint.
It is also very important to be explicit about whether you are in a divergent or convergent thinking mode. Some people naturally gravitate toward divergence while others gravitate toward convergence.
It can reduce tensions in interpersonal relationships to explicitly state whether you are in a divergent or convergent mode so that it is clear whether you are soliciting options or closing down options.
Finally, when you have an organization that is constantly pushing you to move forward, convergence is stressed, whether consciously or unconsciously. This is a detriment to innovation and being open to numerous possible solutions.
It may take an organization to explicitly initiate divergent thinking to achieve more innovation and ideas.
Design thinking is an approach where teams have the space to consider the best options for solving a problem. It empowers those with the most knowledge to work through a solution. It also involves applying iterative and validated customer learning. It combines some of the incremental and divergent thinking in its approach.
Design thinking applies divergent approaches to come up with options on how to solve the problem. This may include research and bringing people together to brainstorm ideas.
From the top ideas, collaboratively converge by having the team self-organize around an option that the team thinks will solve the problem or address the opportunity. Convergent approaches such as affinity and red-dot voting may be used to select an option.
As you approach prototyping the chosen solution, apply a hypothesis to prove or disprove the option chosen for a more systematic way of navigating toward certainty and customer value.
Test the option by using an iterative and incremental framework to validate if the hypothesis (that is, option) moves you toward the direction of customer value. The iterative framework may be one of the Agile processes that exist today.
Once an experiment is concluded, examine the results. Based on the results, either moves forward with the original option or adapt toward another option. This requires customer involvement to continuously provide feedback to validate that you are moving in the right direction.
Designing thinking is a good way to bring together the employee and customer. As employees are collaboratively engaged and empowered to decide how to build customer value, customers are brought in via feedback loops to validate whether it meets customer needs.
Pipeline of Ideas
The enterprise idea pipeline provides three primary benefits to an enterprise. First, it is a channel that provides an end-to-end flow of ideas from the moment they are recorded to when they are released and reflected upon. Second, it is the enterprise-level portfolio backlog of ideas.
Third, it is meant to highlight high-value ideas the moment they come in so that the enterprise does not miss the idea’s window of opportunity.
The culture needed for the enterprise idea pipeline is one where the enterprise immediately considers ideas as they come in because they are based on a current problem or opportunity. You don’t wait for the next budget cycle to consider the idea.
The pipeline is a more adaptable way of managing the portfolio of work across your enterprise since ideas can be admitted anytime and feedback may change its priority or reshape the idea. Also, the pipeline brings enterprise-wide visibility and transparency to the work occurring within an organization.
Before moving on, what is an idea? An idea is something that is deemed as valuable but has not yet been created. At the moment it is recorded, it may be small or large. Depending on its level of customer value, it may become work that is worthy of evolving into a product or service.
As part of the Agile galaxy, the enterprise idea pipeline is a working example of the delivery axis focused on delivering customer value. As the delivery axis represents the end-to-end flow of customer value from the recording of the idea to the point where it is released and then reflected upon, so is the enterprise idea pipeline.
The enterprise idea pipeline is known by different names such as a portfolio backlog, enterprise kanban board, and idea pipeline. What makes all the terms similar is that they imply that the big ideas may eventually (or immediately) be worked on by teams.
The enterprise idea pipeline acts as the parent and feeder to all of the product backlogs and helps you connect strategy and ideas to user stories (and even tasks) and vice versa.
An enterprise idea pipeline is primarily used in medium to large companies when visibility is needed to make investment decisions across portfolios to better understand where the highest-value work lives.
It also helps when there are dependencies across multiple products, or when ideas do not have an obvious resting place in a product backlog.
When an enterprise is small and made up of a singular product, the product backlog acts as the enterprise idea pipeline as it contains the ideas that may be included in the future of that product.
Even at the backlog level, new ideas need to be valued to ensure that the highest-value idea gets worked first. The moment there are multiple products, there may be a need for a portfolio-level backlog that becomes the pipeline for upcoming work.
The path through the Pipeline
As discussed earlier, an enterprise idea pipeline provides an end-to-end view of the flow of ideas from the moment they are recorded to when they are released. It offers a path from idea to delivery. I have found that the Idea Management model established by Emergn is a good way to pattern the flow of work through an enterprise.
Utilizing the first five patterns to form the 5R model, you create a path for your work. As illustrated in Figure the five Rs consist of five stages: Record, Reveal, Refine, Realize, and Release.
The 5R model is meant to be adaptable. Some companies may decide to use corresponding terms. For example, instead of Realize, the term Develop could be used and instead of Reveal, the term Prioritize could be used.
Each stage represents a progression of the idea. It is important to note that the path isn’t linear. Some ideas may get to the Reveal stage and are too low in value to move farther.
Some ideas may get an increment cut in the Refine stage and then, once in the Realize stage, feedback is received from customers in a demo that finds it more valuable, which requires updating the value in the Record stage.
YOUR 5R MODEL EXERCISE
Review the stages of the 5R model (Record, Reveal, Refine, Realize, and Release). What terms could be used in your enterprise that represents each of the stages in the 5R model? Draw out your example.
Recording the Idea
The Record stage is a place to begin documenting what is known about the new idea. The documentation should be visible and transparent to everyone in the enterprise. Who typically submits or records ideas?
Effectively anyone can record an idea, but more commonly it is a product owner, a portfolio leader, a business or marketing leader, or a manager who is in touch with customers.
Recording the idea should include a description, persona or market segment, the value, the risks of doing the idea or not doing the idea, and the assumptions being made.
Revealing the Idea
The Reveal stage focuses on two areas. The first area is where the new idea gets revealed in the pool of ideas, according to its value level.
The second one is where it is determined if the idea has high enough value so that the owners and stakeholders of value (for example, product owners) and Agile team(s) are notified of the possible work ahead.
The idea gets revealed in the pool of ideas in a rank-ordered manner based on the value that was entered for the idea. This new idea rises to its level of value in the pool.
If it is one of the top ideas, it will be prominently available for people to view. If it has a lower value, it will sink to its level of value and may not be discussed further.
From an Agile perspective, if it doesn’t rise to a high enough level of prominence, it’s not worth spending more time until it does, if it ever does. The main benefit of this approach is that as high-value ideas come in, they immediately get rank-ordered so they don’t miss their market opportunity.
Who typically reviews and evaluates the recorded idea? Owners or stake-holders of value (such as product owners and chief product owners) and those that help drive investment decisions (for example, business leaders, marketing, and senior management) should be the ones who do this work. They should all have a stake in the success of the work and operate with a discovery mindset.
If the idea floats toward the top of the pool in your enterprise idea pipeline based on its value, several things occur. First, there should be a healthy discussion surrounding the idea.
The owner or contributor of the idea should share the details, the risk of doing or not doing the work, how the value was calculated, and the assumptions being made in calculating the value. It is important for the owners of value to periodically check the pool of ideas so that high-value ideas are promptly discussed.
In an effort to continue to validate the value of the idea, stakeholders should challenge the assumptions made that determined the value. Toward the beginning of the idea, the journey is when the least amount of information is known about the idea.
Challenging the assumptions of value is beneficial to the health of the enterprise as it will determine where investments in people and resources are being made. Challenging assumptions of value also reduces the gamesmanship of the data’s value.
Once the discussion is concluded, changes are made to the idea, which may include updating details about the idea and adapting the value. The idea floats to the level of its adapted value.
If it continues to appear that the idea is of high value, it is time to consider the team (or teams) that will work on it and the dependencies the team may have on other teams and resources.
Once identified, the team is notified of the idea coming it's way. The purpose is to gauge how much work that team already has on its plate. From here, people and prioritization decisions can be made.
When making people decisions, if it is clear that this team is the target for a lot of high-value work, then it behooves the enterprise to add people to the team or adopt another team’s skills to that type of work.
When making prioritization decisions, if it is clear that this new idea has a higher value than current work in the team backlog, then a re-ordering of work should occur.
If a high-value idea requires the help of two or more teams, a chief product owner or portfolio leader can gauge how much work each team has on its plates and when it can pull the work into its backlog based on its current velocity during the Reveal stage.
The goal by the end of the Reveal stage is for teams to provide a pull signal for the high-value work at the earliest possible moment so the idea misses as little of its market window as possible.
In order for a new high-value idea to get pulled in a reasonable timeframe by the teams, a discussion on slack time should occur. If teams’ backlogs are so full that it makes it hard for them to pull work in the foreseeable future, then you may not be allowing enough slack in the system. The benefit of slack is twofold.
First, slack helps a team consistently deliver on their commitments with quality work since important design and refactoring emerges. Second, slack allows time to respond to emergencies, time to explore high-value work, and time for innovation. Without slack, a lot of high-value ideas could easily sit in a wait state for some time.
Refining the Idea
The Refine stage consists of a combination of the team(s)’ beginning to understand the idea, the team(s)’ beginning to decompose the idea into an increment and user stories, and their continuing to validate the value of the idea. When the high-value idea sitting in the reveal pool gets pulled by the team(s), it is ready to get refined.
The intent is to move away from the big upfront mindset where months are spent attempting to document all of the requirements. Instead, collaboratively focus on a slice of the idea where feedback is used to gain a better understanding of the value of the idea.
Who should be involved in refining and decomposing ideas into smaller pieces? Those that have ownership over products (product owners) and those that self-organize on how to build those products (teams) should be involved. In this case, everyone on the team should be involved including developers, testers, architects, database, and UX.
They should all have a stake in the success of the work and be educated and operate with a discovery mindset. Also, you want the whole team involved so that when it is time to build the idea increment in the Realize stage, the full team has first-hand knowledge of the work involved in the Define stage.
While you may have learned that more than one team is involved in the idea during the Reveal stage, it is in the Refine stage where you learn the details of the dependencies. An idea may cross team and division boundaries. During the Refine stage is when the beginning of cross-team coordination should occur.
It can be challenging to take an idea and decompose it into epics and user stories. One recommendation is user story mapping. The short-form story mapping is both a visual practice that provides you with a view of how a user might use an idea (in other words, the product or service) and a decomposition practice that helps you consider how you may incrementally decompose the idea.
Established by Jeff Patton, the visual portion helps the team understand the customer experience by imagining what the customer process might look like. This encourages the team to think through what the customer finds as valuable.
A benefit of story mapping is that as you work incrementally, one slice at a time, you validate the value that has been ascribed to the idea. Instead of building the whole idea over months, you build a slice and then get actual customer feedback as to the value of the idea. The feedback is used to adapt toward customer value as well as to update the idea record and the value score.
You should only cut one slice at a time. You may learn that the first slice either provided the value or that the customer didn’t find the idea valuable enough to move further.
There are other ways to decompose ideas into increments. Use cases can be used to map interactions between actors (which can be personas) and a system within a particular environment to achieve a goal.
Much like story mapping, the goal is to cut a slice or increment of work that represents one of those interactions and then show it to customers or users to get feedback on the value of the idea and the customer interface.
Another activity that helps decompose and, more importantly, better understand the business and technical detail of the work is the act of grooming (also known as Scrum refining). The end goal of the Refine stage is that you have a slice of work from the idea that should be in the form of epics and user stories that can be placed into your product backlog.
Another goal is that you are aware of the dependencies and risks that can impact the work ahead and begin mitigating them.
Realizing the Idea
The Realize stage is the art and practice of building the idea into a working product. Commonly known as product or software development, it is the art of developing a product in a methodical manner.
All team members who engage in building a product are involved in the Realize stage. Those involved should include all cross-functional team members such as development, quality assurance (QA), database, UX, documentation, education, and configuration management—effectively anyone who has the ability to turn the idea into a piece of customer value.
In the Realize stage, the product owner has a strong role to prioritize the work in the backlog according to customer value, to share business context with the team, and to incorporate customer input and feedback as the idea evolves to better align with customer value.
In the Reveal stage, you may have learned that there is more than one team involved in building the increment of an idea. In the Refine stage, the teams should work together to cut the first increment.
Now in the Reveal stage, the teams should establish communication touch points such as Scrum of Scrums to coordinate and collaborate as they build their pieces of the increment.
Within the Agile galaxy, it is in the Realize stage where you typically see Scrum and Kanban occurring. Irrespective of what Agile process used, an iterative process should be applied so that you can iteratively plan, build, inspect, and adapt the deliverable toward customer value.
The primary activity involved in the Realize stage is to develop an idea. From the Define stage, the epics and user stories from the slice or increment make their way into the product or team backlog(s).
The team(s) should further groom the epics into user stories and gain more detail about the user stories. From there, an iterative approach should be used to develop and test the product.
Iterative and incremental Agile engineering practices should be applied in the Realize stage. This may include eXtreme Programmings (XP) practices such as pair programming, continuous integration, test-driven development, collective code ownership, refactoring, and more. Also, integration testing should occur for those instances where two or more teams are working on an idea.
This should include a system, performance, load, and any other tests that may be needed. The goal of Agile is that when the product is completed at the end of an iteration, it should be potentially shippable.
Because the Realize stage results in a potentially shippable product (that is, something to actually see), customer feedback loops should be used to validate if the idea is valuable to customers.
There should be a concerted effort to invite customers based on personas to the demonstrations to gain valuable feedback to ensure the idea is being developed in the direction of customer value. Also, sales and marketing may initiate a launch plan for making current and potential customers aware of the new or updated product.
Releasing the Idea
The Release stage is the activity that converts the in-house built idea and launches it into the public, the goal of Agile is that by the end of an iteration, it should include activities to make the idea potentially shippable. Then there may be final integration testing, code preparation, packaging, and launch activities in a release.
Record Reveal Refine Realize Release
In some cases, there may be final integration activities, particularly when there are two or more teams working on an increment of an idea to ensure both pieces execute together.
Final integration testing provides an opportunity to perform final testing to include system, integration, performance, load, and any other tests that may be needed. This should be limited since such testing or a significant portion should occur in the Realize stage.
Code preparation and packaging begins with version controlling the code used for the release. From there, activities vary by production platform. For a website, identifying the executable code and updating the website with the new code may be all that is needed. For mobile applications, packaging the new release onto an app store for people to download and providing any terms and conditions may be enough.
For on-premise products where they are installed onto desktops and servers, setting up a downloadable web location for code or burning the code onto disks, packaging user guides, and crafting terms and conditions are part of the process.
Another aspect of the Release stage may be to execute the launch plan drafted by marketing and sales. This activity communicates to the current and potential customers a bit about the new increment that is now on the market. Once a release occurs, you should update the enterprise idea pipeline showing that the first increment has been released.
Reflecting on the Idea
The five stages of the 5R model have been explored: Record, Reveal, Refine, Realize, and Release. Some collapse the 5R model to 4Rs (Reveal, Refine, Realize, and Release). Some expand the 5R to a 6R model. I have found it prudent to include a sixth R called the Reflect stage.
While most product development life cycles end at the Release stage, I believe it is important to add a phase where you reflect on the results of the deliverable, How well did it do once it was on the market? How many customers were willing to pay for the product? Was the deliverable satisfactory to customers? Is the product being used as advertised?
There are many types of feedback loops that can be used to gain an understanding of the product. This is why reflecting is very important in understanding the real value of the product. The feedback helps you determine how to adapt the idea for the future.
Most importantly, the Reflect stage ensures that you revisit the value placed on the idea in the Record and Reveal stages. Did you make the money you thought per what was written into the value or cost of delay of the idea?
It is critical to the integrity of the R model that those involved understand that once released, you will reflect on the idea and gauge its real value.
While challenging the assumptions of value for an idea in the Reveal stage reduces gaming the value score, having to reflect on the actual value data once released can help further reduce any gamesmanship of the value data at the beginning.