Posts Tagged ‘Learning’

This is the best book I’ve read on DevOps and it follows on nicely from Gene Kim’s other book The Phoenix Project.

It’s quite easy to think that DevOps practices are just something that dev teams deal with and the value is simply just an increase in throughput, but the book provides clarity on the colossal value that adopting a DevOps culture and the principles can have on teams, the business, and customers.

Throughout the book, Gene echoes the importance of having the whole product team (product manager, designer and several engineers)) involved in the transformation, as well as focusing on outcomes, and to achieve outcomes you need to collect data and learn through experimentation which is covered in the book too.

Gene gives good advice that it’s important to avoid funding projects and instead you should fund services and products: “A way to enable high-performing outcomes is to create stable service teams with ongoing funding to execute their own strategy and road map of initiatives”.

This is the most comprehensive and practical DevOps guide out there and the layout makes the content easy to digest. The book covers:

– History leading up to DevOps, and Lean thinking
– Agile, and continuous delivery
– Value streams
– How to design your organisation and architecture
– Integrating security, change management, and compliance

The principles and tech practices of:
1. Flow
2. Feedback
3. Continual Learning and Experimentation

“Our goal is to enable market-oriented outcomes where many small teams can quickly and independently deliver value to the customer”

In this book, Frank Barrett writes remarkable stories on leadership, learning, and innovation from a range of industry settings-from Jazz performance to automotive manufacturing.

Saying ‘Yes to the Mess’ ultimately means accepting as a management team that you don’t have control over how the teams on the front line get to the end goal or get a detailed plan on how they’re going to get there, and Instead, you can see how the team navigate through the uncertainty by learning along the way, being curious, creative, innovative, driven to succeed no matter how many experiments fail, and having fun along the way…aka improvisation.

Whilst there is no mention of product management in the book, there are clear lessons that can be learnt from jazz, which are also covered in other Lean product development books on how to handle uncertainty – by providing a vision and empowering the team to decide how they are going to get there, which as a result yields creativity, ownership, autonomy, learning, loyalty, speed, and value.

Jazz is a ‘risky business’ and the mindset of jazz would work in a multitude of environments with high uncertainty such as a product innovation hub, a new product that hasn’t been validated in the market, or a brand new feature for an existing product. Everything is an experiment to a jazz player, which reminds me of the hypothesis-driven product development approach.

After reading this book I definitely have a greater appreciation of jazz because of the level of risk and improvisation that takes place.

This wasn’t an easy read, but I enjoyed it, as it provided a unique angle on leadership from different perspectives.

After 17 years of researching leaders around the world, Jo Owen shares the secret sauce to what a successful mindset looks like at different leadership levels and how you can unleash it.

Seven mindsets that consistently came out of the research which the book focuses on:

1. High aspirations
2. Courage
3. Resilience
4. Positive
5. Accountable
6. Collaborative
7. Growth

This is the best book I’ve read on management and leadership as it compares the different mindsets you need across each leadership level, allowing you to build a crystal clear picture of what mindset you need to focus on to get to the next level of your leadership journey.

Owen includes a multitude of tables, with the most impactful showing how the nature of leadership and management changes at each stage of a career, along with what mindset you need at each stage and details of behaviours/expectations. This makes it easy to find the gaps allowing you to make an immediate impact on your mindset.

The book is packed with advice on how to get the most out of yourself and your team along with some common pitfalls for example:

• High aspirations: should not be about self – focus on the mission and gain buy-in from the team.
• The prison of performance: focus on learning, not just achievements.
• Positive thinking: ensure it doesn’t crowd out reality.
• Leadership: it’s not about authority, power or position, but taking people where they wouldn’t have got by themselves.

“High aspirations will accelerate your career: you will succeed fast or fail fast. More likely, you will fail several times, learn from your setbacks and then succeed to a greater extent than anyone thought possible.”

To paraphrase Charles Darwin: “It is not the strongest of the species that survives, nor the most intelligent, but rather the one most adaptable to change.”

This book will help you make sense out of the nonsense you might experience, and give you insight that will help you to accelerate your learning and career.

“The most important mindset for a successful career is learning and growth. If you stay still, you will fail.”

Before reading this book I’d read a few snippets in other books around Toyota’s Lean way of working, but this book tells a comprehensive story not only about the success behind Toyota’s legendary customer-centric product development techniques along with market performance data to back it up, but it was also fascinating to get insight into how the business got out of its comfort zone to innovate effectively with the Lexus and Prius.

If you’re an advocate for an empowered and learning culture, you’ll love this book as it’s packed with inspiring examples of how their success started with a healthy culture and a long-term philosophy.

This book gives insight into how Toyota creates an ideal environment for implementing Lean techniques and tools by:

  • Fostering an atmosphere of continuous improvement and learning
  • Satisfying customers (and eliminating waste at the same time)
  • Getting quality right the first time
  • Coaching leaders from within rather than recruiting them from the outside
  • Teaching all employees to become problem solvers
  • Growing together with suppliers and partners for mutual benefit

The most common Agile framework is Scrum, which typically involves a product manager managing a backlog of user stories (outputs) using the user story framework:

Template

As a… <persona>

I want… <intent>

So that… <benefit>

Example

As a player

I want to be able to easily access new games

So that I can have fun playing the latest games that I haven’t played before


Since user stories are output-focused rather than outcome-focused, it becomes easy to fall into the build trap of delivering output after output with no understanding of whether it delivered any value to the customer or business. One of the reasons is that unless tracking is part of the DoD, to track the value would often require additional tracking user stories in the product backlog which are easily ignored when in a project led environment or when there is pressure to get after delivering a new unrelated user story (output).

Now, In the 1920s, Ronald Fisher developed the theory behind the p value and Jerzy Neyman and Egon Pearson developed the theory of hypothesis testing, which as a result formed an Agile/Lean technique called Hypothesis-Driven Product Development which is outcome-focused, delivers a measurable conclusion and enables continued learning. A hypothesis framework consists of:

Template

We believe… <capability>

Will result in… <outcome>

As measured by… <KPI>

Example 1

We believe that by providing players with an easy way to access new games

Will result in an increase in game plays

As measured by a higher number of game plays per player and new game engagement

Example 2

We believe that by offering new players a 5 day achievement-based promotion

Will result in new players retaining longer

As measured by a decrease in churn rate by 5%


The immediate benefit of using a hypothesis-driven framework especially for uncertain product iterations is that the product team are forced to ensure that the outcome is measurable before delivering the output/feature. Since it will be measurable, it will be possible to learn and validate the hypothesis aka validated learning.

The ideal scenario would be to run multiple experiments concurrently to reach the same outcome so that you can learn quicker (rapid experimentation). A test failing means progress, that you’ve learned what doesn’t work, so you can progress in a positive way to experiment on a different idea to solve the problem.

It’s easy to migrate from the Scrum to Kanban framework or vice versa, but migrating to the hypothesis-driven framework is significantly more challenging as it involves a culture of empowerment and learning, with trust and patience being critical elements to start with whilst the team gets used to the new framework, data structure and the validation capabilities, which is needed before the product team can conduct rapid experiments effectively.

If you are entering a mature market and you are more certain that the solutions will solve the problem, a standard user story is more appropriate, but the most efficient way of delivering outcomes where you are uncertain that the solution will solve the problem is hypothesis-driven product development, rather than spending months guessing with user stories without any learning.

With tools available to easily conduct remote customer interviews (UserZoom, Lookback.io), A/B testing (Firebase, Maxymiser) and prototyping (Sketch, Figma), it makes it easier more than ever for empowered product teams to efficiently conduct experiments to validate that the solution will solve the problem.

Good luck in your experimentation journey!

Basics

As a product scales there would often be an increase in capacity / scrum teams working on that product, enabling multiple features to be worked on concurrently, which would be a sensible time to review whether it’s time to adopt the LeSS (Large Scaled Scrum) framework.

As there are some additional elements involved in LeSS vs. Scrum including:

  • All of the Scrum teams work as one team, from one product backlog and with one Product Manager to deliver common goals
  • Having a joint sprint planning with members of each scrum team to decide on what product backlog items (PBIs) to commit to delivering in the next sprint
  • Overall Backlog Grooming (OBG) where members of each scrum team decide on what PBIs to assign to what teams, so they know what features to groom and get in a ready state for an upcoming sprint
  • Overall Retrospective where members of each team discuss highlights from their individual team retrospectives with the aim to learn and improve on how the whole team operates

It’s important to ensure that the Scrum teams have mastered the key elements of Scrum before considering using the LeSS framework, so before moving over to LeSS, see how you’re doing against the below questions:

  1. Are the teams using velocity to measure whether process changes they make are improving their productivity or hurting it?
  2. Are fast estimation sessions happening frequently so that the product backlog has rough estimates?
  3. Is it easy to predict when software will be delivered for the current and future projects based on the backlog being sized?
  4. Are sprint burndown charts monitored every day?
  5. Is analytics part of the definition of done?
  6. Is there a strong DevOps culture in all of the teams?

If the answer is ‘no’ to any of these then perhaps it’s a bit too early to adopt LeSS.

Learning

There are three major types of learning:

  1. Learning through association – Classical Conditioning
  2. Learning through consequences – Operant Conditioning
  3. Learning through observation – Modeling/Observational Learning

This article is focusing around No2 (learning through consequences) and the reason for focusing on this is because it’s common for fellow work colleagues across any business to recognise a problem/something not getting done and the consequences of not solving/doing it, that they just get stuck in and solve it themselves because they’re passionate about the business they work for instead of leaving it for the person whose responsibility it is to solve the problem/complete the task with the risk that it’ll likely not get done.

Now, many people would say that’s brilliant teamwork and a fantastic ‘One Team’ attitude, but the action of solving someone else’s problem/completing a task for them is stopping the actual person whose responsibility it is to do it from learning. Also, there’s the point about the person should be doing what they’re paid to do, but most importantly unless people experience the consequences of not doing critical elements of their job, then they’re not going to learn the importance of doing that element of the job and that they need to perhaps adjust their processes or admin to ensure they take control of their responsibilities in future.

Like I said at the start, if you’re passionate about delivering value for the business then it’s certainly not easy to avoid getting stuck in and it’s hard to avoid reminding people to do their job, but if you want to achieve the goal of the person who should be solving the problem or doing the task actually does it as expected in future, then the only way this will happen in the long run is by that person recognising the consequences of it not being done, so then they can avoid leaving it in future.

There will naturally be times when someone is overworked and can do with a hand and that’s where you could come in to help, but if it’s someone close by spending most of their time surfing the net or playing ping pong in the games room, then you need to take a step back, try and ignore the problem not getting solved allowing them to deal with it however they feel is effective, but what is for certain is that problems don’t normally get solved on their own.