Hit Rock Bottom? Maybe Now You’re Ready for Agile


Despair One of the things I enjoy most about my work is meeting other Agile practitioners and coaches and sharing war stories. Recently I was at an Agile Coffee with people who had various experience with Agile, ranging from complete neophytes to folks with many years of experience. The topic chosen was “What are the preconditions for a large company to be successful implementing Agile?” – a very pointed, yet valid, question to be sure. All of the answers were ones that one might expect; support from upper management, learning culture, etc. except for one. The lone unobvious answer was provided by someone whose opinion I respect. I was somewhat surprised at the time and it has reverberated in my mind ever since, “one precondition for a company to be successful in an Agile transformation is they have failed miserably and have hit rock bottom.”

The term “rock bottom” is most commonly used by folks in NA and AA (Narcotics Anonymous and Alcoholics Anonymous). I found the following definition of rock bottom on a website for alcohol addiction:

… often used to describe a point … when they are finally willing to seek help. Things are now so bad for them that it is impossible to deny their problem anymore. Hitting rock bottom may result due to a particular event, or it can be a slow decline over time. This is a subjective term because some … will be willing to suffer a lot more … than others.

I first came in contact with Anonymous groups through my work in healthcare (nearly a lifetime ago when I was a licensed Health Care Administrator) and have more than one commented on how Agile transformations remind me of some of the twelve steps – with the first step being to admit one has a problem.

So when my friend mentioned that a good indicator for agile transformation success was a company had hit rock bottom I knew exactly what he was referring to. In this particular case he used the examples of the FBI Sentinel Project and Healthcare.gov website debacle. In both cases, it wasn’t until each was a total disaster that Agile was actually tried with any seriousness and rigor and in both cases the results were amazing.

The total spend of these [two] failed [Waterfall] attempts to replace the ACS system was $597m and wasted 10 years. The Agile project, which is now delivering a solution, will only cost $114m for a three-year long project.

DespairIn another recent talk I went to on Agile a gentleman explained how Agile helped with an ad agency. He was only brought in AFTER the agency blew millions on a website that never made it to production. After losing millions I would guess this agency hit “rock bottom”. The good news was that Agile was able to help them to change and allowed them to produce high quality software with a much better time to market (than never).

In my agile coaching practice I have had more than one conversation with enlightened management that has acknowledged our Agile transformation wasn’t working as good as hoped and, barring a complete meltdown, most folks were happy to continue along a non-optimal path. In fact, relative success is a particularly sticky barrier to change as people often confuse the ability to get something done with the ability to get something done optimally. Bill Gates has often remarked, “Success is a lousy teacher. It seduces smart people into thinking they can’t lose.” Sometimes what we mistakenly call “failure” is a much better teacher. Sometimes the lesson is more important than the perception of relative success or failure.

Just this morning I was listening to my local NPR station as they were having a fund drive. Like many others, I couldn’t wait for the drive to be over so I could no longer had to feel the shame and guilt of being a “free rider”. Fortunately, it was the last day of the pledge drive and my mind was only half listening to the chatter of the announcers when they introduced Shankar Vedantam who does segments on the Hidden Brain (which I enjoy immensely). His topic was why people donate (or don’t donate) to pledge drives. He talked about humans’ tendency to pay more attention to emergencies and crisis than what is important. Being the last day of the pledge he hoped what was merely important (donating) would now also be given the status of an emergency because time was running out.

DespairMy mind went immediately back to the concept of “rock bottom” and why this is one good indicator of where Agile can be successful. Sometimes it is only when we hit rock bottom that the importance of being Agile begins to align with the immediate crisis of having to be Agile. It is then, and unfortunately for some, only then when Agile gets the attention and focus it deserves. It is my hope companies realize becoming an Agile organization is essential to their long term survival (at least in organizations that rely heavily on software development), seek the help they need to transition and actually carry out the transition before they hit rock bottom. In the meantime, if you have hit rock bottom (are you listening Yahoo!?), please seek out Agile help.

Project Manager/Scrum Master: A Cry for Agile Help

call for help

Over my time as an Agile Coach I cannot even begin to count the number of times I have been approached by recruiters for a position as a Project Manager/Scrum Master. My coaching colleagues and myself often joke about this particular job title saying, “we like the title Project Manager/Scrum Master because it helps us know which jobs and companies to avoid.” Why would we avoid such positions? For better or worse, by using the title Project Manager/Scrum Master we are able to quickly infer a great deal about the company and their experience with Agile – most of it not positive.

