An Apology, An Explanation, A Promise and A Call to Action

December 1, 2017 — Posted by Al Shalloway

The Apology

Last night after a very successful but very intense trip to a client I was on an airplane headed home.  I had told myself I would just relax but couldn’t.  I made the mistake of getting on twitter (something I know I shouldn’t do when I’m tired).  I got into some dialogs and said something that was plain old wrong.  I deleted it, and restated it, but the restatement was still wrong.  For those who weren’t there (and I am sure are now curious) I will repeat the deleted tweet:

The fact that I am the _only_ person who has put forth an approach to Agile at scale and am requesting that people tell me what’s wrong with it so that I can improve it tells more about this industry than anything else I know.

I restated it for clarity:

Let me restate this to make it clearer. Net Obj is the only company with an approach to Agile that works at all scales who is also asking ppl to tell them how it can be improved.  We want discussion of what is the best approach so as to make it better.

Both tweets are wrong and I have deleted both now and I apologize for both. My intention for both tweets was to bring forth the idea that we need more discussion about what works and what doesn’t in this industry.  I was not trying to make myself be anything special. But the implications regarding others were clear and not appropriate. And that’s what I am apologizing for.

The Explanation

Now explaining why you did something wrong does not diminish the mistake.  But it may help shed some light on what may be useful thinking. As many of you know, I have been involved in the forefront of XP, Scrum, Kanban (both Lean based and LKU kanban) and SAFe.  I have not gotten involved in LeSS or Nexus because disagree with the assumptions/mindsets on which they are built.

Over the last 19 years of consciously doing Agile (some before it was called that) I have seen a lot of misunderstandings by very bright people.  Sometimes it’s just been a learning process, sometimes its been due to them being misdirected by people they trust (I am not saying intentionally).  After seeing these patterns over and over again, I sometimes get very frustrated. The frustration is that I sometimes think that some of the people that I believe are contributing to this don’t recognize this.  In many cases,   I believe their intents are good.  I really do.  But good intentions with bad results are still bad results.

One of my fundamental beliefs is systems-thinking.  That we must look at the whole.  We can not take components of a system and change them and expect to change the system. That modifying one part of the system has a system-wide effect – often not anticipated.  Russ Ackoff did a great talk that if you haven’t see it I highly recommend you do.

Systems are complex.  But we make them much worse if we deal with only one aspect of them. This means that if you introduce a framework or method to a company you are embedding your approach into the system – and it becomes part of the system.  How people are affected by this, in my mind, should be part of the approach.  

This impact is often ignored.  Or at least aspects of it are.  It’s why we often see initial success only to lead to stagnation in most every approach I know.  Sustaining success typically happens when an experienced consultant or internal transformation leader keeps adjust the transformation.  We hear the words “inspect and adapt” but usually they are stated on how to improve the framework or method.  Often we need to go beyond the framework or method using double loop learning.  People describe this as “shu ha ri” (going from following to owning to transcendence)  but typically don’t talk about how to go from shu to ha.  My question would be how do we set that up.  I actually don’t believe shu ha ri is a good metaphor for this, but that’s another story.

It’s easy to say – “well that’s bad X” but if X causes it to happen on a regular basis, then it’s part of X. In fact, this is exactly what triggered this conversation with the inappropriate tweets.  I came across, for the hundredth time, a client who had a former consultant who was doing Scrum “by the book” – meaning “do it this way because that’s what’s in the Scrum guide.”  As Ron Jeffries so astutely pointed out, you can’t really do that if you read the whole book because the Scrum guide says to inspect and adapt.  But you get the idea.  This is bad Scrum.  This is dogma.  But this is common.

This industry has a lot of misunderstanding.  It would be like having a highway system where some of the people say “here we drive on the left” while others say “here we drive on the right” yet both sides don’t talk to each other.  And when someone tries to ask “well, when should we drive on the left and when should we drive on the right?” others say – “let’s be in this together and unify things and not talk about differences.”  Sorry, this just makes me crazy.  Especially when I’m tired.

A Promise

My intentions in discussing things have always been about helping people better understand ideas that will help them.  Sometimes they’ve “learned” things that actually are incorrect and, in my opinion, need to be told, that that won’t work. I don’t always say this well.  And some people are nervous about having someone telling the world that something won’t work that they make their livelihood on.  Some people just are passionate about their beliefs and feel attacked if you suggest their ideas are incorrect.  Some people can only apply ideas in a certain way and are afraid if that manner is claimed to be ineffective.

