Disciplined Agile Applied

I recently had the pleasure of reading Agile Transformation: Organizational Agile Transformation in 5 Steps by Eren Ozdemir and Orhan Kalayci. As the title suggests, the book describes strategies for agile transformation. The approach reflects the Disciplined Agile (DA) mindset and other aspects of the DA toolkit, which is what got my attention.

To describe the transformation process the book applies the analogy of treating a patient. As a result, they describe the five steps of agile transformation as:

1. Occurrence of the disease. In this case, the organizational disease is not serving your customers well as the result of not working in a rapid, faultless, efficient, and integrated manner.
2. Diagnosing the patient. The aim is to assess what is going wrong and why it is going wrong.  This requires expertise and experience. It also requires you to look at the whole picture, not just portions of it. To help illustrate this point, they use the DA Value Stream to illustrate the interconnectedness of your overall way of working (WoW) and work through the implications of that.
3. Making a treatment plan. Every person, team, and organization is unique. You need to identify an improvement strategy that reflects the context that you face.  Furthermore, it's about improving your WoW, it isn't about adopting a prescriptive agile framework (regardless of what the purveyors of such frameworks may tell you).
4. Administration of the treatment. This is the execution of your improvement strategy, which will evolve as you learn and as your situation changes.  Flexibility is key and it requires you to put your people at the center of the transformation.
5. Healing of the patient and sustaining a healthy life. The true goal of any transformation is to become a learning organization, one that has the ability to adapt and improve over time. In DA we promote the strategy of Guided Continuous Improvement (GCI) to do exactly that, and it is a skill that you want to teach your people during step 4.

Here is what I think you will find valuable about this book:

• It is based on the real-world experience of its authors.
• It is insightful, providing great advice that you will be able to apply in your own environment.
• It recognizes that agile transformations tend to be fragile, requiring flexibility and context sensitivity.
• It doesn't present a "one size fits all roadmap" and is clear from the start that there are no simple solutions. 
• It is a short, easy read at less than 100 pages.
• It aligns well with DA's Transformation Strategy - Steps 1-3 map to the Align stage, Step 4 maps to the Improve stage, and Step 5 maps to the Thrive stage. 

In short, if you are in the process of an agile transformation, or thinking about embarking on one, this book contains significant wisdom that you will benefit from. It is worth your while to read Agile Transformation: Organizational Agile Transformation in 5 Steps.

In case you haven't heard, PMI's Mike Griffiths has a new book out, Beyond Agile: Achieving Success with Situation Knowledge and Skills. Mike is a well known and respected thought leader within the agile community.  To be transparent, Mike is currently an employee of PMI, working on the Disciplined Agile IP team with me, and he is a long-time volunteer with PMI and contributor to PMI publications.  

So why is one of the Disciplined Agile (DA) guys recommending a book titled "Beyond Agile"?  Simple: The material in this book is incredibly complementary and confirmatory to what we recommend in DA.  Here's what I like about Beyond Agile:

1. It promotes a hybrid strategy. Just like DA, the Beyond Agile approach recommends mixing a combination of lean, agile, and traditional strategies.  And it recommends doing so for both project teams as well as long-standing teams (such as product and service teams).  
2. Context counts. A common theme throughout the book is to do what is right for the situation that you face.  So there are no best practices, rather there are practices that work well for you given the context of your situation.  Furthermore, having industry-specific knowledge and experience is a part of that - what works well for the automotive industry may prove to be a mess for the financial industry, and vice versa.
3. It addresses people issues. The book offers a lot of great advice around people-oriented topics.  This includes emotional intelligence (EI) and emotional quotient (EQ), both intrapersonal and interpersonal skills, leadership, servant leadership, and working with stakeholders. Just this material alone is worth the price of the book (and the rest of the book is great too). 
4. It addresses process issues, particularly those critical for project professionals. One of the greatest frustrations that project professionals have with many agile writings is how they avoid, gloss over, or provide naive advice around issues that are critical to your success.  Luckily this book doesn't make that mistake.  It provides proven strategies for when (and when not) to take a plan-driven approach, how to work effectively with project management offices (PMOs), performance analysis and reporting, estimating time and cost, and risk management to name a few key topics. 
5. It covers organizational change. Adopting more agile ways of working is a change for many teams and their organizations.  The book covers several key topics in this space, including Frederic Laloux's organizational model and several organization change models (Kubler-Ross, Satir, ADKAR, Kotter, and SCARF).  While the book won't make you a change expert, it does cover critical models that you may want to explore in greater detail.  You may also find the offerings of PMI's BrightLine to be of value.
6. It's consumable.  This book is well-written and an easy read.  There are a lot of pictures including great cartoons.

There are several compelling reasons to read Beyond Agile: Achieving Success with Situation Knowledge and Skills. In summary, Mike says it best on his page describing the book:

Beyond Agile is for project practitioners, PMOs, and business representatives who want relevant, high-value delivery guidance. The book presents a model that provides a context-specific approach from a full spectrum of project disciplines including: lean/agile, leadership/EI, plan-driven, and industry-specific approaches. Unlike scaling models such as SAFe, LeSS, and Nexus, the Beyond Agile Model avoids agile-myopia (believing everything can be solved best by agile approaches) and buffet-syndrome (taking on too much process) by being simultaneously broader but ruthlessly selective in its recommendations.

