Cooks, Chefs and Agile Scaling Models

Chef Photo

Chef Photo     A few years back my doctor gave me some somber news. He told me my cholesterol was too high and I must get it lower. It was then that I decided I would make changes to my less than stellar diet. At the time, we had a large family in the house – seven including my father and mother-in-law. My mother-in-law had become the default cook for the family and, while she made some very tasty dishes, it was not exactly healthy fare. I knew that if I were to reach my goal of a better diet I would have to become the new cook for the family.

Chef PhotoOriginally I thought that my mother-in-law would be upset if I banished her from the kitchen, but if she was, she did a good job of hiding it. That aside, there was only one more small problem – I had not the first clue about how to cook, let alone cook healthy. Obviously I needed help and what does someone do to find help these days? That’s right. I googled it. I found my salvation on a website that not only had thousands of recipes, but each had a rating and comments. I could print out a list of ingredients, create a shopping list, scale recipes to my large family. Most important, I could choose recipes by food type (in my case – healthy foods, low in sodium and cholesterol). Without the internet my plans to eat healthy would have died in infancy.

While I went into this quest as one who was not even a functional cook, I was able to read and follow directions well enough to create some very tasty dishes that the family enjoyed. The plan paid off. My cholesterol and blood pressure went down, as well as other family members including my mother and father-in-law. Over time I even became a functional cook. However, I never became a chef (and to this day I am still not).

Chef PhotoThe difference between a cook and a chef can be summed up in conversations I would have from time to time with my wife. She would ask, “Can you make this dish without this or that? Or maybe substitute this with this.” My response would always be the same. “Sorry honey. I wish I could help you, but I am not sure what this ingredient does and not sure what would happen if I don’t follow the directions to the letter.” I was a cook. What she was looking for was a chef; someone who had a deep culinary knowledge that would allow them to not only modify recipes, but someone with the ability to create new dishes from scratch or show creativity with existing ingredients. I could not do this. I got very good at the motions and following a recipe, but I never cultured a deeper understanding of the why behind the individuals ingredients and actions. I could not “see the big picture.”

Chef PhotoI am often reminded of the difference between a cook and a chef in my agile practice. I have used this story numerous times with developers to explain agile development practices. Like me, it seems that some developers will always be cooks. While there are some who don’t know the difference, I have even run into some that prefer to be cooks instead of chefs. Not that there is anything wrong with choosing to be a cook, but it helps when one is aware of the choice and makes a conscious decision to be one.

I was reminded of this again recently when I went to a talk on scaling agile. The presentation was supposed to last about an hour, but ran long because of the numerous questions and comments from the crowd. It wasn’t until the following day when I was explaining the presentation to a group I was coaching that I realized why the presentation was peculiarly long. The crowd at the presentation were novices with respect to this scaling model and the questions they asked were ones that we would expect cooks to ask. They wanted to know a prescriptive recipe for scaling and wondered how it could be applied to their unique circumstances. Without having the deeper knowledge of a chef, the scaling model recipe didn’t make a great deal of sense to the crowd.

Chef PhotoOf course, this phenomenon has been observed and named the Dreyfus Model of Skills Acquisition. In this model, “cooks” could best be mapped to the “Novice”, “Advanced Beginner” and maybe even the “Competent” categories while “chefs” are referred to by the name of “Proficient” and “Expert”. The Dreyfus Model helps us understand one of the biggest problems facing Agile scaling models today. The scaling models I have some experience with present the world with software development recipes. Unfortunately, the majority of individuals being presented these recipes are cooks (“novices”) and not chefs (“experts”). While one can function adequately as a cook by merely following directions, software development is much too complex. People trying to do Agile scaling are too new to scaling concepts to make successful adaptations should their “ingredients” not match exactly with the Agile scaling “recipe”.

There are a number of Agile scaling models including SAFe, LESS, Nexus, DAD. Since there appears to be quite a bit of money in creating scaling recipes, training people on the recipes and certifying that people have been given and understand the recipes, I expect to see many more in the coming years. Each scaling model claims to have many companies successful in using their model. I am dubious because I have seen overlap among the companies claimed to be successes with the different scaling models (“the usual cast of characters” a person said to me once). I would guess the companies where success is claimed are merely the ones where people paid for the training and certification. What actually happens vis-à-vis scaling models is probably far from what the proponents claim. I expect over time many of these scaling models will be spectacularly unsuccessful. It may be the luminaries of agile have created the perfect scaling “recipe”, but there are too many cooks and not enough chefs for lasting success.

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

Despair

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.

The 3Ps of Agile Software Development

einstein

I am often faced with explaining the various aspects of Agile to people new to Agile and I have come up with a very simple way to remember (and explain) Agile. I present to you now the “3Ps of Agile Software Development” with the hope you find this useful to your own understanding and an aid in your ability to explain Agile to others.

Philosophy

“The world as we have created it is a process of our thinking. It cannot be changed without changing our thinking.” – Albert Einstein

einsteinAt the core of Agile is the Manifesto. A few years back, I even took the time to create business cards that contained the four values and twelve principles. When I heard people say that this is or is not Agile, I could hand them a card and say, “This is Agile.” This is where I start in explaining (and training) Agile because without the philosophical underpinnings one is most certainly lost. I couldn’t give an exact number, but I do know that a high percentage of companies trying to move to Agile are unable to fully embrace and promote the philosophy behind Agile. I wrote my first book, Understanding The Agile Manifesto: A Brief & Bold Guide to Agile, because I have witnessed firsthand the struggle companies are having with adopting the Agile Manifesto. I have seen companies rewrite the Manifesto to omit or change things that they find too difficult to embody and watched good people punished for having the temerity to post the Manifesto at their workplace. The philosophy is the base upon which the other two Ps rest.

Process

“This strange dichotomy, this agonising gulf between the ought and the is, represents the tragic theme of man’s earthly pilgrimage.” – Martin Luther King

martin luther king jr.It is not enough to have the basic philosophical understanding of Agile, we must find ways to embody the principles. There have been a number of ways to embody this philosophy over the years. Take for example, Scrum. Technically it is a framework, but it contains ceremonies (actions) that allow us to realize the Agile philosophy. Why do we do retrospectives? Because the last of the Agile principles state, “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” While Scrum has claimed a high level of mindshare, there are numerous other processes and frameworks that also help organizations embody the philosophy of Agile (Kanban, DSDM, Crystal, etc.). In fact, Agile’s history is one of empiricism with people “uncovering better ways of developing software by doing it.” This means it was actually Process (and the 3rd P) which came first. It is Agile Processes that help us to realize the philosophy of Agile.

Practices

“Practice does not make perfect. Only perfect practice makes perfect.” – Vince Lombardi

lombardiSometimes when we classify things, people can certainly disagree with our classifications, but when I explain the term “Practices” I am referring specifically to software development practices that are done within the processes and frameworks. It is into this category that I would put things like Extreme Programming (XP) practices as well as something like BDD. What separates these things (which could be argued to be processes) is there more technical nature and the needed expertise of software development professionals (developers and QA) to implement. Processes are things that embody the Agile philosophy which any intelligent individual could understand and facilitate. For example, though it might be optimal for a scrum master to have a development background, one could be successful as a scrum master without it. On the other hand, one could not be successful in performing code review or test driven design (TDD) without knowledge of coding. Why do agilests do BDD? Because through BDD we can realize (among others) the principle that states, “Business people and developers must work together daily throughout the project”. It is Agile software development practices which also help us to realize the underlying Agile philosophy.

While any system of classification subject to interpretation, I have found that speaking to the 3Ps of Agile Software Development has provided a simple and understandable way to introduce people to Agile. If you get a chance to present this, please let me know if it helps you as well.

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.

Wagerfall

wagerfall certification

happy new yearThe end of the year is upon us and, like most, I have begun to reflect on the year that was 2015. It was a great year for me both personally and professionally. Earlier this year I was given the opportunity of a lifetime to help build an Agile practice and continue my work as an Agile coach. As I looked back on 2015 I could not help but notice the really big news in the world of Agile was the concept of scaling. There has been a proliferation of scaling frameworks. Time will tell which, if any, will be beneficial, but it did get me to wondering if maybe there wasn’t room for just one more.

What follows is a satirical press release for the newest of Agile scaling frameworks. My purpose was not to offend or disparage, but to amuse. My apologies if I missed the mark. I wish you all a happy and prosperous new year!


“Wagerfall” – A New Way to Scale Agile

Agile Scaling Society announced today a new framework for scaling Agile called “Wagerfall”. This new lightweight framework trumps all others in an increasingly crowded field for the ease of its implementation.

NEW YORK, NEW YORK (PR FILE) DECEMBER 30, 2015

You might be familiar with Agile scaling frameworks like SAFe, DAD, LeSS and the like and today a new scaling framework has joined the list, Wagerfall. Wagerfall is the brainchild of Steven Anderson of the Agile Scaling Society. According to Anderson, Wagerfall is different in that it represents the easiest of all the scaling frameworks.

“The beauty of Wagerfall is in its simplicity. The framework is nothing more than the name Wagerfall because the name explains it all. You start with your current waterfall and sprinkle in a little agile somewhere in the middle. The “g” in the middle is for represents the Agile part,” asserts Anderson. When asked why not the “ag” for agile, Anderson mumbled something about it not being mandatory and holy wars.

wagerfall certificationThe announcement today also coincided with another press release detailing Wagerfall certification. In the spirit of lean and reduction of waste, the Agile Scaling Society has done away with any mandatory training or testing to get certification. “Why go to the trouble of pulling someone out of their job for two days?,” asks Anderson. “Send us your money and we will send you a lovely (and very fancy) certificate you can hang on your wall and you too can say that you are Wagerfall certified. Doesn’t it make sense if your company is not going to change anyway?” When asked why certification cost so much, Anderson replied, “science has taught us the more money we invest in something, the more value we place on it.”

There are already a great number of clients joining the ranks of Wagerfall. Donald Love, CIO of Great Big Company, credits Anderson and Wagerfall for their successful Agile transformation. “I can’t tell you how refreshing it was to work with Wagerfall. We transitioned to Agile immediately without the messy process of organization change, with all the training and thinking that comes with it. I can now check this one off my list and get my big fat bonus.”

It is not just the C-suite that has fallen in love with Wagerfall; the frontline workers have embraced it as well. Vijay Patel, a software developer, credits Wagerfall with allowing him to go about his business as he always done. “We’ve tried other Agile transitions, and I believed in them. I put myself out there and honestly tried to change. When the truth surfaced and us developers found out it was just lip service, we were crushed. Our morale is still low under Wagerfall, but we know Wagerfall is just lip service, so we got that going for us.”

In addition to the framework and the certifications, Anderson has a cadre of Wagerfall coaches. Anderson states, “The problem with most Agile coaches is that they are either not competent or too earnest. Wagerfall deals with these two problems head on. Since there is no recognizable change, competency is not an issue. Furthermore, our coaches provide a patina of credibility without pestering people to change their existing behavior. We often refer to what we do as ‘homeopathic agile.’”

While other scaling frameworks have detailed flowcharts, organizational structure documents, etc., Wagerfall avoids such complexities. Mindy Minter, Head Architect at Great Big Company, praises Wagerfall for its simplicity. “We are big believers in the KISS principle. You can’t get more KISS than Wagerfall. Pay your fee. Get your certification. Claim you’re Agile.”

waterfallAccording to Anderson, perhaps the most valuable aspect of Wagerfall is in the ability to roll back should the transition not work out as planned. “Just imagine, run a global search and replace on all your process documentation. Voilà. Wagerfall is turned back to Waterfall and you can go about your business as if nothing ever changed.”

About Agile Scaling Society

The Agile Scaling Society, headquartered in New York (to give it legitimacy), was founded on the belief that most companies want to be Agile without the hard work of actually changing their culture, philosophy or business processes. They provide certifications, training and coaching to allow companies to claim to be Agile while operating exactly as they always have. They claim that literally hundreds of major companies are currently following the Wagerfall framework and are in litigation with many of them for infringing on their trademarked Wagerfall process.

About Steven Anderson

Steven Anderson has been described as a “jack of all trades” with experience in selling homeopathic medicine, street preaching and HVAC. While new to Agile, he recognized the opportunity to make money and has embraced it. He once owned a PC and wrote some excel macros. He has parlayed this experience into a successful consulting company and has recently founded the Agile Scaling Society.

 

On Death and Dying and Agile Transformation

death and dying