I am thinking about what can I promise as I am writing this to have more effective and appropriate behavior.  Promises are a commitment to change action.  I am considering what promise would have me communicate more effectively when I am in a situation of frustration, passion, and weariness.    I take my promises seriously.  It’s a commitment, it’s something that I say is consistent with my beliefs and values. 

I don’t think I can promise I won’t talk about people misapplying Scrum to their clients.  Nor can I promise not to talk about something in method or framework that I believe is harmful.  At this point I think all I can promise is not to tweet when I am tired.  That does make sense – but I’ll think some more on this.

A Call to Action

I believe that we reached a stage in the early 2000s where how to write high quality code was known.  Albeit few did it.  Unfortunately, in the last 15 years the number of people using these approaches is still relatively small.  Some of this, of course, is that new folks come in every year.  But it has been encouraging me to see people like Uncle Bob Martin and many others create forums for discussing what is effective coding.

Sometime a few years ago I would suggest that we also now know good practices for effective software development and how to discern what should even be built.  In this case, however, there is not agreement.  There are several different philosophies out there.  Some work better in different places than others. 

I don’t believe there is one-size fits-all approach, or even one-size fits-all mindsets.   It depends what you are going after.  If you are a small development team where you have control over what is to be done, a different mindset may be better for you than if you have a group of 300 developers being driven by 5 different stakeholders.

A challenge I see in this industry, and what I was trying to point to in my misguided tweets, is that we should be discussing these issues openly.  What are our mindsets?  When do they work?  How would we apply them?  How do they affect not just people who are experienced but who are new to the game?  What truth is out there that is truth everywhere? That is, is there something like gravity in the world of software development? 

I have recently announced FLEX (FLow for Enterprise Xformation).  This is a writeup of parts of our approach to enterprise transformation, whether it be 50 or 50,000.  It is not a framework, but rather a method of thinking to create a step-by-step transformation approach to helping organizations solve the dilemma of needing a solid place to start while knowing there is no one-size-fits all.  This has been guided by our successes and failures over the last 19 years.  When we have succeeded, fortunately more often than not, we look to see why.  When haven’t met our clients’ expectations, we’ve also looked to see why.

It’s easy to ascribe less than successful implementations to a client not adopting what we suggested. But the reality is that as soon as we enter the door we become part of their system.  Our approach has to include the way it affects their thinking process.  Years ago I created a system I called “the inflection point system” which could be used to model any framework or method.  It was very powerful. In the right hands we had some great success.  But in the wrong hands we had some failures. 

Open discussions about what worked and why and what didn’t and why had us (or I should say me because I was the one wielding this particular approach) change it.  Others in my company had taken a more effective route and have a better track record.  The point is we learn.  We have more to learn.  No one has a solution – nor is there one.  There is only movement towards better ways. This is how to acknowledge we are in a complex field and the real challenge is always a people challenge (kudos to Jerry Weinberg).

I believe we still have much to learn about how to make organizations more effective.  I believe that the bigger problem is not figuring out what to do but in getting people to do it.  I don’t believe we can stand on mantras such as “it’s simple just do it.”  What is being stated may be simple but getting people to do it is not.  Not to mention “simple” is not the goal anyway – understanding and effectiveness is.  No system stands on its own.  Every approach becomes part of the system that it is trying to affect and therefore is complex.

So my call to action is to join me in trying to figure out how to solve this problem of first, figuring out what’s good and where it applies, and second getting people to adopt it.  This is in the form of a general conversation about what we should do in particular situations, and what we shouldn’t do in particular situations.  I believe our industry can only solve the issue of how to be more effective by discussing what works and what doesn’t.  I am requesting people’s opinions about that and inviting open dialog.  I have put forward FLEX as a way to codify what we’re doing so as to allow a discussion of what works.  I invite you all to tell me what you like, but more importantly, what you don’t like. 

It’s not that we learn by failure.  The oft repeated mantra of “failing fast” is misguided.  Many of my learnings have been due to quick success when I hadn’t expected it. It’s “learning fast.”  We often learn from failures because they challenge our belief systems. So I’m looking for feedback that challenges my beliefs, although getting a “that’s pretty cool” is always nice to hear. 

If you’ve reached the end of this blog I thank you for your time and hope you’ve found it valuable. 

Al Shalloway

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With over 40 years of experience, Alan is an industry thought leader in Lean, Kanban, product portfolio management, SAFe, Scrum and agile design.



        

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban