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.

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.

 

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.”