TLDR

If you have been reading my postings, you have noticed that I write detailed, complex and long compositions to explain my thoughts on agile principles and transformations.  I also do this in the normal course of planning and guiding agile transformations for organizations.  I like to share the ‘conscious’ side of ‘competence’ so others can explain the ‘why’ behind the ‘how’.

Needless to say, I often get TLDR in response, as in ‘Too Long, Didn’t Read’.  I have been asked to summarize my thoughts in a summary paragraph, a short presentation, and yes, once by a boss who told me to put the important parts in the email subject line.  Somehow, there’s an expectation that if I could only shorten the concepts to bullets, the ‘aha’ would happen across the organization.  Adoption of the concepts would be self-motivated and immediate.

This leads me to ponder how a medical doctor becomes one.  Consider how the best and brightest high school students are guided to a strong ‘core’ set of biology and chemistry while getting their bachelor's degree.  In medical school, they spend their first year learning how a healthy body works, in great detail and with hands-on experience (I won’t go into detail of the hands-on experience).  Their second year is spent learning pathology, or why and how things go wrong in an unhealthy body.  They finish out their last 2 years of medical school rotating between various medical disciplines understanding the basic practices, procedures and realities while continuing to deepen their basic knowledge.  They spend years preparing for the medical exam that will determine what medical specialty that they will spend the next two to seven years being an intern after medical school.  They have board certifications to master before they are allowed to freely practice as an attending physician.

Why do they spend this much effort to learn the complexity of the human condition?  One reason is that the downside of making a mistake is so high that it can cause undue pain and suffering, even death, as well as waste time and resources on missed diagnoses.

Let’s ponder a TLDR version of medical education.  Let’s assume that we have the most excellent medical snippets from X (formerly known as Twitter), TED talks, Youtube, LinkedIn and TikTok.  Let’s assume that a really smart designer using AI figured out how to place in front of our medical students the right information in the right order, of course monitoring dwell times, actions, and answers.  Once the medical students have been exposed to the right materials long enough with sufficiently successful metrics, they are free to practice medicine.  

Would you be willing to go to such a TLDR medical doctor?  

They might be able to diagnose simple cases.  They might be able to perform simple procedures.  They might be able to, when presented with x causes y causes z, reason with the patient that x causes y causes z.  They would likely be good at a particular ‘how’.

They would likely be unable to reason the complex ‘why’.  When they are presented with unseen representations or complex, multi-causal symptoms, they will not have the context to reason possible diagnoses. 

Why?  A simple diagnosis or procedure taught without context means that that same simple procedure may not apply in all contexts.  In fact, that same simple procedure may cause harm in many other contexts.  The ‘why’ explains context and the ‘how’ explains the procedure for the right diagnosis. 

Well, what does a medical education have to do with hi-tech?  There are no life threatening development teams out there.  Right?  While this may be true, technology development does have customers, investors, stakeholders, and co-workers who are depending on leadership knowing the ‘why’ and ‘how’ of complex situations, organizations, projects and products.  Making a mistake does cause harm to these dependents.  Why would anyone simply trust a TLDR trained technology leader?  Why would anyone trust an organization that demands TLDR communications or processes?

Allow me to redefine TLDR as Tough Learning Different Reasoning.  To build the necessary context takes time and exposure.  The context explains the solutions, procedure and rituals.  This is done by humans in taking time to learn, understand and experiment with new concepts.  Watching a lot of motivational TED talks won’t suffice.  Reading a ton of summaries or email subject lines won’t help. 

Tough Learning means that one has to spend time and effort to learn and think.  Simple impressions of Learning are insufficient to master the full context.  Different Reasoning means that the underlying principles and methods are unfamiliar.  To learn them requires practice and experimentation.  Few are able to read about the new rituals and discern the new principles.  Study, effort and practice are required for mastery.  

You should ask me then, what’s a test that you can take to determine which TLDR you have been exposed to in your past.  Here is the test:  Read the Poppendiecks’ book, Lean Software Development, An Agile Toolkit.  It takes between 2 to 4 hours for a seasoned technical leader to read the whole book.  

If your response is that you don’t have the 2 to 4 hours to read the book, then you know which TLDR that you’ve been exposed to.

If you read the book AND you can explain to yourself ‘why’ and ‘how’ for ALL of the 22 Tools apply to Scrum, S@S and/or SAFe v6 (or later), you have been exposed to the second definition of TLDR and are a well trained agilist.

If you read the book AND you can not explain to yourself ‘why’ and ‘how’ for ANY of the 22 Tools apply to Scrum, S@S and/or SAFe v6 (or later), you have fallen victim to the first definition of TLDR.  You should consider vesting time to learn the foundations and principles of agile development.

If you read the book AND you can not explain to yourself ‘why’ and ‘how’ for SOME of the 22 Tools, you have been exposed to a mixture of the TLDRs.  You have more to learn.  Focus on one of the tools and immerse yourself into building your understanding of that tool’s context.  Move to the next tool until you can explain the ‘why’ and ‘how’ for all 22 Tools.