call for helpThe first thing we notice about a company using this title is that they usually have little or no understanding of Agile and Scrum. The duties of a Project Manager and Scrum Master are quite different. Not only do the two roles perform different functions, but they represent a fundamental different in the way they view the world. Project managers in Waterfall try to control projects. Scrum Masters work with Agile Scrum teams to facilitate. In Waterfall, Project Managers have responsibility. Scrum Masters, on the other hand, do not have direct responsibility as the responsibility for success shifts to the development team and Product Owner. Since the Product Owner decides the sequence of the work, a Product Owner is the closest thing to a Project Manager in Scrum. A simple Google search of “project manager versus scrum master” can provide more information on this for those who are curious.

This particular problem manifests when a company desires the potential benefits of Scrum without really understanding Scrum. Without a good understanding, people attempt to map their existing roles with those of Scrum. Let me make one thing perfectly clear. The role of Scrum Master is unique to Scrum and any attempt to map it to existing roles will only result in confusion, frustration and less than optimal outcomes. As coaches, if given the choice of coaching a complete novice as scrum master or “retrofitting” a project manager as a scrum master, we chose the former. It is not that project managers cannot become good scrum masters because many have, but in order to properly train one as a scrum master there is a great deal of work in “unlearning” much of what has been previously trained. With novices the time spent “unlearning” is non-existent.

life perserverThis is why I believe that companies recruiting for Project Managers/Scrum Masters are actually making a very public plea for help. If a company truly wants the benefits of Agile, it is essential that they actually take the time to truly understand that becoming Agile through the use of the Scrum framework is a serious commitment. People must gain a better understanding of software development and how knowledge workers differ, change their fundamental thinking around projects and products, pursue organizational change and realign people around properly configured scrum teams, work with recruiters who understand the difference between project managers and scrum masters and work as partners to recommend better solutions to underlying organizational needs.

For those seeking Project Managers/Scrum Masters, I hear your cries for help. As an Agile Practice Director I would love to help you to better understand your real Agile needs, to help you reorganize your work and people to take advantage of Scrum (other Agile frameworks, methodologies and development techniques), to optimize your organization so that you can deliver high quality software in a shorter time. I am available anytime to provide the help you need. If not me, please reach out to another Agile professional so we can rid the world of Project Manager/Scrum Master for good.

One Effective Interview Question for a Scrum Master or Agile Coach


I have had the good fortune to be involved with Agile software development for close to a decade now. During that time I went from a somewhat skeptical Director of Software Development to someone who now makes his living helping others create great software by applying the Agile philosophy as an Agile Practice Director. One of the things I have noticed during this time is, as Agile (and especially Scrum) have become more mainstream, the quality of individuals calling themselves scrum masters and agile coaches has become more variable.

The problem is certainly not new or particular to Agile Scrum Masters and Coaches, However, I feel that that, given their centrality to software development teams, the fact that Agile is new to many organizations and in many cases these individuals are expected to aid in transformation, having an ineffective Scrum Master or Coach can lead to disproportionally negative effects. For example, a single inadequate developer can be a real drag to a team, an ineffective Scrum Master can be detrimental to multiple individuals and multiple teams and the same inadequacy at the Coach level can lead to wholesale bedlam for large parts (if not the entire) organization.

BookThe problem is further exacerbated by, as I (and others) have pointed out in the past, by a weak and inadequate system of certification. It is good business to mint as many scrum masters as possible from a two-day training, but it does the outside world no service. This begs the question – in a world where every former project manager with a CSM calls themselves a scrum master and every scrum master with a few teams under their belt calls themselves a coach, how can I really assess those who have talent from those who do not?

Of course, one could use someone’s resume to assess the breadth of work. How many different teams has one worked with? How many years has one been involved with scrum? How many different organizations has one coached at? Unfortunately, individuals looking for work have a tendency to prevaricate at times so how is one to know if that time was really spent doing Agile or did I conveniently reclassify this work because it was not “entirely waterfall”?

A good deal of my current work is trying to make these kinds of judgments. If you too need to assess the ability of a scrum master or coach, let me share the question that I have found to be most effective:

What book have you read recently that has changed the way you think about Agile and the way you go about your job as a scrum master (or coach) and why?

If you are merely a paper candidate who has relied on the minimum set of qualifications (ie you have a good number of certifications) then this question is very difficult to answer. Being a scrum master or coach requires a level of passion that transcends merely implementing a small set of learned behaviors. It requires an active mind that is constantly seeking new ways of thinking,, new experiments to try, new behaviors to model – any and everything that one can do to truly be a servant leader. Passionate people always want to improve. There is no better indication than reading as a means of improving one’s ability.

