DevOps Dojo: Lean Product – Part 1
Being smart is about knowing what you want.
Being wise is about knowing what you don’t want.
To become wise, you need to have models in your head. Models are formal structures represented in mathematics and diagrams that help us to understand the world. Mastery of models improves our ability to reason, explain, design, communicate, act, predict, and explore. When our thinking is informed by diverse, logically consistent, and empirically validated frames, we are more likely to make wise choices.
We will dedicate three blogs to exploring the product-centric model and the lean product model developed by our DevOps Dojo community. This blog is Part 1.
I: Introduction
During the initial ideation of Dojo’s vision and strategy, one critical component was to define a complete end-to-end DevOps taxonomy to be used for the classification of DevOps capabilities, as well as the principles underlying the classification. We all understood that Culture, which includes people and mindset, was an important pillar. We all agreed that Technology was an enabler as a pillar. We also purposely put Architecture as a pillar because it has been a frequently underestimated yet highly critical component of DevOps. Finally, we had Process as a pillar, though most of our debates were regarding this pillar.
Value Stream Mapping
The first option we suggested as a Dojo process was Value Stream Mapping, as it was used intensively in our support organizations. While it is a great process for evaluating the value stream and identifying waste, it doesn’t describe what the ideal target process should be in DevOps. Also, it was usually used to evaluate the IT process, which starts from business requirements given by business stakeholders.
Scaled Agile Framework (SAFe)
When the SAFe method was suggested, the opposition started pouring in. The fact was that Microsoft product groups never used SAFe, and our services organization didn’t have expertise in SAFe, so it didn’t make sense to use SAFe as our process because we would not be able to walk the talk.
Other Process Frameworks
There were other options suggested too such as IT4IT and ITIL, but they didn’t fit our strategy—we played in the joint space of Business, IT, and human-centric design in DevOps.
Speaking of strategy, it is important to understand that a strategy has three elements in its kernel: problem analysis, guiding principles, and coherent actions. So, what was the problem we tried to solve? As mentioned in our blog #1, our DevOps point of view is more than the IT functions of Dev + Ops. Our DevOps’s People MECE (Mutually Exclusive, Collectively Exhaustive) principle includes Business, IT, customers, and partners. Therefore, the process must cover more than IT organizations.
Product-centric Model
According to the research article, Gartner Predicts 2020: Agile and DevOps Are Key to Digital Transformation,
“In the future, we will no longer have a divided conversation between agile, DevOps and project teams. It will be a product-centric value stream conversation with a singular focus on customer value.”
This research has shown that the industry is moving from the project-centric model to the product-centric model.
When we were designing DevOps Dojo, we didn’t think of Dojo simply as a short-term program. We believed Dojo was a transformational program for both internal Microsoft Services and our customers, so our vision went much farther than the short-term view. The product-centric model might be new for most industry customers who are still in the project-centric model, but the product-centric model is not new for product companies like Microsoft, who have been making software products for decades. As you can see, our vision goes beyond the product-centric model.
After gathering extensive research from industry analysts, reviewing studies from thought leaders in the product-centric model, and having many fierce debates within the Dojo community, we landed on the process pillar called “Lean Product” in early summer 2019.
Having a name for the process was only the beginning of the journey, as the road on our Lean Product journey has been bumpy. Let’s look back at our history to understand what we have learned so far.
With a few of us who were passionate about Lean Product, we finished our White Belt point of view and exercises on time. We decided to release it before we collected more reviews and feedback from the community. With great excitement and high expectations from the core team, we agreed to deliver the White Belt Lean Product content to four Master Classes in one of our biggest internal face-to-face Dojo readiness events. This was before the pandemic.
Alas, we stumbled terribly. But why?
In our retrospectives, we learned some very good lessons about what we had not put into consideration during our design:
-
The participants didn’t understand why we adopted the product-centric model in service organizations as we have been using the project-centric model in our deliveries.
-
The participants didn’t understand the product-centric model, let alone understand the LEAN product-centric model.
-
We didn’t provide a point of view to describe how to transition from the project-centric model to the product-centric model.
-
We didn’t provide a point of view to describe the difference in roles between both models and how to transition from people perspectives.
-
We didn’t offer a point of view on contract options related to the product-centric model for our service delivery.
Despite the setback, we didn’t consider it a failure, but rather a great learning experience on this important topic. We decided to redesign the entire Lean Product content in the White Belt, Orange Belt, Green Belts, and Black Belt with the following guiding principles and coherent actions:
-
White Belt to cover the basics of product-centric model
-
Orange Belt to cover all elements of lean product model
-
Green Belts to cover lensed view of lean product model
-
Black Belt to cover C-level view of lean product model
It is worth mentioning a good leadership lesson we learned:
“A good leader can’t get too far ahead of his followers.”
– Franklin D. Roosevelt
II: Intro of Product-centric Model in White Belt
Based on what we learned from our previous missteps, we revisited our design with the following content in Dojo White Belt. In the new design, we had two hypotheses. First, we assumed that most people were familiar with the project-centric model, so bringing a clear comparison between project-centric and product-centric models should lead to better and broader acceptance of the product-centric model. Second, we assumed that most people in Service organizations would like to discuss how this model would impact the service organization including contract options, resources planning, skill readiness, etc.
We will discuss the following topics:
-
Visual examples of project-centric model vs. product-centric model.
-
Class exercises to discuss their observation of project vs. product.
-
Comparison of roles in project-centric model vs. product-centric model.
-
How to transition from project-centric model to product-centric model.
-
Various topics related to product-centric model in Service organizations.
III: Why use a Product-centric Model
The best way to help participants quickly appreciate the benefits of the product-centric model is to create a contrast. Because a picture is worth a thousand words, we decided to bring a side-by-side comparison of both models, then we asked participants to share their own observations leading to their own conclusions. Participants immediately appreciated what the product-centric model can lead to. Understanding and accepting the model was a big step forward in transitioning to a product-centric model.
The following is a case study we used in the class.
Here we have a fashion company that offers on-site and on-line services for customers to buy fashion products from the company’s store or online web site. With an increasing demand for both personalization in fashion and reduction in mass production to support sustainability, the company decided to add a new service called “New Look”. This service allows customers to upload their favorite looks from celebrity photo shoots, social media, or their own creation, and then the company makes a personalized look for the customers based on their unique requirements.
Here is how the project-centric model works when the new service is built.
Step 1: The relationship between business and IT is that IT primarily takes detailed project requirements from business, executes the projects based on the budget, then hands them off to business and operations after acceptance.
Step 2: With the “New Look” business case, business works on creating and approving the business cases based on the various inputs from business stakeholders. Once it is approved, business creates business requirements and asks IT to provide an estimate. Then, the project is funded for the time it would take to finish the “New Look”.
Step 3: A project team is formed with a new project manager and a new architect who both need to put a project plan and staffing plan together. In parallel, the fulfillment team needs to find a partner to handle fulfillment as it is not currently supported by the company. A new program manager is assigned to orchestrate various collaborations with the web site team and marketing team to ensure that everyone is aligned with the tight schedule.
Step 4: The project team is staffed but with a lot of challenges, as there is a significant learning curve for the new team, and it also takes time for the team to build trust. The team also needs to build the DevOps platform and onboard new team members, so velocity is low during the first few sprints.
Step 5: Since all four teams have not worked together before, there is a significant amount of alignment, negotiation, and coordination between the four teams. The fulfillment team is an external partner and paid by time and material (T&M), but they heavily depend on the project team to provide an interface so they can develop their components in parallel. Unfortunately, the project team takes a long time to form a team and sort out various logistics, so the project team can’t provide the functional interface to the partner until a few months later.
Step 6: The project finally goes live into production after over nine months of development.
Step 7: At this point, the project is closed, so the project team is released. All resources are reassigned to other new projects.
Step 8: A few months later, the new offering misses the mark. This failure occurred partially because of a miscalculation of the AI model based on the look itself for the recommendation. The more sophisticated recommendation model should have been used, for example, utilizing insights such as fashion influencers’ connections and influencers’ seasonal updates.
Step 9: At this point, the original team has been released, so another round of funding and staffing is required to improve this offering.
Step 10: The same process is kicked off again. As you can see there is so much human capital wasted in this project-centric model.
Here is how the product-centric model works when the new service is built.
Step 1: In this model, business and IT is organized by the product-centric model.
Step 2: The company is a customer-centric product company as the product organization is based on the customer journey with respect to the fashion products. There are four product teams to support the customer journey.
Step 3: The “Offer Fashion Products” Team focuses on building a fashion product catalog based on market research. They are experts on industry trends, regional demands, competitive analysis, pricing, and new markets.
Step 4: The “Attract Customers” Team focuses on customer data including their preferece, their life events, their social network, their buying habits, their influencers, and more.
Step 5: The “Order Fashion Products” Team focuses on their on-site and on-line shopping experience, order history, shopping cart abandonment, wish list, gift cards, promotion, etc.
Step 6: The “Fulfill Fashion Products” Team focuses on fulfillment, return, credits, etc.
Step 7: The new offering of creating your new look will involve the customer team, ordering team and fulfillment team. If the new look is popular, it can be added to the product catalog as well. With the new look uploaded by a customer, “Attract Customers” team is required to capture insights about the customer’s tastes, likes, dislikes, lifestyles, influencers, life events, and future recommendations. The “Order Fashion Products” team is required to add new functionalities including uploading and processing media, a body scan for the customer’s size, a new pricing calculator based on materials, remarks field for additional requirements. The “Fulfill Fashion Products” team will then take the input from the order form to create the custom design, the return policy will most likely be different from that of regular products.
Step 8: A long-lived product team is responsible for this new offering and epic/features, which significantly reduces start-up time. They treat this new offering as any new epics and new features of the product. The teams have already worked together for a long time with trust. With the new features, they can focus on building the new capabilities without wasting any time.
Step 9: The product teams work together to deliver this new offering. Once it is in production, the product teams continue working on other new features in their backlog.
Step 10: A few months later, if the new offering doesn’t meet the mark, the same team can review the insight and decide on the root cause based on the learning, the same team can develop a new version of the features, and the same team can then measure, learn, and improve. In the long run, product-centric organizations are much more effective in customer experience, cost, agility, and business outcome compared to project-centric organizations.
Recap & Experiential Learning
Part of our experiential learning in Dojo is to not provide the answer or definition of a new concept to the classes at first, but rather to offer a problem for class to solve. By analyzing the problem state in great detail and then discovering the pattern, the class could learn much better together as a team. When we did offer a definition of the product-centric model after the exercise, it indeed made sense for all participants. We included two definitions of the product-centric model below.
Definition by MartinFowler.com: “Product-mode” is a way of working. It is a way of funding and organizing software development that differs significantly from the projects’ way of doing it. Although generally applicable to digital-age enterprise IT, this way of working is especially suited to those who aim to drive business through a digital platform.
Definition by Gartner: A business-centric strategy for delivering software and digital experiences in which a product is developed that delivers an ongoing business capability (as opposed to a limited time project-based project). Generally, a product manager owns this product and is responsible for its ongoing development and its budget. This product may exist on a platform, which is essentially a product on which other products are built.
IV: Project-centric Model vs. Product-centric Model
A good analysis simplifies the often overwhelming complexity of reality by identifying certain aspects of the situation as critical. Here are what the particpants came up with after their observations and discussions. The classes did a good job in finding the core concepts of product-centric model. We have only listed four comparison diagrams below that came out of the class discussion.
Success criteria for Project-centric Model vs. Product-centric Model
Attributes for Project-centric Model vs. Product-centric Model
People or Work for Project-centric Model vs. Product-centric Model
InsideOut or OutsideIn for Project-centric Model vs. Product-centric Model
V: Project Managers vs. Product Managers
After we understand the differences between both models, let’s look at the definitions for the roles of project manager, product owner, and product manager.
Project Manager
A project manager is a professional in the field of project management. Project managers have the responsibility of the planning, procurement, and execution of a project, in any undertaking that has a defined scope, defined start and a defined finish, regardless of industry. Project managers are the first point of contact for any issues or discrepancies raised by various stakeholders an organization before the problem escalates to higher authorities, as project representative. Project management is the responsibility of a project
Product Owner
The product owner is one person, not a committee. A significant relevant business background is required. The product owner is the sole person responsible for managing the product backlog. A product owner is responsible for maximizing the value of the product resulting from the work of the development team.
Product Manager
The product manager is the CEO of the product, as they drive the vision, strategy, (high level) design, and execution of the product. When a product is successful, it is everyone’s success. Unfortunately, when a product fails, it is the product manager’s failure. Let’s look at some good examples of vision, strategy, design, and execution in product building.
-
Vision by Elon Musk: “Humanity needs to become a multiplanetary species to preserve the light of consciousness.”
-
Strategy by Satya Nadella: “Microsoft loves Linux.”
-
Design by Steve Jobs: “You have to work hard to get your thinking clean to make it simple.”
-
Execution by John Doerr: “Ideas are easy, execution is everything.”
Many companies misunderstand and misuse this role, so let’s give a bit more context about what it takes to be a good product manager. Product managers need to have organizational knowledge, product knowledge, and industry knowledge. Given this broad field of required knowledge, finding great product managers in our industry seems to be very hard, there is a serious shortage of great product managers in our industry.
-
Organizational knowledge
This refers to understanding how your company really works. Because, as a product manager you need to get the right people behind every major decision you are pushing, you need to learn who those people are and what their motivations and incentives are. You want to prioritize opportunities that support your company vision, mission and strategic objectives over opportunities that don’t. You also want to consider the company’s political climate. You might need to spend a lot of political capital to gain support for a more controversial opportunity.
-
Product knowledge
Product knowledge means knowing a product’s limitations, its benefits, what users love about it, and what they hate about it. It is important that you know enough to be able to empathize with users to help create solutions to their problems.
-
Industry knowledge
This is arguably the most important of these three areas of knowledge because it represents a deep and thorough understanding of customer problems that remain unsolved or unmet in your market or adjacent/similar markets today. It is through this domain that we recognize the largest market opportunities.
As you can see there are significant differences between project manager, product owner, and product manager. Let’s look at additional roles in product-centric models.
VI: Transition to Product-centric Model
Our participants in Dojo Master Classes now understand the differences between the two models and appreciate the reasons why the industry was moving to a product-centric model. The million-dollar question now is how do we transition from a project-centric model to product-centric model?
We spent a lot of time in classes discussing the challenges. Moving from projects to products requires substantial changes to the enterprise’s core processes, which includes product-centric funding model, business and IT alignment model, team model, skill and talents required, etc. In the end, we all agreed that leadership will play a key role in moving to this new model. We will cover more in Part 3 of this blog to discuss the leadership role in Lean Product.
Despite the challenges, we all agreed that the impact and benefits of a product-centric model could lead companies not only to survive but excel in this constantly changing world.
VII: Product-centric Model at Services
After all those conversations and learning experiences, we had to make it all relevant to our services organization. The question is how will services providers change in this new model? This includes sourcing model, procurement/vendor management, and contract model changes. We have listed only three questions asked in the classes.
Question #1: Companies are moving to the Insourcing model, but with a shortage of required skills in the product-centric model, how can service providers help?
- Many enterprises struggle to adopt agile and also struggle to change their development culture. Thus, moving to a product-centric model added significant challenges into the mix.
- Before the pandemic, CEOs rated skills gaps as a top business challenge. Enterprises couldn’t hire all the talent they needed for digital transformation, which includes agile ways of working, DevOps, and digital product management. COVID-19 crisis won’t change this because few workers with these skills are being laid off.
- To fill these gaps, current employees must acquire new skills. For some industries such as retail, we have seen a significant acceleration of digital transformation. Their challenge is that while the need for DevOps transformation is so pressing due to digital disruption during the COVID-19 pandemic and digital natives eating away market shares, keeping the lights on for outdated IT landscapes supporting their still very profitable “nondigital” business is even more demanding. How on earth would these companies be able to attract new talent that will stay once they notice the actual truth, let alone find time for existing employees to learn these new skills?
In the classes, we agreed that we saw increasing demands on the Dojo type of immersive learning to train entire product teams to upskill for product delivery.
Question #2: Companies have started to hire multi-disciplinary teams from the service providers, so how do those companies source service providers?
According to Gartner, IT Services are changing. Gartner defines continuous product-centric services as an external service provider with a long-term contract to supply a multidisciplinary team that builds, deploys, and supports software using agile and DevOps approaches.
- A “multidisciplinary” team could include business analysts, architects, user experience/customer experience (UX/CX) designers, scrum masters, engineers, security experts, platform engineers, and site reliability engineers.
- A continuous product-centric services team takes requirements from the backlog created by the customer’s product owner. The team then develops software, as well as automating the test suite, deploying to production, and resolving support requests for incident resolution, defect correction, and software enhancement.
- “Long-term contracts” are those that do not end when a project phase is completed, but can continue for multiple years, ending only when the product is retired, or the contract term expires.
- This is a significant shift from functional outsourcing like App Dev, App Ops, or Service Desk services to product-centric services with multidisciplinary, durable, and persistent teams.
One major challenge is that sourcing teams lack experience in evaluating and selecting product-centric vendors. Almost all outsourcing service providers and system integrators offer some level of agile capability, but very few can offer product-centric multidisciplinary teams. The selection process should identify which vendors bring an actual depth of product-centric experience rather than just “lip service” such as through the number of certified Scrum Masters alone. Some companies are more creative, as they may, for example, run hackathons or Dojo as part of the supplier selection process.
Question #3: The contract model changes during this transition. What is the best contract option in this product-centric outsourcing model?
In our classes, we discussed the following six potential options.
Time and materials (T&M)/Managed Capacity
A very commonly used method because it is simple, quick to put in place, and quite flexible. Where the supplier provides an entire team, a fixed monthly “price per team” is sometimes used instead, providing a blend of resources as managed capacity. However, in both T&M and managed capacity, the customer bears the risk of the engagement, while the service provider bears none.
Unit-based
Many sourcing organizations would ideally like to pay per unit of work delivered, but the challenge is to find a unit measure that works. There is no industry standard definition of a story point. Each team, project, and vendor define story points differently. Therefore, it would be impossible to benchmark a price per story point to verify value for money.
Fixed price per sprint
At the start of each sprint, a set of stories or features to be delivered is agreed upon in the normal agile manner. Part of the supplier’s revenue can be held back as a retention against achieving milestones such as the deployment of a minimum viable product.
Business outcome-based pricing
It is difficult to implement this model because defining an outcome is not as easy as it sounds, and a business outcome may be only partly dependent on the service provider. The service providers would probably not like to put a part of its payment at risk based on factors outside its control. Also, business outcomes may not be achieved until many months after the project is completed, thereby creating a delay between the service provider’s costs and its revenue.
Product outcome-based pricing
A business outcome measures how well the business is progressing. A product outcome measures how well the product is moving the business forward. Product team will make progress on a product outcome rather than a business outcome. A product outcome is within the product team’s span of control, but a business outcome often requires coordination across many business functions such as marketing and customer support aside from the product team. Product outcome can be measured by lagging metrics or leading metrics. The lagging metrics measure something after it has happened. The leading metrics predict the direction of the lagging metrics. Defining leading metrics is critical but not easy in any product organizations.
Which contract model to use?
As you can see, T&M is easy, but customers bare all the risk. Other models are more fair but hard to implement. Fundamentally it takes trust between customers and service providers to make other models work, and trust takes time.
VIII: Outcome of Revised White Belt
“An outcome is a change in human behavior that drives business results.”
– Josh Seiden, Outcomes over Output
With a revised curriculum, we tested the White Belt in various cross-functional teams in a wide spectrum from more technical teams to more process-focused teams across all worldwide regions. The feedback we received was positive and encouraging. We received post-survey results, and the overall satisfaction rate at worldwide level was 4.52 out of 5.
In more technical teams, the classes had many questions about how full-stack feature teams would support this model. In more process-focused teams, we had the greatest success in landing the ideas and executing the model. It is also interesting that we had some differences across various regions. The most engaging groups were from Europe, where we had, for example, a one-hour session that was extended to two and half hours on a Friday afternoon.
By using a hypothesis development approach, we validated and invalidated our hypothesis in our new design. Furthermore, we have seen most classes leverage the product-centric concept in their final challenge competition, which shows that the concepts landed well and strong. It is worth mentioning that most people in the classes didn’t understand why we needed to move to a product-centric model three years ago, but now everyone has accepted the concept and actively promotes it to our customers.
With foundational knowledge in the product-centric model, we will dive into the Lean Product-centric model and more importantly cover how we applied the Lean Product model to create our own lean product in Dojo in our next blog, Part 2.
Special Dedication
This blog is written and reviewed by the following authors in Dojo Community.
- April Edwards – April.Edwards@microsoft.com
- Krikor Maroukian – krmaro@microsoft.com
- Paul Fijnvandraat – Paul.Fijnvandraat@microsoft.com
- Kan Tang – kan.tang@microsoft.com
Light
Dark
0 comments