In the past few years a few new trends have emerged in the Agile community that have challenged some of the basic assumptions of how software should be delivered. The first one, #NoProjects is challenging the idea that software work is best managed as a project. As Allan puts it in this episode: “Successful software does not end. It continues. And projects are for temporary endeavours, that have a known start and fixed end. That’s now how software is developed today.”
With that start to the episode you can expect that many unconventional (and inconvenient?) ideas will be shared in this podcast focused on the latest trends in how to manage software development.
Distributed teams are a fact of the multinational organizations we work with. Hiding from it is not going to remove that. And crying “distributed agile = bad agile” is only going to alienate people who genuinely need to learn to cope with the fact that distributed teams are the new normal.
There are good and bad ways to adapt to the reality of distributed software, and copying the methods and practices from co-located teams into the digital world is not enough. Molood shares some of the common anti-patterns that arise when we plainly try to copy the co-located team methods into the new distributed reality.
One such example is the communication channels: trying to copy daily meetings from the co-located team into a digital world will eventually bump against the frustratingly low quality sound of some conference room setups. Molood suggests a different route and shows how a team she helped took full advantage of Slack (or any other asynchronous communication channel) to make their daily meetings for effective, and efficient for everyone involved.
Marcus is the author of Salvation: The Bungsu Story, a book we here at the Scrum Master Toolbox Podcast are helping to publish. This book is inspiring, and will definitely move you to action.
In this episode, we discuss some of the many techniques Marcus used in Indonesia while he was helping the team at The Bungsu Hospital literally save the hospital from bankruptcy. And that’s not an over-statement!
Click to liste to the interview and read more about the topics of this episode.
Karin has a long experience helping teams and businesses to use self-organization as a way to drive business success. She’s worked as an interim-CEO in several companies where she helped drive major changes and positive business results using the principles and ideas behind self-organization.
Self-organization is not only for small teams. Karin shares with us the stories of the businesses where she worked, and how some fundamental changes enabled not only self-organization but also major business changes.
Read on for the detailed insights from this episode.
Psychological safety has been claimed to impact greatly the productivity and well being of teams. Building trust is how we reach psychological safety, but trust is a touchy topic for teams. Scrum Masters try to build trust between team members, with stakeholders, with other teams, with the Product Owner. Trust maybe one of the critical ingredients that allows collaboration to emerge. But how do we build trust? How do we learn what works, and what doesn’t when building trust?
Tim Ottinger shares his learning in this BONUS episode on trust, with a very practical approach, just like we like it here on the podcast.
Does your company need estimation? Listen to Erwin’s take. He’s a CEO. He should know.
Erwin has his own company and invests his own money in that company. For him, #NoEstimates solves a clear problem: too much time wasted estimating, instead of producing.
He challenges us to investigate how much money and time we already invest in that process, and then to measure the benefits. Are we getting enough return on the time and money we invest on estimation?
We learn about Erwin’s story of adoption. How he started with gradually larger projects, even at larger clients, and what he learned about the dynamics that push companies to make larger and larger decisions. Those larger decisions look like they require estimates, but why aren’t we questioning the need to make large decisions (large batch)?
Can we apply Agile ideas to the definition and execution of Strategy for our businesses? Trent Hone, award winning Naval historian, Karl Scotland, Agile Strategy pioneer, and Henri Mårtensson, long time author on the topic of business strategy got together to discuss just that.
Al Shalloway is a veteran of the software industry, and one of the early adopters of Agile. His company NetObjectives has even been podcasting on the Agile space way before Agile was popular. NetObjectives started their Lean And Agile Straight Talk Podcast way back in 2006, and you can still find many of their episodes on iTunes.
Business Value, the forgotten goal
In this episode we start by talking about the concept of “Business Value”, which is often forgotten in favor of some process goal like “adopt agile”. One can ask: what is the value of adopting Agile if we end up going bust?
But it is not so easy to define business value. In this episode we explore what might be the meaning or definition of business value in our organizations. We also discuss how we can help our teams focus on impact, not just more features delivered. And we end up talking about the need to have a process that adapts to many different organizations. Al talks about FLEX, a model NetObjectives developed after working with many organizations and understanding what is not working today when we try to scale Agile.
Developing an Agile model for organizations of many sizes
Al and his team have been around for a while. They have used XP, Scrum, Kanban, SAFe, Lean and more recently FLEX. From that varied experience, Al has learned a lot that he applies today in his company. From the insight that Scrum can only succeed if we take care of the people, to how SAFe is more appropriate to certain organizations, to the idea that management has to be an integral part of any transformation or Agile adoption. We talk about the Art of Action by Bungay, the orientation of management (hint: not top-down or bottom-up!), and double-loop learning. Double-loop learning is an essential part of transformation and actionable learning. We also refer to the New New Product Development Game, and other work by Nonaka, which informed the creation of Scrum.
EXTRA BONUS: to get 30% off Barry’s Hypothesis-Driven Development course you can go to www.leanagile.study and use discount code THIRTYCPOFF before the end of December 2017.
Far too many companies act as if Product Development was a shopping trip: they get a list of things to “buy”, typically Features. Then they create documents explaining that shopping list: Roadmaps, Backlogs, PowerPoint presentations, Post-its on walls, you name it. And then they execute. Here’s the thing: if you act as if Product Development is a shopping trip all you will do is spend a lot of money and get lots of Features you don’t really need.
Barry suggests we treat Product Development differently. He calls it Hypothesis-Driven Development (HDD for short) and includes:
Leadership set an outcome (not a task!) Example: how to increase conversion by 10%
Look for observations: where you try to understand what is happening in the product and to the product you develop.
Set a hypothesis to validate ideas: where you make assumptions and write those down as assumptions. Assumptions should be about how to reach the goal set in step 1.
Create simple experiments: actions that drive results, which you will compare with the hypothesis you created in 3.
Gather the data, learn and repeat: the core process is LEARNING. Therefore, spend enough time on this step so that you generate new observations, insights. Then repeat the cycle.
A fundamental shift in product development
Barry claims that HDD is a fundamental shift in product development. The shift is from doing many things, many small changes, and switches to focusing on outcomes, on results to the business. This means that leadership is no longer accountable for the work, but for the outcomes. And this frees the teams to focus on self-organizing to reach those outcomes, instead of following a list of things that others have dictated.
As a result of the shift towards HDD, we stop focusing on big-bang, all-in projects and focus on running smaller experiments that drive the learning that will eventually generate the outcomes we defined. As Barry says in this episode: we go from 1 to 2 experiments per year (projects) to testing many more ideas every month.
But you can’t run that many experiments with the same approach to funding, and management that you used when you ran projects. So we focus on a different management paradigm that Barry explains further. The goal: learn and adapt faster, not produce more features.
As part of that, we need to get familiar with the concept of safe-to-fail experiments that can reliably generate knowledge without causing chaos or confusion in our product development process.
And it all starts with a simple change in product development: define the problem you are trying to fix, not the solution you are trying to create.
If I want to know more about the Hypothesis-Driven Development approach, where should I start?
Barry O’Reilly is a business advisor, entrepreneur, and author who has pioneered the intersection of business model innovation, product development, organizational design, and culture transformation.
Barry works with business leaders and teams from global organizations that seek to invent the future, not fear it. Every day, Barry works with many of the world’s leading companies to break the vicious cycles that spiral businesses toward death by enabling experimentation and learning to unlock the insights required for better decision making and higher performance and results.