Library of BooksThe question not only shows ones ability to think critically, but it also indicates a higher level of maturity. To read something that changes ones view requires the ability to realize ones knowledge is never perfect or complete. I have to acknowledge that something I hold to be true today may not be true or that I have a true ignorance of certain things.

Agile and scrum are about continuous improvement. We should not expect our scrum masters and coaches to have all the answers any more than we can expect our teams to function perfectly. There is always room for improvement and it is the good scrum master and coach who is not only able to admit this, but also has taken the steps necessary to improve. One of the most accessible ways for this improvement is to read books and to apply this knowledge. So the next time you are asking yourself “Is this scrum master or coach any good?” perhaps you might want to ask them this simple question:

What book have you read recently that has changed the way you think about Agile and the way you go about your job as a scrum master (or coach) and why?

Type Three and Four Errors – Solving the Wrong Problems Flawlessly

covered wagon

For some reason, I find myself attracted to statistics and probability. This is one of the reasons I love the books of Nassim Taleb, anything that Stephen J. Dubner and Steven D. Levitt of Freakonomics fame write, the social economics work of Dan Ariely, etc. Most recently I was doing some research and ran into the work of Ian I. Mitroff and Abraham Silvers and “The Error of the Third Kind (E3)”.

Because I had read so many books that have statistics and probability as themes, I was familiar with Type One and Type Two errors. Type One errors can be defined as incorrectly detecting an effect that is not present. Type Two errors, on the other hand, occur when one fails to detect an effect that was present. However, Type Three and Type Four errors were new to me.

An Error of the Third Kind (E3), as presented by Mitroff (and others), are those where the wrong problem has been not only proposed, but it is solved flawlessly so that it has the perception of being correct. Mitroff states:

The vast majority of books on management contribute to E3 because they imply that managers already know what their important problems are, for example: how to downsize in the most efficient way, how to improve chances for success in the global economy, how to install the correct Total Quality Management program, how to design the right reward system and so on. In each case, the unstated assumptions are that the essential problem the organization is facing is downsizing, global competitiveness or whatever it may be. While the assumptions may be correct, they are so crucial to formulating a problem correctly that they deserve to be challenged in the strongest possible way by asking tough questions.

puzzleThis type of error reminds me of the argument I often hear from clients that “we have always delivered” or “waterfall has worked for us for years.” The real question that needs to be answered is not if one has “always delivered” it is “what has one always delivered?” If, in software development, the code is difficult to maintain, if it has a great deal of technical debt (for example, only concentrating on on-time delivery), can it really be said that one has delivered successfully?

When someone mentions “waterfall has always worked for us”, I believe this is an example of Type Three error. The real question – has waterfall been optimal? The example I always give is that the covered wagon was successful for transportation, but when I look out the window of a plane, I don’t see any crossing the prairie. In the case of those applying the values and principles of agile properly there is little doubt as to which is the airplane and which is the covered wagon.

Type Four errors may be even more insidious. These are sometimes better known as HiPPO errors (Highest Paid Person’s Opinion). These are seen in companies where top down hierarchical control is the norm. In their book, Dirty Rotten Strategies: How We Trick Ourselves and Others Into Solving the Wrong Problems Precisely, Mitroff and Silvers state:

The Type Three Error is the unintentional error of solving the wrong problem precisely. In sharp contrast, the Type Four Error is the intentional error of solving the wrong problems…

The Type Three Error is primarily the result of ignorance, a narrow and faulty education, and unreflective practice. In contrast, the Type Four is the result of deliberate malice, narrow ideology, overzealousness, a sense of self-righteousness, and wrongdoing.

By allowing others to improperly frame the question, a troublesome groupthink is created that allows many people to solve the wrong problems precisely.

As companies go down the road to Agile transformation, it is helpful to understand the Type Three and Four errors so that we don’t fall into the trap of solving the wrong problems flawlessly.

No More Agile Checklists – Can We Concentrate on Outcomes?

As an agile coach and change agent I am always asked how maturity can be measured at the team and organizational level. What I have found over the years is that there is no lack of different checklists that can be used to give us these “metrics”. In fact, a recent Google search gave me a page that contains links to literally 41 checklists. In addition to these I have personally worked on many different custom checklists myself as if the 41 currently available do not adequately address the needs of teams transitioning to agile! Why is it that these already existing measures are not enough?

Here’s my theory.  Most agile transformations are accomplished by outside consultants (like myself) and these outside consultants know that beginners are looking for checklists. A great way to make money and to fulfill the client’s desire is to create a custom checklist or impress the client with a proprietary checklist – one assured to work where none of the hundreds of others can’t.

