Failing consciously – Product Managers, make failure your ally to be successful

real-estate-failure

Failure. A word that refers to the act of failing or proving unsuccessful.

There have been multiple instances when we decide not to do something because we not sure of being successful. Similarly we sometimes undermined our own efforts to avoid the possibility of a much larger failure.

No one likes to be called a failure, however; what would happen if you knew that you were working to fail or that your work is intended to failing you personally but making someone or something else successful?

Let’s take the example of Toyota Prius. When Toyota decided to work on the concept of a hybrid car, they created 9 teams to work on different engine ideas. So, there were engineers that were trying to create the best hybrid technology possible but they also knew that the probability of creating a successful concept that will potentially revolutionize the automotive industry was very small since there were other 8 teams working on the same idea. ToyotaHybrid2.jpgToyota did not form committees that made decisions on which engine idea to embrace but they tried all ideas in multiple scenarios, kept refining the ideas and finally got to one that proved to be the best. It turns out that in a approach like this, the final design turns out to be a collection of smaller ideas from all teams that come together to create innovative products. For Toyota, Prius became synonymous of hybrid just like Kleenex became synonymous of tissues.

Failures are the biggest allies for Product Managers. The value that Product Managers expect to achieve is based on limited analysis and certainty and huge amount of ideation, adaptation to market and most importantly failing and using the failure to learn and build something better. However; when it comes to failures, what differentiates great Product Managers from the good ones is their mindset of failing consciously and intentionally. Here is why:

Plan for failure – Thought leaders cannot stop emphasizing on the fact that failure is opportunity to learn, improve and be successful. As much as this way of thinking is important to keep the positive energy flowing,  there is a huge difference between failing consciously and failure due to unaccounted or unexpected reasons.

business-plan1-600x353While watching  Olympics a few days ago, I noticed the french sprinter Wilhem Belgian  getting disqualified from the 400 meters race and the Olympics due to a false start. While preparing for an event as big as the olympics, an athlete like Wilhem would have laid down a strategy to get to the finals, he had to end his run at the Olympics for the most unexpected reason possible. He was completely devastated when the failure was caused due to a mistake he never imagined would occur and would have been better of completing the race and loosing to better sprinters.

I am sure Wilhem was not 100% sure of winning a medal but he surely wasn’t expecting to loose the way he did.

Pro tip: If you were conscious of failure, you were sure of success.

Build entrepreneurial character – When talking about entrepreneurial characteristics,  tenacity, perseverance, and resilience are the key attributes to success. However, these attributes are not as common. Elon Musk back in 2013 said that the human brain cannot cope with business failure. But at the same time, a human brain responds differently to failures that were completely unexpected versus failures that were expected and were part of the plan to become successful.

entrepreneurAn entrepreneurial character does not try to conceive a idea that had a 100% chance of being successful. Most successful entrepreneurs started with an idea, knowing what could get in their way in becoming successful but having a strategy to deal with expected failures and leveraging the small wins along the way to make a lasting impact.

Pro tip: Do your best to plan ahead for success but be aware of the failures that may happen along the way to affirm your assessment and awareness of what could fail and what will work.

Encourage creativity and innovation – The reason for success behind most successful products and services companies like the Apple products, Google or Airbnb has been the unique opportunity to ideate, innovate and be creative. Talking about Google, its most successful innovations came by way of the 20% time given to its employees (as much as people question the existence of this policy at Google now) where they could innovate on new ideas and opportunities. What was even more important was how Google employees were measured when it came to tracking success. In this case, the engineers building the product were their own product managers.

The biggest impact of this approach was the freedom to try new ideas, innovate and  feeling safe to fail. This basically meant that they were in total control of the “why”, the “what’ and the “how” of the product. This kind of environment allowed them to keep away from the pressure of making everything successful right from the word go but also consciously make decisions that might prove wrong in working towards the final right outcome.

Pro tip: Many minds can create many ideas and then come together to produce the awesome.

Conclusion: Leveraging failure consciously in making the right decision is a critical mindset shift for product management. An urge to get things right the first time can significantly constraint human behavior in a way that can lead to a negative impact if things were to go wrong. So next time you site down to ideate, be conscious of your failure as much as your success.

 

 

3 Pillars of Scrum – Core but easily forgotten

Screen Shot 2016-07-17 at 8.03.49 AM

What are the 3 pillars of Scrum? This is a one question I love to ask leaders, Scrum Masters, Product Owners and members of development teams as I engage with them, trying to help with their agile adoption. The statement “our team is already agile” is commonly heard but what is being referred to is the fact that the teams are conducting Scrum events (sprint, sprint planning, daily scrum, sprint review and sprint retrospective), connecting these events to agility and keeping the ideas of transparency, inspection and adaptation on the side.

Limiting the idea of agile adoption to just events and practices is a clear indication of the missing understanding of the core mindset of agile and Scrum and instead, the use of Scrum as a process control method.

The simplistic design of Scrum framework and the embedded practices are the heart of creating a agile culture for software development. Every event in Scrum is conducted to constantly put the 3 pillars of Scrum in practice to not only ensure adherence to the framework and its practices but also to have agility embedded to the people and process aspects of product development.

Most common examples of situations when transparency, inspection and adaptation are overshadowed by other “not” important decisions are:

