Jan
15

It's about more than setting up Scrum teams.

The term "agile", when used in IT and software, is a quirk of history. The Agile Manifesto captured many principles that had been simmering in our culture for decades, then applied them to software. Had that fantastic document not been produced, we would most likely be talking about Lean Software Development, or Lean IT. Understanding the relationship between Agile and Lean thinking helps break through barriers that many teams and organizations face, both internally and with external business stakeholders.

Sometimes when teams are adopting agile frameworks (like Scrum) and practices (like Kanban), the benefits seem elusive. Most large organizations hit an early plateau, where real agility - the promise of sustainable pace instead of endless death marches - seems just out of reach. You may overhear comments like this:

"When is this agile transformation going to be done?"

"Our teams are exhausted."

"If only we could do that, things would improve."

"We're waiting for systems access/environment setup/testing to finish/security validation."

Fundamentally, these headaches are due to a lack of end-to-end systems thinking in the organization. To break through these logjams, scaling frameworks like Scaled Agile Framework (SAFe), Disciplined Agile Delivery (DAD), and Large Scaled Scrum (LeSS) can come in handy. But more importantly, the underlying principles of lean thinking and end-to-end system flow become essential.

End-to-End Systems Flow

In the mid-1900s, the "Father of Quality", W.E. Deming, mentored Japanese automobile manufacturers, helping influence a process of continuous improvement. This ultimately enabled Toyota to become the largest auto manufacturer in the world. At the pinnacle of his career, he introduced the concept of a system of profound knowledge and promoted a remarkable simple tool to achieve it: a flow chart.

"An organization may require someone...to teach and facilitate profound knowledge. We have learned that a flow diagram is helpful toward understanding a system." (Deming, 2018)

I first heard this quote while listening to an audiobook during my commute. I was eager to download the audiobook companion PDF to see what such a profound flow diagram looked like. To my surprise, it was ridiculously simple. It was a simple flow diagram of an organization's processes, linking inputs, production, and distribution processes. It didn't even include fancy boxes. It was simply words on a page with arrows between them.

StuckerBlog1

 

The profound insight comes from comparing the end-to-end system to how people work in independent silos, or competitive components.

StuckerBlog2

Since that eureka moment, I've encouraged many teams to visually model their processes and look for improvements. It works profoundly well. I also highly recommend listening to The New Economics or reading the book. It's a great primer on lean thinking, quality culture, and servant leadership, all foundations of agility.

A Picture is Worth a Thousand Words

Ever been on countless conference calls or in meetings that re-hash the same content over and over again? When the topics are complex, even after a hard-won consensus, that knowledge and agreement can be easily lost or mis-remembered. This is especially true if people just talk, without using visuals and diagrams to clarify important points and goals.

The average person can only hold a handful of concepts (usually around 7 to 10) in their working memory, at a time. Once the context is lost, it's difficult to reconstruct a complex solution from memory. A visual reference can facilitate stronger, more accurate recall and jump-start future conversations and action items.

Two flow diagrams artfully capture and preserve consensus related to complex process transformations:

  1. The current process as a flow diagram
  2. The future process as a flow diagram

Armed with these two tools, a small team that reached a consensus on behalf of an organization, can accurately communicate that plan to other teams and groups. They can also collect additional input and feedback in order to improve the process.

Be aware that having such a clear process diagram invites criticism. This is especially true when the current flow exposes problems in the organization - sometimes glaring, embarrassing problems - now clear for all to see. The reactions can be unpredictable. Putting a future state into a diagram format also invites idealists to punch holes into the proposed solution.

Agile practitioners know this kind of process can be repeated. If you can diagram an improved process today, you can do it again tomorrow.

Embrace the Ugly

Eventually, people will get used to seeing imperfect processes in visual form, especially when they are empowered to change them. I've been in many organizations that consider creating a diagram tantamount to etching a process in stone. Abandon that thinking. A diagram is a representation of reality. We can only change what we can see.

Agile Principles at Large

Scrum is built upon the pillars of empiricism: transparency, inspection, and adaptation.

  • Transparency: You can't fix what you can't see
  • Inspection: Making something visible is useless unless you look at it
  • Adaptation: We must follow-through with action in order to improve anything

These principles of empiricism are the foundations of the Scientific Method. They're essential to quality culture, lean thinking, and learning organizations. Agile thinking builds upon the shoulders of giants who paved the way.

The Giants

This foundational thinking not only applies to our processes, but also to the underlying principles that guide the transformations of teams and organizations.

In my experience, most of the agile software community also embraces DevOps, which is yet another set of disciplines related to lean thinking and continuous improvement. Gene Kim and John Willis expertly weave the relationship between these disciplines in their audiobook, Beyond the Phoenix Project. They paint a vivid picture of the history of DevOps, with its many inputs from agile and lean thinking, quality culture, safety culture, and learning organizations. These various disciplines are close cousins and its often good to have a family reunion and compare stories. Another excellent example of story-telling and historical reflection can be found in Eli Goldratt's series of lectures in Beyond the Goal.

With that in mind, it's no surprise that the business novel that introduced DevOps to the world (The Phoenix Project) was explicitly modeled after Goldratt's business novel The Goal. Flow modeling was an underlying assumption in Goldratt's Theory of Constraints, introduced in The Goal. This theory provides a lean approach to identify bottlenecks in processes in order to eliminate the constraints and improve end-to-end system flow.

What's Next in Flow Modeling and Agility

In 2018, Mik Kersten brought together agile concepts and DevOps process thinking in the book Project to Product: How to Survive and Thrive in the age of Digital Disruption with the Flow Framework. Using an airline route map as a metaphor, Kersten introduces the Flow Framework as a model for managing software delivery.

Influenced by lean manufacturing concepts, like the agile practitioners before him were, Kersten refers to automobile manufacturing as an inspiration for software development processes. This time, it's not the Toyota Production System but BMW that serves as a shining example of lean thinking and process flow efficiency.

Each of these resources creates a vivd image of how things can improve when we put on minds together and develop processes with tight feedback loops, promoting inspection and adaptation. They encourage the visualization of our processes as specific tools designed to assist with those feedback loops and pave the way for consistent improvements.

If, like me, you listen to each of the works I've mentioned in this post on audiobook during your morning commute, you'll be eager to get to the office and begin mapping out diagrams on a white board.

 

Learn more about how to apply Agile Delivery using Scrum. Sign in with your All Access Pass today!

Watch Now

 

 

 

Jeff Stucker
About Jeff Stucker

Mr. Jeff Stucker has 25+ years of IT experience as a consultant, manager, data architect, and software developer. A certified Agile coach and team facilitator, he has Full Solution Development and Support Life-Cycle experience with Cloud and Enterprise Premise solutions. Jeff has recently led Agile transformation and training for a 600+ member department of a global bank and facilitated the creation of DevOps pipelines and test automation for numerous different software and database technologies. He's also coached distributed teams adopting Scrum and Kanban practices, designed Agile reporting systems for continuous team improvement, and optimized operational support across multiple teams. At home, Jeff is happily married and has 2 teenagers. He enjoys studying history, as well as getting out in nature for cycling, hiking, and cross-country skiing.

Subscribe to INE Blog Updates

New Blog Posts!