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: 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.

 

 

Henri Karhatsu on moving towards a Vision

Success for a Scrum Master is defined in many ways. For Henri this means focusing on constant evolution and change. He refers to the Toyota Kata by Rother as a model to follow when working with teams and defining success for you, and the team. He emphasizes how important it is to focus on one improvement goal at a time.

About Henri Karhatsu

Henri is a consultant at his own company Karhatsu IT Consulting in Helsinki, Finland.
He is a very experienced software developer that has worked for and with many clients over his career. He’s also been exploring how to improve our industry of software development and sharing his learnings in his blog.
You can connect with Henri Karhatsu on LinkedIn, and reach out to Henri Karhatsu on Twitter.
Henri Karhatsu’s blog.

Angel Diaz-Maroto shares his approach to start a change process

In this episode Angel shares many of the tools and techniques he uses to support the start of a change process in a system. There’s plenty of work to prepare the change before it can get started, and most of that work is about understanding the system we are about to be part of. We talk about many tools, like using Experiments, A3 problem solving and PDCA cycles for learning at the organisational level.

About Angel Diaz-Maroto

Angel is a seasoned and very energetic Agile coach and a frequent speaker at international conferences and Agile events in Europe and America. He is Certified Scrum Coach. Currently he is member of Agilar, one of the leading Agile coaching firms in Europe and Latin-America.
He is now at Agilar, but before he was the leader at one of the biggest Agile transformations in europe, including business and IT at the Spanish branch of a multinational bank (ING). He lead the transformation from the trenches and starting from scratch. He as more than 15 years of experience in many different roles and is a professor at ESNE (University School of design, innovation & technology).
You can link up with Angel Diaz-Maroto on LinkedIn and connect with Angel Diaz-Maroto on Twitter.