I was recently involved with a large scale Agile transformation and noticed what I thought was an interesting correlation, jotted down a note to blog about it and then promptly did nothing for a very long time. Usually these blinding flashes of light quickly lose their luster and find themselves relegated to the bottom of the blog backlog, never seeing the light of day, but this particular one reignited my attention as I sat down to write my newest blog.

ideaMy earth-shattering insight was that any organizational transformation, which obviously includes an Agile transformation, involves the very same stages that were first identified by Swiss psychiatrist Elisabeth Kübler-Ross in her 1969 book, On Death and Dying. For those who were sleeping through Psych 101, Kübler-Ross proposed that there are a series of stages that are experienced by survivors when faced with the death of a close friend or relative. These stages could be experienced linearly but also in no particular order, but that everyone would go through the five stages she recognized through her work with terminally ill patients.

The five stages are: Denial, Anger, Bargaining, Depression, and Acceptance. Though the model was originally created to explain the stages of grief following the death of a loved one, it was later expanded to encompass the grief stages associated with any major loss like the loss of a job or income or divorce / end of a relationship. It is my opinion that these stages can also be applied to the loss of a treasured idea. In fact, I think these stages are better explained by the death (loss) of a cherished idea since love, attachment, etc. are all associated with mental constructs (ideas). Our world is merely the sum of our mental perception so the loss of a loved one, loss of a job, or loss of a relationship are nothing more than the loss of an idea.

Once we understand that the grief stages are in response to the loss of an idea, it is not a great leap to apply this to any company transformation. It is well known that there are some who will readily embrace change, but there are a great number that see any change as a threat. What is the nature of the threat? I think that either consciously, or more often subconsciously, the threat is to an idea that one has grown to “love” and that there is a very real fear that if this idea were replaced that its death would cause grief. In my experience with a great number of agile transformations I do tend to see the five stages that Kübler-Ross outlined.

sadnessThere is certainly a large share of denial when I have tried to help companies become more agile. There is never a shortage of people who will defend the status quo and insist that the current way of creating software (nearly always waterfall) is already successful and that there is no need to bring agile. The minds of the people in denial are closed to any external threat to their enshrined beliefs.

I also see a great deal of anger during transformations. People have loved their ideas for so long that they are like a member of the family. How dare you agile folks try to kill off my favorite processes? I will do everything in my power to try to stop you, railing at the purveyors of such dangerous ideas.

I see my share of bargaining too. If we cannot outright defeat the new ways, we can at least try to keep as many of the old ways intact. Maybe we don’t have to kill off all the waterfall phases. Maybe we can keep the phases, but just do them in shorter time frames. Maybe we can just do this “agile” thing for development and leave the rest of the sacred cows not slaughtered. I don’t have to give up my old way of thinking or deal with the death of my ideas, is there not room for both?

As new ideas begin to take hold, I have also seen my share of depression. People have viewed the world in one way for so long that once their ideas are shown to be outdated or not optimal, they begin to look forlorn and some even begin to despair. With waterfall gone, how am I to complete a software development project?

handshakeAnd finally, if the company has the intestinal fortitude to stick it out through the first four stages, you will finally get to acceptance. No with your new idea having taken hold, it probably won’t be long before you will have to go through it all again with another new idea. I think the more that we realize that changes our ideas result in the death of old ideas and that the death of old ideas will result in some recognizable stages the more we will be able to quickly move through those stages and adopt new ideas more readily.

Postscript: Interestingly enough, when I had just finished the above blog, I did some research to see if I had written on this subject before because it had seemed eerily familiar. I could find no blog that I had published on the subject, but I may have written about it before and not published. What my research did find was that I am not alone in my link between the Kübler-Ross model and Agile. I have found other references to this on Mindstorm, and Agile Helpline. While I do not recall reading these blogs prior to my current blog and it is possible that we have all come to the same insight independently, I reference these here just in case I did read them at some point and perhaps forgot. Regardless, the fact there are others who have written about the very same topic leads me to believe in the concept’s applicability.

Post Postscript: This blog represents my 100th blog post under the agile-doctor.com website. While this is mostly symbolic and my 100th blog post will not guarantee me syndication (like a sitcom), it is still a moment to celebrate. Many thanks to everyone who has given support over the years! Stay agile my friends!