BONUS: Lean and Agile Financial planning with Maarit Laanti and Rami Sirkiä

The financial processes of companies can defeat their own efforts to become more agile. It’s simply impossible for an organization to be adaptable if their project processes require all projects to be specified up-front and funded months ahead of their starting date.

Tackling the financial process changes in our organizations is one of the make-or-break aspects of helping organizations become Agile and adaptable.

In this episode, we talk about Lean and Agile Financial Planning (PDF article download), an approach that tries to adopt Agile and Lean thinking in the funding and financial processes of an organization.

The reason why Lean and Agile Financial planning is a core aspect of Agile transformation in enterprises

Continue reading BONUS: Lean and Agile Financial planning with Maarit Laanti and Rami Sirkiä

Why Agile frameworks fail and what to do about it: #ToolsOverFrameworks, the context-aware solution

4 minutes read

I have worked at many organizations that were trying to adopt Agile using a framework as the starting point. SAFe, LeSS, or even Scrum were the frameworks of choice.
Scrum, for example, is a very simple framework. It stands to reason that it would be easy to adopt and therefore benefit from the value that Agile brings. Or is it?
If we look deeper, Scrum is a collection of patterns or thinking tools. The daily meeting pattern, the time box pattern, the single owner of the requirements pattern, etc. There are many patterns that were considered when creating Scrum, and together they form what we know as the Scrum framework.
As the Agile community, the problem we face is that Scrum (and other frameworks) did not make Agile adoption easy. The Scrum Theatre many teams play attests to that fact. Using a framework is a problematic approach for Agile adoption because it assumes a prescriptive solution would help us tackle agile adoption. However, Agile adoption is a problem that requires constant evolution and changes.
As the Agile community, the problem we face is that Scrum (and other frameworks) did not make Agile adoption easy.
We need a different approach. One that builds on what we’ve learned from others (books, podcasts, conferences), but also that adapts to our context and the specific reality we live in.

The patterns we’ve seen working before, fail later on

When we work with different teams, we start to get a “feel” for what works, and what doesn’t. We try to apply the same ideas to another team, and then start to understand what consultants mean when they say “it depends…”

When we work with different teams, we start to get a “feel” for what works, and what doesn’t.

For example, the star-fish retrospective may work great for one team, but it just bombs when we use it with another team. That’s ok. Nothing works all of the time. The good thing though, is that there’s always something that works, we just need to know what it is.

The solution is not a process or a framework, it’s a toolbox!

Having worked with many teams, I’ve come to value a few tools that I try to use often. Some retrospective formats are one example of that. But not every retrospective format will work, so I’ve collected over time a large set of “thinking tools” or retrospective formats that I use depending on the context.
As a Product Owner, I’ve successfully used Backlogs. But in some teams Backlogs get abused and create the “slave to the backlog” anti-pattern. With those teams, I’ve been using Impact Mapping and Story Mapping instead. Different situations require different tools. The challenge is collecting a good and large enough toolbox, and the stories to go with it.
Stories, when attached to a tool, help us define where the tool will work, and when it might not. Stories are our “labels” for tools.

Collect tools, not frameworks

No doubt you will be part of teams using different frameworks: Kanban, Scrum, Extreme Programming or Scaled Agile (SAFe), Large Scale Scrum (LeSS), etc.
Don’t fight the framework! Instead, use concrete tools that help you progress and achieve your goals.
As Agile Coaches, Scrum Masters, Product Owners and Team Members, we should be collecting tools, not frameworks. Our goal is to deliver something valuable to our customers/users, not be good at SAFe, Scrum or some other framework.

How we collect tools

We collect tools and stories by sharing our experiences, and listening to those that have solved the problems we are facing now.
For a while I’ve been collecting challenges and tools that product developers use to solve their most important challenges. I’ve collected those in the form of workshops that tackle specific types of problems.
In the #NoEstimates workshops, I share tools and techniques that have helped me and many others deliver on time. Sometimes you can’t fight the deadline. If the product must be out for Christmas, you just deliver. Period. How? That’s what we tackle in the NoEstimates workshop: tools, techniques and thinking models that help deliver on time. These tools are context specific, they come with stories and we practice those in the workshop. Click here to find out more and join the next #NoEstimates workshop.
In the Product Owner Success Toolbox workshop, we review, and practice tools that have helped teams deliver products and services that have a market impact. Impact for the users, customers and also the companies we work with. The biggest waste is that of human potential, with these tools we build our Product Ownership toolbox, and tackle the biggest challenges people have faced when trying to define and deliver products with market impact. Click here to find out more and join the next Product Owner Success Toolbox workshop.
In the Agile Strategy workshop (still in alpha, contact me to know more), we tackle the biggest challenges that companies have faced aligning the teams, and focusing larger number of teams on concrete value for the customers and the organisation. The Agile Strategy workshop collects tools related to funding of work, strategy definition, product strategy, strategy deployment, and progress follow-up at the organizational level. Email me to know more about the Agile Strategy Workshop.