– What is the buffer we should account for during the sprint to account for unplanned work? This is a step in the wrong direction from a transparency perspective. Team should rather allow for unplanned work to impact work so that delays become visible and the team can assess the reason behind unplanned work and adapt by working with the Product Owner to make the right decision.

–  Our/Your burn down does not look good. This is commonly bought up as an issue by the Scrum Master or the management and can take the focus of the team from getting the sprint forecast accomplished to making the burn down look good. It is important to understand that the burn down was not created to paint a good picture of the team but to transparently surface delays so that the team can collaborate and plan for the work to be done to possibly meet the forecast.

– Get the stories to “done” by moving the undone tasks to a new story. The “Definition of Done” is sacred to the team and is created with an intent of ensuring that the story accomplished is in a state to be released into production. However; creation of new stories with an intention of claiming browny points for work done or delaying defects for later is a common cause of delays and reduced quality.

There are many such behaviors and conversations that you will observe in your teams and the easiest way to make the right decision is to go back to the 3 pillars and make a decision keeping them in perspective. This is what I do while coaching team and it is what teams should do to create a culture of agility.

Remember, Scrum does not solve problems, it exposes them

Agile transformation – Working with shared services along the way

Screen Shot 2016-07-05 at 1.27.38 PM

The concept of shared services is prevalent in most large organizations. A centralized user experience or architecture group or services group can be commonly spotted. A lot of times, component team setups are given a flavor of shared services.

No matter how much dysfunction it causes, shared services continue to live for many reasons including:

  • Organization’s inability or hesitation to make structural changes
  • Fear of being exposed in getting outside of their comfort zone
  • Fear of change in general
  • Focus on local optimization
  • Others…

The fact remains that shared services are generally not economically viable due to associated communication overheads and increased cycle time to get work done, however; the idea of shared services will not go away anytime soon. So what are some of the ways to work with shared services setup in an agile organization? Saying that organizations need to completely change from a shared services structure to feature teams capable of delivering end to end functionality will sound lame and unrealistic. Below are some techniques that can help organizations work with shared services, trying to transform to the agile way of working:

  • Vision – The environment in a shared services setup is generally chaotic as consumers always have a high priority need. At this time, it pretty much becomes a bidding game. The person or team that shouts the loudest or the person with the highest level of influence is able to get their work prioritized to the top. This is followed by the lengthy process of knowledge sharing where the member of the shared services team spends time in understanding what to build and why. This causes the shared services team member to take a very narrow approach to quickly build what is being asked without understanding the vision and move out to the next ask. This sounds pretty much like a robot in a manufacturing environment that just gets its work done without caring about the end result.

vision

For agile teams, having a common understanding of the vision of the overall product or just a single release is of paramount importance to ensure that every single activity is focussed on achieving the vision. When working on large product backlogs, it is recommended that teams (I mean the whole team and all the teams) get together to create a common understanding of the functionality targeted in the next release. All teams involved should participate and help in sequencing the work to be done to be able to assess when the consumer will need something. This generally calls for investment of time from all teams but the outcome overshadow the cost.

Where there exists a clear vision and a clear understanding of what is needed from the teams, team members remain excited about what is being developed and look forward to their contribution and stay engaged

  • Alignment“Change is the only constant”. A sequenced backlog should not be treated as a project plan. Once a vision has been established and the backlog has been sequenced, all involved teams should come together on a regular basis to inspect the progress and resequenced their backlog as needed. Four-Dimensional-Goal-Alignment

This will specially help the shared services    teams to reprioritize their work to make sure that the next highest priority deliverable goes out quickly.

  • Collaborate – Coming together frequently to align is part of collaboration. Additionally, having someone from the shared services team attend the consumer team’s daily Scrum and other Scrum events and vice versa will help both the shared services team and the consumer team to stay informed about the progress being made and plan their work appropriately.
  • Service Level Agreements (SLAs) – Achieving discipline through working agreements is important when it comes to collaboration between teams. To use a metaphor, car manufacturers rely on multiple suppliers to provide various parts of the car to be able to assemble the end product. Each of the suppliers have to agree to certain processes and protocols to make sure that the assembly line does not come to a halt due to shortage of parts. Each part has a assigned reorder inventory level at which point the order system automatically places order for the next shipment. 3771.PPP_PRD_165_3D_people-Binding_Agreement_1FA08461Not only is the vision of the system clear to each supplier, the suppliers ensure delivery of products on time and are also liable to penalty if the agreements are not adhered to.

The key focus agreements is to build the environment of collective ownership, collaboration and focus to ensure quality and timely deliverable while maintaining a flow.

  • Use a tool – Tools can come in handy when it comes to collaboration and keeping shared services teams informed about their commitments. While I am a huge proponent of physical boards for Scrum teams, I do have to acknowledge that physical boards become a limitation when trying to keep shared services teams informed about the needs or the change in needs of the consumer.

tool-icon

Additionally, tools can be used by teams to generate metrics to assess their performance in being able to meet their SLAs, get notified about key milestones and provide data specifically targeted towards continuous improvement.

 

————————————–

While I truly believe that structural changes are a critical part of a successful agile transformation, it is not always possible  right from the word go. Organizations are generally resistant to radical changes fearing impact on running the business. While baby steps are taken to impact structural transformation, the above mentioned steps will help in the interim to help the organization get started on the journey of agile transformation.

If you have other ideas/techniques that you have used in your engagements, I would love to hear from you.

 

 

 

 

%d bloggers like this: