Agile principles and Roles Tutorial 2019
An Agile and customer-value-driven enterprise is an organization that optimizes its roles in a manner that focuses on the Agile values and principles and customer value.
Optimizing Enterprise Roles and Principles for Agile
Organizational roles and their functions are part of transforming to Agile. What this means is that each function must operate such that it can readily adapt to the needs of customers and market conditions.
Are current roles and their functions constraining or embracing the need to adapt toward customer value? Embracing the need should be the goal.
What roles and functional areas should be optimized to the changing needs of customers and the marketplace in order to have better business outcomes? The short answer is all roles and job functions should contribute.
What you are really looking for is what roles directly contribute to customer value. the two- degrees- of-customer-separation rule can be an effective means to determine how far away any one employee is from the customer.
Two degrees of customer separation would be “you (as an employee) connected to an employee connected to the customer.”
The farther away employees are from the customer, the less likely they understand what is considered valuable to the customer. Aligning the roles in your Agile galaxy to customer value will often require a shift in how the organization is run and may entail adapting roles and responsibilities.
Obvious Agile Roles
If you look across an Agile galaxy, there are obvious roles and less obvious roles that should be adapted toward an Agile mindset and aligned with the delivery of customer value.
The obvious roles tend to primarily focus on the team level. However, in an Agile enterprise, the norm is that all roles adapt toward an Agile mindset and align with the delivery of customer value. If they do not, there may be an opportunity to streamline toward alignment to customer value.
Roles in the “obvious” group tend to be the first to apply Agile for several reasons. Development teams are more receptive to apply Agile. Management departments, on the other hand, find it easier to ask teams to change to Agile without themselves committing to the change.
Also, team -level Agile processes are more prevalent and have a mechanical feel, making it easier to apply the culture changes.
In both the obvious and less obvious sections, there is advice on how to adapt to each role. These blogs highlight what it means to be a customer-value-driven enterprise, the importance of the customer and employee, what an Agile galaxy looks like, and what it means to embrace the Agile mindset.
All roles should have this level of understanding. The role or functional areas that tend to fall into the “obvious” grouping are:
A development team consists of a group of people focused on building the product or service. It is comprised of cross-functional roles such as development, quality assurance (QA), database, user experience (UX), documentation, education, and so on.
When moving toward Agile and customer focus, development teams must learn the Agile values and principles and apply Agile behaviors and processes as they incorporate customer needs into the delivery of customer value. They should apply a discovery and incremental mindset and processes that will help them evolve their deliverable toward customer value.
While technically focused, they should gain business knowledge from the product owner so they can better understand the customer and customer value.
The Scrum Master is the facilitator for a team applying the Scrum process when building customer value. Scrum Masters lead the team through planning, daily stand-ups, retrospectives, and supporting the demonstrations. If not using Scrum, the role may be called the Agile facilitator or coach.
When moving toward Agile and customer focus, this new role focuses the team on the Agile mindset, Agile processes and practices, and the delivery of customer value.
This new role in Agile often replaces project managers; ScrumMasters act more as facilitators of the Agile process and servant leaders to the team. This may be a significant shift for some companies where functional managers or project managers have always played a more directive role.
The product owner (PO) role is responsible for identifying and prioritizing the work according to customer value and for incorporating customer input and feedback to better align with customer value as the product evolves.
When moving toward Agile and customer focus, the PO is the champion and owner of customer value. This may be a shift for some companies where others play this role. The PO works with the team to ensure the team members realize customer needs and the business perspective of the work.
The PO is the customer advocate and captures customer feedback to move the product in the direction of what the customer actually needs. The PO contributes to sprint planning and invites customers to attend the demonstrations.
This new role may be played by an existing role engaged with the customer, such as a product manager or business analyst. It requires the person performing the role to engage regularly with the team. The PO must have decision-making rights to steer the product toward the direction of customer value. For more information on PO responsibilities.
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:
A customer is someone who has a choice on what to buy and where to buy it. By purchasing your product, a customer pays you with money to help your company stay in business.
Because of these facts, engaging the customer is of utmost importance. Customers are external to the company and may provide the initial ideas and feedback to validate the ideas into working products.
While not always obvious, the customer role should be front and center when working in an Agile context. Your customers are your business partners and your goal is to build strong customer relationships.
While customers should be invited to product demonstrations and provide feedback, they should really be asked for their opinions all along the idea journey from identification to delivery to the reflection of customer value.
[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.
Business Leaders (Including Marketing and Sales)
The business department, including marketing and sales, focuses on developing products and services that meet customer needs. They focus on customer value by understanding current demand, marketplace trends, competition, brand value, and overall customer needs. The best product owners come from the business side and its employees can be an effective part of a PO constellation.
When moving toward Agile and customer focus, the business side (specifically the product owners) becomes the driver for capturing customer value. All those on the business side should learn Agile, embrace the discovery mindset, and begin to operate in more of an incremental manner.
Roles in this space should be no more than two degrees of separation from the customer. All business personnel associated with a product should attend demonstrations as products evolve.
Traditionally, middle managers carry out the strategic vision of executives, create effective work environments, coordinate and control the work, and supervise groups of people who do the work.
They may have functional and technical ownership of products. They also provide performance management and career development to their people.
When moving toward Agile and customer focus, middle managers must build a healthy Agile culture by encouraging their teams to align with Agile values and principles and focus on being customer-value -driven. They must adapt and act as a coach and servant leader toward their teams and become less directive.
They must trust their teams to make good decisions, establish bounded authority, create safe work environments, and remove an employee and team roadblocks.
They should focus on the optimal location of people that reduces impediments and enables the flow of work. They should promote career and personal development through continuing education and apply Agile-minded performance excellence.
If middle managers have strong product knowledge, some functional management members shift their roles and become a PO since the PO now owns the product direction. Because of less functional responsibility of their teams, some managers may evolve from a functional manager to a resource or career manager.
Middle managers are often the lynchpin that allows the executive’s vision for Agile to thrive in the team setting. If they embrace Agile, then the change may succeed. Otherwise, they can block the change toward an Agile culture if they feel the need for control and won’t allow a team to self-organize.
Human resource (HR) departments focus on managing company processes, policies, and standards while carrying out management programs that focus on employees.
More specifically, HR engages in recruitment, employee relationships, performance management, corporate communications, employee benefits, and pay structures.
When moving toward Agile and customer focus, HR can help build a healthy Agile culture that optimizes for engaged and happy employees. HR should be knowledgeable in Agile and what it means to be a customer-value-driven enterprise. HR should promote the values of collaboration, ownership, motivation, empowerment, trust, and safety (COMETS) for employees.
HR should recruit those candidates with an Agile mindset and align performance management from individuals to teams. HR works to adapt all roles toward an Agile mindset as described in this blog and, in particular, to move management toward a coaching and servant leader role. For more on evolving HR to be agiler.
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 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 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.
The project management office (PMO) focuses on defining project standards and supporting projects in the latter part of the delivery axis of the Agile galaxy. Traditionally, the PMO is directly involved in managing projects and often supply project managers to lead them.
PMOs supply output metrics and report on the status of projects. They may initiate project status meetings to determine how projects are doing.
When moving toward Agile and customer focus, there may be a significant shift in how the PMO operates. Since most work in Agile is facilitated by a ScrumMaster with the Product Owner in deciding the value and priority of the work, there is less work for a project manager to do.
It is not uncommon for some project managers to become ScrumMasters, depending on their ability to adapt to an Agile mindset and act as a coach and facilitator.
It is not uncommon for a PMO to adapt to a leaner AMO (Agile management office). In an Agile environment, the focus is not the project, but the incremental delivery of value.
Establishing a project implies you can know customer value upfront. In Agile, the team creates increments of value and the PO collects customer feedback used to adapt the product toward customer value.
While the PMO may be leaner due to the ScrumMaster and PO, the PMO may focus on managing bigger releases where multiple teams are required to build the product.
As the PMO adapts to an Agile culture and processes, it should also adapt reporting toward understanding value delivered, speed of delivery, quality of delivery, and business outcomes of revenue generated. Of course, the PMO should learn Agile and what it means to be customer-value-driven.
Importance of an Agile Coach
The Agile coach plays a big role in getting Agile off the ground. It can be beneficial to have a coach with an enterprise Agile experience because he or she can help you navigate toward an Agile culture and the deep Agile implementation knowledge that ensures teams are implementing Agile effectively.
While education will provide initial knowledge, a coach can keep you on the Agile path and prevent you from reverting back to old, traditional habits. The coach also understands the short-term and long-term pitfalls of adopting Agile and that Agile is a culture shift and will take time. The coach can help the team move to Agile in a more effective and efficient manner.
With that being said, it is important to gauge whether the Agile coach really understands Agile and what levels he or she has operated in (for example, team, management, and enterprise).
As a tip, ask perspective coaches if they can articulate and discuss the Agile values and principles (without referring to a blog or the Internet). Ask them what level(s) they have coached. For each level, ask them what challenges they have encountered and how they overcame them.
As you move to an enterprise where employees are engaged and teams self-organize around work, there is a benefit to providing guidance on the boundaries of the various roles and their activities.
Instead of approaching this by trial and error where teams bump into the boundaries with often negative consequences, consider applying the concept of bounded authority.
Bounded authority is defined by the sphere of responsibility determined by who has the most knowledge and experience over a particular aspect of work. Those people should have the authority and decision-making rights over that work.
For example, the group having the most knowledge about enterprise strategy is senior management. The group having the most knowledge about designing and building a product is the team.
Within a hierarchical structure of a company, the bounded authority can help at multiple levels.
Within an Agile context, the goal is to push ownership and the authority and decision making it brings to the lowest possible level where most information and experience dwells.
For an Agile team, the members self-organize around the work in the product backlog that has been prioritized by the PO. Once that work is available at the team level, the team has authority to make architecture, design coding, and test decisions, and it can self-organize around how to build the product.
The key to bounded authority is that each level knows what work it should self-organize, what it is empowered to change, and the areas in which it can make decisions. Another key is that each level knows the authority of another level. Equally important is that this implies what authority a level does not have.
If the team’s work is prioritized by the product owner, what does middle management do? Can they assign work to the team? The short answer is no since the team gets their work from the PO via the product backlog.
While the team self- organizes around the work, middle management helps optimize flow for their teams by removing impediments and enabling the teams to be it's most effective.
Senior management should be focusing on the work where they have the most knowledge and experience. Their bounded authority of work may be to provide a strategy for the enterprise. This means they must help teams understand strategy and help them align strategy with their work.
Another option is the concept of seven levels of delegation where the bounded authority guidance is at the activity level instead of the role level.
Established by Jurgen Appelo, this concept expands the binary view of the authority of a decision (for example, you have the authority or I have authority) into seven levels of delegation. They are the following: tell, sell, consult, agree, advise, inquire, and delegate.
As you may guess, on one end of the spectrum “tell” means that the manager fully owns the decision, and on the other end “delegate” means the decision is fully owned by the team while not even telling the manager the outcome.
The value of this model is that some managers are not ready to give total authority of the decision away, so they may incrementally move to a less authoritative position (for instance, from tell to consult) where the manager now asks for input before making a discussion. You can learn more about the seven levels of delegation in Managing for Happiness.
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 you look at the various trust relationships, an important connection is between an employee and his or her direct manager. Managers are responsible for maintaining a healthy and happy workplace. Managers need to make extra efforts to build trust with their employees and promote an open and honest workplace.
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
Enter the continuous learning Agile 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 you 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: Education Is More than Training
Does your Agile education begin and end with a touch of training? A number of colleagues have told me that their Agile training was completed in one hour, one day, or two days, and then they were expected to apply and master the topics.
Agile isn’t simply a process or skill that can be memorized and applied. Will such limited training time suffice for a transformation to Agile? Probably not, as insufficient training time limits the success of effectively implementing Agile.
Education is an investment in your people. A shift in culture requires an incremental learning approach that spans across time. What works in one company doesn’t work in another. Education should be an intrinsic part of your Agile transformation that includes skills, roles, process, culture, and behavior education with room to experience and experiment.
When you want to adapt your enterprise culture, you need the education that includes more than just skill building. Culture change is a transformation that involves the most change and requires the most time for an organization to adapt. To support that change, there are educational elements that are suited for achieving Agile skills, roles, processes, and culture.
These elements include training, mentoring, coaching, experiencing, experimenting, reflecting, and giving back. These education elements should be included in your culture change.
Training is applied when an enterprise wants to build employee skills, educate employees in their roles, or roll out a process. It is often event-driven and a one-way transfer of knowledge.
What was learned can be undone when you move back into your existing culture, and it can be forgotten if not applied quickly. Coaching can reaffirm the training. Also, training can occur in an instructor-led manner where it is scheduled or in a web-based manner where the material is pre-recorded and can be used on demand.
Reading allows individuals to focus on topics of their own interest and at their own pace, but it does require self-motivation. Readers can use a physical book or e-book. The reading often includes articles, journals, podcasts, and blogs.
Reading offers the advantage of going back to the source of the article, blog, or section. Reading can also be done in with the aid of blog clubs where teams or groups read and then discuss a topic.
Coaching helps a team put the knowledge of process and roles into action and lays the groundwork for transforming the culture. Coaching provides a two-way communication process so that questions can be asked along the way.
If you do not have a coach, it is very easy to apply a process incorrectly or give up and revert to the old process. A coach has been on this journey before and can help you until you are enacting the process or practice correctly with the right behaviors for the culture you want.
Mentoring focuses on relationships and building confidence and self-perception. The person being mentored (mentee) invests time by proposing topics to be discussed in the relationship.
In this two-way communication, deep learning can occur because the mentee is asking questions and seeking answers without being prompted. Mentoring allows individuals within an enterprise to better understand their place in the culture.
Experiencing focuses on living in the new process, applying the skills, and experiencing the new roles. This provides individuals with first-hand knowledge of what they’ve learned, allowing them to better understand the behavior changes needed. It allows for deeper questions, further exploration, and experimentation.
Experimenting focuses on trying something new for a short period of time in order to test a proposed change. The change often begins with a hypothesis on what might work better and then is crafted into a short test to see if the new idea had the effect or improvement set out by the hypothesis. Experimenting is a way to try concepts and practices before fully committing to a change.
Reflecting focuses on taking the time to consider what you learned—whether it is a skill, process, role, or culture—and determine what you can do better and what else you need on your learning journey.
In effect, it is similar to an Agile retrospective that can occur at the employee, team, or enterprise level. It is a feedback loop to consider where you’ve been and what you need to achieve an Agile culture and a customer-value-driven enterprise.
Giving back occurs when the employees have gained enough knowledge, skills, and experience to start giving back to their community. It is a commitment to start helping others. This provides a feeling of ownership in a transformation of the culture. Giving back can be to the company, local community, or greater community.
It takes a repertoire of educational elements to achieve an Agile culture. These elements help a team develop skills, learn its roles, navigate a process, and grasp behavioral changes toward achieving an Agile mindset. Ensure you apply a repertoire to your learning.
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 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 a 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.
How will your teams be educated?
An accumulation of education elements at different points in time will provide a comprehensive focus to help you, your team, and your organization.
Consider applying a self-organized education vision that best serves your goal of being Agile. You want to create a self-organizing education culture where employees are eager to learn, act, and give back to their community.
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.
Is It Time to Learn?
Do you work in a continuous learning enterprise? Injecting a continuous learning mindset can help people understand that there is a lot to learn and that the knowledge gained can only help your enterprise succeed.
It takes a repertoire of educational elements to achieve an Agile culture. An accumulation of education elements at different points in time will provide a comprehensive focus to help you, your team, and your enterprise.
Consider establishing an iterative and adaptable Agile education vision for yourself, your team, and your enterprise that best serves your goal for an Agile transformation and the delivery of customer value.
Ultimately, you want to create a self-organizing learning culture where employees are willing and eager to learn new topics and make themselves and their enterprise more successful.
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 a 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.
Enhancing the Culture with Discovery
I discussed the importance of activating an Agile culture within your Agile galaxy. This means all roles from team to management and operational roles (HR, finance, and so on) in all quadrants of the galaxy should embrace the Agile and discovery mindset.
It is within this third dimension of your Agile galaxy that the discovery mindset and thinking approaches belong. The discovery mindset complements the Agile cultural attributes of COMETS (Collaboration, Ownership, Motivation, Empowerment, Trust, and Safety).
While COMETS are attributes you want to see in the people within an Agile galaxy, the discovery mindset contains the approaches people can use to methodically learn what is valuable to the customer.
The goal of both is to cultivate positive behaviors. The three-dimensional view can help you understand your starting point, where the discovery mindset is occurring, and where you need to focus.
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 the 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 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.
Feedback thinking is the belief where you embrace feedback, realizing how it provides you with information that can guide you toward what is valuable.
Collecting feedback can shatter the certainty mindset since feedback will often highlight differences in what is stated upfront as customer value and what a customer actually finds valuable. Key to feedback thinking is not just capturing customer feedback, but using it to adapt toward customer value.
Applying feedback thinking can be a big shift for some organizations that embrace a certainty mindset, don’t currently collect and apply customer feedback, or don’t intuitively understand the value it will provide in building products of customer value. Feedback thinking means that there is a pervasive need to collect customer feedback via feedback loops in as many areas across the delivery axis as possible.
Feedback thinking brings in many voices to validate the direction through multiple feedback loops and is crucial to help course-correct toward customer value. The primary feedback collected should be from the actual customer.
The customer is the most important voice in shaping the direction of the product. Customer feedback should be the basis for driving the majority of your decisions and setting the direction of customer value.
A benefit of feedback thinking is you gain real-time information on what the customer finds valuable since what customers find valuable changes over time.
Incremental thinking along with feedback thinking to build customer value allows you not only to learn what the customer wants but also to gauge if there is a shift in the marketplace. This real-time data (in other words, feedback) allows you to adapt to the ever-changing customer landscape.
Feedback thinking is an integral part of the discovery mindset. Feedback works well when paired with incremental thinking, experimental thinking, divergent and convergent thinking, and design thinking.
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.
Is It Time to Lead with the Discovery Mindset?
The discovery mindset and the thinking approaches are meant to create the behaviors for the Agile mindset to move the culture toward agility.
They are great to ready-the-mind and set the tone for the behaviors that focus on customer value. Leading with mindset activities avoids the trap of believing that mechanically applying an Agile process makes you Agile.
Instead, it is a great way to achieve the Agile behaviors that can help your enterprise shift to an Agile culture and lead you toward customer value.
As you approach your Agile transformation or you realize that you need an injection of the Agile mindset, consider educating leadership and teams with a discovery mindset and the thinking approaches it embraces.
Consider infusing incremental thinking, experimental thinking, divergent and convergent thinking, feedback thinking, and design thinking into your Agile environment in the early part of your transformation.
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 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 its 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 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.
REFLECTION OF VALUE EXERCISE
Consider the last release you were a part of. Attempt to find the value data that was used to promote the idea. This may be in the form of return on investment (ROI), cost of delay (CoD) or potential revenue data. Then look for the actual revenue made from the release. What was the difference? Has anyone actually compared the initial value data with the actual?
Are Your Enterprise Ideas Visible?
The enterprise idea pipeline provides you with an end-to-end view of the flow of ideas from the moment they are recorded when they are released. As an enterprise-level portfolio backlog of ideas, it is meant for the enterprise to respond to high-value ideas the moment they come to the enterprise does not miss the idea’s window of opportunity.
It is a more adaptable way of managing the portfolio of work across your enterprise and responding to feedback. Specifically, it is meant to highlight high-value ideas the moment they come into an enterprise so that they can be worked on almost immediately and the enterprise can take full advantage of the window of opportunity.
Whatever you chose to call the enterprise idea pipeline, it holds the big ideas that will eventually (or immediately) be worked on by the teams. The enterprise idea pipeline is the parent to all of the product backlogs and helps you connect ideas to user stories.
The operation of the enterprise idea pipeline feeds right into your enterprise Agile budgeting and investment process. It can help you see where your high-value work is.