Join the conversation

Have an opinion on the use of Tools vs. Frameworks? Join the conversation on Twitter/LinkedIn with the hashtag #ToolsOverFrameworks

2 major challenges I faced as a product developer

When I started developing software as a team member, and later as a project manager, I started to face some of the challenges that you are probably familiar with.

With the little experience I had, these challenges proved to be difficult to solve. During part of my journey, they even felt impossible to solve. I know better now…

The first and most important challenge for me was the need to meet a strict deadline.

We ended up calling it the Christmas problem.
Continue reading 2 major challenges I faced as a product developer

BONUS: Dean Leffingwell on scaling Agile and the Scaled Agile Framework, SAFe

scaled agile overviewFor this first Christmas 2018 special we focus on scaling Agile, and specifically how the Scaled Agile Framework (SAFe) can help organizations take Agile and apply it in the large.

There are many systems that require multiple teams to work together. As more and more industries adopt software as a core part of their services and products, we also see many organizations developing many products concurrently, and large engineering organizations that require coordination across tens or hundreds of teams, including non-software teams.

In this episode, we discuss how SAFe can help you take Agile to that type of environments and organizations.

Read on for the detailed show notes, as well as all of the links.

Continue reading BONUS: Dean Leffingwell on scaling Agile and the Scaled Agile Framework, SAFe

How Agile and Lean saved a hospital from bankruptcy! Twice!

All of us working with Agile and Scrum are used to the (sometimes) large transformations that these approaches can have at work. But it is not everyday we see the impact, the amazing impact, it can have on other types of work. How about this: Marcus Hammarberg, walks into a hospital and the hospital is about the crumble. Literally! The roof has collapsed, there’s dripping water and buckets everywhere and the second floor is overrun with debris. But that is not where the problems end…

A few months later, and using Kanban, Agile and Lean ideas the hospital is saved. But how did that happen?

Marcus explains his story, and the amazing transformation in his latest book: The Bungsu (now available for pre-order at Amazon), and we have a short video to explain the main points of the story right here.

Click on to see the video, and sign-up to get the first chapter of the book.

Continue reading How Agile and Lean saved a hospital from bankruptcy! Twice!

How trust, kanban and a little structure changed a life

Work life is a serious thing. We spend (at least) one-third of our time awake at work, and in some cases much more time than what we spend with our families most days of the year.

Now imagine what would happen if your work would be falling apart. You have too much work, and are being constanly interrupted. Your authority and ability to contribute is undermined. And on top of it your place of work is literally crumbling: the roof collapsed and what is left is being innudated by dirty water that runs off from the roof’s debri.

Meet Ibu Elsye!  Ibu Elsye is the lady dressed in black in the picture or “Mrs.” Elsye if you don’t speak Indonesian ;).

She’s General Manager of a hospital, Rumah Sakit Bungsu (aka The Bungsu), that Marcus Hammarberg helped, in Indonesia. General Manager; what is that, in a hospital? I’m happy you asked: basically she’s in charge of everything that is not health care. Food, laundry, maintenance, security staff, drivers … you name it.

In The Bungsu, if you need something fixed – go to Ibu Elsye.

But Ibu Elsye’s work life was not going very well…

Continue reading How trust, kanban and a little structure changed a life

Using Lean and Agile to save a hospital from bankruptcy: twice! The Bungsu Hospital Story

When Marcus Hammaberg first started to work with the Bungsu hospital they were in a devastating situation. Their finances were on a bottom low after years of decline of patients visiting, their operational permit had not been renewed and they were operating on a probation, the staff was disengaged and blasé … oh, that’s right – the roof of the entire second floor had collapsed.

Read on for more…

Continue reading Using Lean and Agile to save a hospital from bankruptcy: twice! The Bungsu Hospital Story

BONUS: Mary and Tom Poppendieck on Lean Software Development, Business Agility and how autonomous teams enable adaptability

Tom and Mary Poppendieck have authored several books over the years about what needs to change in how we develop software to be able to meet the demands of the market, competition, and the growth in complexity of technology businesses. A recurring pattern they have witnessed is that people keep trying to discover a “silver bullet”. We explore why that is a bad idea and some of the changes in product development that make it an impossible quest.