There is a problem with this checklist approach – it doesn’t really work all that well. The problem is that checklists tend to measure input and are very reminiscent of the failed waterfall view software development.  It is, in effect, a CYA type of activity.  In other words, you cannot blame project failure on me because I checked all the checkboxes. If checklist software development worked then waterfall would have a respectable success rate and folks wouldn’t be flocking to agile alternatives.  No sense trying to fix the problem with the failed approaches of the past.
Another problem is that Agile works because of self-organization of teams and checklist tend to be very prescriptive and top down. A great number of these checklists have so many very specific factors that are measured that they provide little room for experimentation for the team to discover the best way for them. A checklist assumes that they way measured is THE way. If this is truly the case then what about the manifesto which States that we are “uncovering new ways ” not that we have found a way and we have a checklist to show you the way.

My inclination is to reduce our focus on the inputs of Agile and spend more time focusing on outputs. Instead of measuring whether a stand up lasts 15 minutes or less, I think it best to focus on what value did the team deliver during the previous iteration.  In fact, I have only two primary measures for when it is time for me to stop coaching – does the team exhibit predictability by completing 90% or more of the work planned each sprint and is the Product Owner happy with the amount of work taken and quality of work delivered. Give me these two things and I don’t give a damn how you did it! However, if you are not giving me these things then you have opened the door to coaching on the inputs. Interestingly enough in order to achieve these pared down metrics most teams figure out what the proper inputs are without a top down mandate.

You can spend a great deal of time, money and effort checking endless inputs or just measure a few highly critical outputs. The choice to me is clear. Stop concentrating on inputs as primary measure and concentrate on the few critical outputs.

Individuals, Teams, Systems – The Evolution of Agile at Scale

building for scaling agile blog 2

If you have any interest at all in agile, if you read agile blogs, if you follow agile trends, you most certainly have been (over) exposed to one phrase “scaled agile.” I, myself, recently received a certification for one of the new scaled agile programs. While I enjoyed the training I find myself not 100% convinced of its effectiveness.

Perhaps it is because of its very novelty that I remain skeptical.  Perhaps it is because I know front line people in companies referenced as successfully adopting who do not agree to the efficacy.  Perhaps it is because “scaling ” has simply become the latest excuse from management why agile cannot be adopted at their company (as in why should we bother when agile has not been Provence to scale).  In the end though I think the reason that I am lukewarm on the idea is because companies have been latching on to scaling before doing the initial groundwork.  in other words, scaling has become a red herring that induces companies to put the cart before the horse or the system before the team.

Once upon a time I coached one of the most amazing agile scrum teams. They were able to deliver things that their management found quite unbelievable so much so that they conveyed a meeting to find answers to why this particular group of people were able to so greatly outperform others in the organization. As an aside I was not originally invited to the meeting but the team lobbies for me to be there as they considered me one of the team and, as a team member, partially responsible for their success.

I remember very well one manager in particular gushing about the team performance and wondering aloud how such a miraculous feat could be “scaled.” “It is very much like the legends of people working together out of their garages,” the manager said, “but how can such a thing” he paused briefly to allow the group to understand what came next would be important, “be scaled?”

Before I realized that the question was merely a rhetorical one to introduce us to the new management buzzword “scaling”, I opened my mouth to answer. “Why we just create more garages,” I said. The answer, which I still stand by to this day, was roundly ignored by aforementioned manager and his manager reports and was about as welcome as a tart in a crowded elevator.  What I realized too late was that “scaling” was management’s way of avoiding any action, especially action that might involve hard work and opposition.

So, you might say, scaled agile to the rescue. Not so fast my friend. My amusing anecdote above was all about creating good teams (and creating more good teams). Agile at scale is about creating a good overall system. There is no need to scale agile until you have enough teams doing agile.

Here is the way I like to explain the evolution to scaled agile. Waterfall is inefficient because it tries to optimize individuals at the expense of teams. Good teams have a higher productivity, shorter time to market, higher quality, etc than individuals.  Enter Scrum. Scrum, when done correctly, optimizes teams. This is a huge advance and if your agile evolution ended here, you would have come a very long way.  Nevertheless it frequently happens that we cam optimize teams at the expense of the system. Once we reach this point it is appropriate to look at ” scaling” and how we can optimize the entire system.

To recap – waterfall optimizes individuals at the expense of teams. Scrum optimizes teams at the expense of the system. Scaling is the attempt to optimize the system. My experience (and it may be biased because like Freud I work mainly with the “sick”) is that companies abuse scaling because they either use it as a means to avoid agile or they rush to scaling without first making the tremendously difficult transition to creating effective scrum teams. My advice remains “build more garages.”