We expect our medical doctors to be conscious competent.  Shouldn’t we expect that much of ourselves when doing agile development?

The Most Critical Step in Agile Transformations

The most enjoyable part of every agile transformation is the time spent with people during one-on-ones. They bring their realities and difficulties to the conversation. We sort out what’s going on. They allow me to share insights and provide alternatives for their consideration. They leave the discussions appreciative with ideas to consider for next steps. The best compliment that I can receive is when they thank me for allowing them time to think.

An often asked question after we’ve wrapped up a discussion is, from my perspective, what’s the most critical step in an agile transformation?  They are always surprised that my answer doesn’t appear to conform to the Agile Manifesto.  They expect something like, establish Scrum rituals.  Or, do agile training.  Or, define individual and teams’ roles and responsibilities.  Or, define the SAFe or S@S hierarchy.  Or, establish a maturity model with a clear definition of done.  And to be fair, these are important items to establish during an agile transformation, but they aren’t the most critical.

My answer is simply to establish a Learning Organization.  That is an organization that values curiosity, change, experimentation, inspections, introspection, education, teaching moments, trends, root cause analysis, improvement, and innovation.

I have found that many organizations are in an unconscious competence state where they do what they do because they have documented processes for how they do everything, but they have forgotten why they do these things, or they are in telling leadership style where they expect to ‘just tell the organization what and how to do everything’.  

The urgency of needing to fix a bad agile transformation gone wrong, to move quickly to mature agile development, and/or the onslaught of business conditions reinforces the leadership’s expectations to do what they do faster or just tell them what to do now.  There’s no time to learn.  Absolutely no time for experimentation.  If there’s any failure, there’s only time to punish.

At the core of agile thinking is empirical inspections, or the Plan, Do, Check, Act (PDCA) cycle.  The core is reinforced by Sprint Review meetings, retrospectives, burndowns, velocity and root cause analysis.  How can any of these be done without a Learning Organization?  Sadly, none can be done correctly.  Those organizations that do these rituals without reasoning, or do Scrum in name only aren’t improving, growing or learning.

When staging an agile transformation, my first act is to set up as many cross-functional, multilevel one-on-ones as possible.  The one-on-one frequency varies based upon particular needs of the individual.  They are always confidential and designed as a safe place for exploration and learning.  I always focus on root cause analysis in my questioning to help raise curiosity as to ‘why’.  I have never been disappointed by the 5 ‘whys’ questioning method that quickly guides our one-on-one to a deeper understanding of the situation and presents alternatives to consider.  I explain how PDCA, retrospectives, etc are aspects of learning and experimentation, and how those must be done to achieve improvements, albeit initially on a small scale.

What I’ve noticed is after a number of these meetings, that those involved in my one-on-ones start to set expectations with their leaders and teams for root causes, deeper reflections, incremental improvements and seeking information on concepts they don’t understand.  Learning is valued.  Time is set aside for discussions.  Experimentation is planned.  Results are inspected.  Adjustments are made.

As leaders mimic, teams start to learn and pick up on the value of Sprint Reviews and Retrospectives.  Teams become curious about ‘why’ the various rituals, metrics and roles are defined.  They become open to the role of the Scrum Master guiding the team to maturity.  This opens the door to more learning and improvements.  

A Learning Organization that only remains within a single function like engineering, can make good progress on an agile transformation, but one that does it across multiple functions can make amazing progress on agile transformation and the velocity of business value delivered.

The difficult step in a Learning Organization is to learn together across functional groups and across teams.  This means understanding that the role of leadership in an agile organization is different from what they may have grown accustomed to.  Functional leaders and their functions play important roles in agile organizations.  Setting up and enabling the role of architecture that empowers teams to act and gain velocity. Building a value chain from specification to builds to validation to deployment to enablement to sales to support.  Defining a product backlog that is built on continuous increments of capabilities that are continuously deployed.  

I liken creating a Learning Organization across functional groups to that of nurturing a human being.  When the human is a child, we nurture and educate them on the basics with an expectation that they will eventually grow and mature.  When they reach their teens, we help them understand the deeper, abstract nature of the world around them.  We can demand more from them, but they remain immature in other ways.  When they reach their twenties, we help them understand the interconnectedness and interdependence of complex systems.  We demand professionalism and perfection.  

I have found that a functional organization is well aware of their shortcomings, however, they expect and demand perfection from all of the other functions.  I have to point out that while the individuals and organizations may be highly experienced and successful, they too are in the midst of an agile transformation both within their organization and their relationship with the other organizations.  We need to realize that together we operate more like a child that needs nurturing and education together.  This is far better than demanding a child to do something that they are incapable of doing and expecting adult results.  

As we grow being a Learning Organization, we as a whole organization will become teens and adults.  As mature adults, we now understand the complexities in delivering value and continuous improvement.  We innovate. We teach.  We are consciously competent together.