I recently had the privilege of writing the foreword for "Navigating DevOps Through Waterfalls" by Brent A. Reed, Willy Schaub, Mathew Mathai, and Lauren Mix with illustrations by David Hughes-Coppins.  Regardless of where you are on your DevOps adoption journey, even if you are far down the path and realize that you’re actually on a continuous improvement journey, this book has something for you.  I learned a fair bit by reading this, and I’ve been doing this for years.

Here is the text of my foreword:

DevOps has become table stakes for modern organizations.  DevOps must be baked right into your organizational way of working (WoW) if you are to thrive in the “new normal” of constant change.  DevOps enables your teams to become semi-autonomous and self-organizing, more disciplined in their WoW, and in a better position to improve how they address the needs of their customers. This book provides proven strategies for how to make this happen.

The authors present their DevOps adoption advice as a story.  This is a tale of a fateful trip, a trip that started from a tropic isle, aboard a tiny ship.  The mate was a mighty sailing man, the skipper was brave and sure, and five passengers set sail that day for a three-hour tour.  A three-hour tour!  But the weather started getting rough, the tiny ship was tossed.  If not for the courage of the fearless crew, they would have been lost!  Oh wait, that’s Gilligan’s Island, not this story.  My bad. 

This book is a story that is based on the hard-won experiences of the four authors after helping various organizations for years in their DevOps adoptions. DevOps has effectively become table stakes for your organization’s IT processes, all the more so given how COVID-19 has upended societies around the globe.  In the private sector the marketplace has become far more competitive, requiring companies to get better at sensing what their customers need and responding quick to fill those needs before someone else does. In the public sector the needs of their citizens have increased while the tax base has shrunk, implying that they need to do more with less.  My advice is to take this book seriously – although it is presented as a work of fiction the lessons in it are very real and very important.

Now that I think about it, many DevOps adoptions efforts turn out to be a lot like Gilligan’s Island.  Many organizations mistakenly believe at first that they are embarking on a short effort to adopt DevOps, or worse yet to “install DevOps.”  They hope that their journey will be straightforward and over with quickly, perhaps three to six months to Gilligan’s three hours.  Then they quickly find themselves in trouble, stuck on a transformation trip that they don’t know how to navigate. 

Why do DevOps transformation efforts run into problems?  It’s often because they don’t invest time to identify a compelling vision and instead head out into the transformation sea.  A critical lesson that the authors convey in their tale is that you must define, and then communicate clearly and consistently, both the what and the why of your DevOps transformation. Your objectives and the results you how to achieve become a driving force for your organizational success, and a driver for what you measure. What gets measured will get improved, and you very likely have a lot of things that need to be improved to fulfill your goals.   

There are other similarities between ineffective DevOps transformations and Gilligan’s Island. Many episodes centered around some sort of unlikely strategy for the castaways to escape their predicament, but their plan would invariably fail due to mis-execution.  Sometimes the professor’s attempts to cobble together the existing material available to him – bamboo, coconuts, and something that had recently washed ashore – would fail because they simply weren’t up to the task.  Sometimes the castaways would have different personal goals and were working at odds to one another.  And sometimes one of the castaways, usually Gilligan, would make a mistake and ruin the plan.

Just like the castaways were thrown into a situation that they were ill-equipped to deal with, many DevOps transformations are similarly poorly thought through.  When funding for new tooling isn’t available, and teams are forced to make do with what they have, this is the equivalent of the professor trying to cobble together a radio from coconuts and bamboo.  When teams don’t know the what and the why of your strategy, they work at odds to one another and waste organizational resources.  When people haven’t received training and coaching in new DevOps techniques and technologies they are apt to make mistakes that will undermine your organization’s efforts to escape from their existing WoW.

But I digress.  The entire predicament of having to escape from Gilligan’s Island could have been completely avoided had they only known what they were doing to begin with.  First, they would have acted differently had they known they were going out into a storm.  And let me be clear about this, DevOps transformations always get stormy.  The advice described in this book shows you how to avoid common problems that other organizations have suffered from, and how to navigate through them.  

Second, if they had a better boat and a crew prepared for the situation that they faced then they very likely could have successfully weathered the storm. This book works through the equivalent of building a capable crew by describing the mindset and the skillset that they need to succeed.  This includes business representatives that are actively involved in the effort and a supportive engineering process (or at least the beginnings of one). It also shows how to build a better boat by picking the right project(s) and developing a supporting DevOps infrastructure.

Third, you need some outside help.  Just like the castaways on Gilligan’s Island faced problems that they weren’t capable of overcoming on their own, so will you.  The transformation journey described in this book is supported by experienced change agents who coach the organization along the way. Without such help you will quickly find your transformation efforts running aground on the shoals of organizational complexities you don’t know how to avoid on your own.

Regardless of where you are on your DevOps adoption journey, even if you are far down the path and realize that you’re actually on a continuous improvement journey, this book has something for you.  I learned a fair bit by reading this, and I’ve been doing this for years.