Read on for the details, and all the links shared during the show.

Continue reading BONUS: Mary and Tom Poppendieck on Lean Software Development, Business Agility and how autonomous teams enable adaptability

BONUS: Barry O’Reilly on What is Hypothesis-driven Development, and why that matters for Agilists

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:

  1. Leadership set an outcome (not a task!) Example: how to increase conversion by 10%
  2. Look for observations: where you try to understand what is happening in the product and to the product you develop.
  3. 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.
  4. Create simple experiments: actions that drive results, which you will compare with the hypothesis you created in 3.
  5. 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.

We go from investing in work to investing in learning. We might use Innovation Accounting, à lá #LeanStartup, or focus on creating Options and benefit from the concept of Optionality popularized by Nassim Taleb in his famous Black Swan book, but also referred to in Commitment, the book by Agile Coaches Chris Matts and Olav Maassen. This different focus will completely change your product development process to maximize the information generated and help you find new avenues for growth in your product.

We don’t do Projects anymore, we run Experiments!

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?

 

If you want to generate options you may try Teresa Torres ‘Opportunity Tree’ which is a great tool for generating experiment options to test hypotheses https://www.producttalk.org/2016/08/opportunity-solution-tree/

 

About Barry O’Reilly

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.

Barry is the co-author of the international bestseller Lean Enterprise: How High-Performance Organizations Innovate at Scale—included in the Eric Ries Lean series, and a Harvard Business Review must-read for CEOs and business leaders.

You can link with Barry O’Reilly on LinkedIn and connect with Barry O’Reilly on Twitter.

You can also contact Barry O’Reilly through his site, and sign up for his newsletter to get the latest news about Hypothesis-Driven Development.

EXTRA BONUS: to get 30% off Barry’s course you can go to www.leanagile.study  and use discount code THIRTYCPOFF before the end of December.

BONUS: What is TameFlow? Steven Tendon explains TameFlow, an hyper performance approach for software development organizations

Steve has been interested in the performance of IT teams and organizations for many years. His work goes back to the 90’s when he experienced, first-hand, what a hyper performing team feels like during his stint at Borland International.

Borland famously fought off Microsoft in one of the most competitive markets in the 90’s: the code editor and compiler market.

During his experience at Borland, Steve got inspired to go beyond the basics of the definiton of performance and started to look for references and inspiration which later led to the definition of his TameFlow system which he describes in this TameFlow introductory book: The Essence of TameFlow.

Among some of the original sources of inspiration for his work, Steve mentions The New New Product Development Game by Takeuchi and Nonaka; David Anderson’s Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results; Flow: The Psychology of Optimal Experience; and many others.

Why do we talk about Hyperperformance and not Hyperproductivity?

Steve explains why he struggled with the use of the word “productivity” and ultimately decided against it. The use of the productivity word develops a focus on the wrong kind of metrics, as well as the fact that it drives a single-dimension focus. In contrast, with the word performance, Steve tries to elicit the different aspects that we need to take into account if we want to improve our teams and organizations. Among the different focus aspects Steve mentions what he calls the 4 flows in the TameFlow system:

  • Operational Flow: How well are you delivering? The operational flow is the conventional “work flow” that determines how work moves through an organization.
  • Financial Flow: How much wealth are you creating? Financial flow is measured in financial throughput. It represents the rate at which an organization turns its products or services into profit or to other units of value.
  • Informational Flow: How well are you communicating? Informa- tion is the lifeblood of an organization; even more so in modern knowledge-based organizations.
  • Psychological Flow: How happy are your people? The highest levels of individual or group performance are achieved when people reach mental states of flow, which is generally associated with a state of happiness.

The take-aways for Scrum Masters

Finally, we review the concrete take-aways Scrum Masters can apply based on the work that Steve has published under the TameFlow banner.

If you want to know more about TameFlow you can visit Steve’s site on the topic: https://community.tameflow.com. In this community you will find others that are applying these insights to their work.

If you are looking for a book where the TameFlow system is described you can check the TameFlow book or the set of shorter books that recently published.

 

 

About Steve Tendon

Steve Tendon popularised the Theory of constraints in some of the agile community and he is also the Creator of the TameFlow systems thinking approach which nurtures breakthrough performance innovation.

This system is described in the book with the same name: Tame the Flow.

You can link with Steve Tendon on LinkedIn and connect with Steve Tendon on Twitter.