Blog - 5/16 - Agile Doctor

30 December, 201531 December, 2015

Wagerfall

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

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

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

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Android | RSS

16 November, 2015

On Death and Dying and Agile Transformation

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.

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

There 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?

And 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!

9 November, 2015

The VW Scandal as a Cautionary Tale – Cultivating Fear Always Ends Badly

For those who might have been taking a long vacation from reality, Volkswagen recently became embroiled in a scandal regarding some of its cars with diesel engines. It seems that when these cars where tested for emissions, a “defeat device” (a software program), would detect that the cars were being tested and change the performance accordingly. This led to claims that their diesel cars were better for the environment than their competitors. In all there appears that over 500,000 of these “clean diesel” cars are currently on the road, mostly in the United States.

Shortly after this scandal broke, the finger pointing began. Under pressure from a United States House of Representatives Oversight and Investigations panel, Michael Horn, Volkswagen’s United States Head, stated, “This was a couple of software engineers who put this in for whatever reason.” While I find it very disingenuous and slimy to through your software developers “under the bus”, albeit one with flowers and the smell of Patchouli oil, the question that remains, assuming Horn was not involved, is why would these “rogue” developers decide to create something like a “defeat device” in the first place?

When I first heard of the “rogue” developer explanation, I realized there are two possible reasons – the developers do not care about their work or the developers acted out of fear for their jobs (or both). In either case the root cause is that there is a culture that discourages employee disengagement and fear. This means that while Mr. Horn might be accurate that it was “rogue” developers who are responsible for the act of creating the malicious software, the responsibility for corporate culture rests squarely with leadership. Since Horn was the top leader then he bears the brunt of the responsibility for the culture that would allow/coerce developers to make such a disastrous decision, one that could cost VW billions.

That is not to say that the developers who made the changes should be held blameless, but it is not unusual for corporate culture to treat developers more like minions than the professionals that they are, shielding them from making decisions we would expect respected professionals to make. Fear for their very jobs, while puzzling in an environment where good developers can pick and choose, was most likely the final calculation that allowed the developers to write this malicious code. And not only developers, but where was the Quality Assurance during this process? Again, it is poor culture that allows such misdeeds to flourish.

My educated guess received some support in a recent column in Road and Track by Bob Lutz, a former Genera Motors executive. Lutz placed the blame for the recent scandal directly on the shoulders of ex-Chairman Ferdinand Piech. Lutz stated that Piech’s tenure was distinguished by a style of leadership which was “a reign of terror and a culture where performance was driven by fear and intimidation.” Lutz described one exchange with Piech regarding the body fits of the new VW Golf where Piech bragged about his “recipe” for better body fits.

“I called all the body engineers, stamping people, manufacturing, and executives into my conference room. And I said, ‘I am tired of all these lousy body fits. You have six weeks to achieve world-class body fits. I have all your names. If we do not have good body fits in six weeks, I will replace all of you. Thank you for your time today.”

While this leadership style might work from time to time, it is motivational junk food. It creates a toxic culture where the long-term effects will one day negatively manifest themselves, in this case, with “defeat devices.”

Studies have shown that only about 30% of US workers are engaged in their work. That fact, along with dozens of years of experience, have led me to believe a huge percentage of companies use fear as their primary means of motivation. My advice to leaders is to pay attention to the VW scandal and heed its warning. You will most certainly reap what you sow, karma will catch up with you and cultivating fear will always end badly.

19 October, 2015

Stop the Sprint Slop and Shot Your Zombie Stories in the Head

One of my loyal supporters last week requested I write an article about “sprint slop” and I am very happy to accommodate any requests. Before I could begin it was important that to understand the request because this particular term is not ubiquitous. A Google search for “sprint slop” returned few links and those returned were associated with skiing and not Agile or Scrum. Nevertheless, I had a good idea of what was meant by the term “sprint slop” and was able to isolate the meaning to refer to those stories that move from sprint to sprint and are not completed. I have also referred to such stories in my agile coaching practice as “zombie stories” since the never seem to “die”.

“Zombie stories” are a great indicator of team maturity, the origin of which is mostly related to either stories that are too large, poorly written and poorly refined or teams that are pressured to plan more in a sprint than is possible or are victims of “false” dependencies. In most cases, the root cause of the above is related to poor understanding of Agile Scrum from the business, particularly in relation to expectations of the product owner and the amount of time that is necessary to devote to the processes associated with the scrum framework.

The scrum framework consists of ceremonies for each sprint – daily standup, planning, review, retrospective and refinement (new term – originally referred to as grooming), which can be broken into backlog refinement and story refinement. If we were to look at the time that is necessary for all of the these ceremonies for a two week sprint (which seems to be the most popular timeframe), we would have something similar to the table below, with the total time between 9.5 and roughly 12 hours:

Ceremony	Time (in Minutes)
Daily Standup	150
Planning	60
Review	60
Retrospective	60
Refinement	240 – 400
TOTAL	570 – 730

Refinement of the backlog (and stories) for future iterations is estimated to be between 5 and 10 percent of the current sprint. It is during this time that we gain a greater understanding of the work that we are going to do in the future. In my agile coaching I break the refinement into backlog refinement and story refinement. Backlog refinement consists primarily in story identification, effort and value estimation, and sequencing of the stories – basically understanding the work that will be done in the next iteration. This happens as the beginning of the sprint in anticipation of the future sprint. The story refinement happens after the sequence of the stories is understood and consists of a deeper dive into the stories, one at a time in backlog order, generating a good story description (As a..Iwant..So that), generally understood acceptance criteria (my teams use BDD) and preliminary implementation tasks and estimates that are used for Sprint Planning ceremony.

When I have witnessed “zombie stories” and “sprint slop” it has been generally the teams inability to take the proper amount of time to refine the stories for future work and by not using tasks and hours to better understand the implementation of the stories. I know my particular way may be somewhat controversial since the trend these days is to not do estimates, either for tasks or stories, but in my experience the ability for teams to become predictive (ie complete 90% or greater of planned work) is something for mature teams and tasks and hours are a necessary step to help the team truly understand what they are capable of accomplishing. The detail work forces the team to consider how they will implement and will give the team more information on the true size of stories and places they might be able to break the story into smaller pieces.

In some cases, where the detailed work is done and the team still is unable to complete high percentages of the work, then the problem can be related to pressure from the business. Sprint Planning should be based in reality, but when timeline expectations are placed on a team, their natural inclination is no longer to make estimates and predictions based on their best understanding of the work, but based on the expectations of how much work “needs” to be completed.

The last reason I see for work moving from sprint to sprint is dependencies. Again, this is more an indicator of maturity level and an inability to write proper stories, than actual “hard-stop” dependencies. A “hard-stop” dependency is one where no work can be accomplished unless some other work is completed first. In software development I usually find that these are the more hardware-dependent stories. It is really difficult to deliver working software if I do not have the servers with which to deliver the software to.

However, my experience has taught me that most of the stories teams think are dependencies are, in many cases, not. These I call false dependencies and proper utilization of an INVEST acronym in writing stories will go a along way to breaking these “false” dependencies. For example, if there are two different team working on the same feature, one that is doing the backend services and one that is doing the front end UI work, then there appears to be a dependency of one team waiting for output from another team. This is a “false” dependency. There are two ways to address this issue. First, I can change the teams so that they follow the guidance that all members necessary for software functionality are on one team. Second, I can create three different stories that would allow the teams to operate somewhat independently – one for the service mocking the front end, one for the front end mocking the service and one for integrating the two stories. While not ideal, it allows for much quicker feedback on the work and allows the teams to schedule a chunk of work that they can accomplish in a single sprint. This can even work sometimes with hardware dependencies. I currently have a team that did their integration locally to a laptop while they waited for the real hardware to be delivered. Again, no optimal, but it did represent a way for the team to deliver into an environment that allowed for faster feedback and it is particularly this feedback that is missing from “sprint slop” and “zombie stories.”

One word of caution about team commitment and expectations. When I received my CSM training all those many years ago, I was taught that every story (100% of the work) should be completed by the end of each sprint. I remember the instructor saying something about developers “chopping off their arms” and “banging them on the keyboard” if it was necessary to get the work done. I did then, and still do not, believe that this is what is meant by commitment and have railed against the 100% expectation ever since. As with all things in life there is the ideal and the acceptable. My three boys are all still in various years in school, but my expectation from all is that they try their best to get 100% on every test, but I find that 90% or greater (an “A” these days) is acceptable. I preach the same with my scrum teams. Of course, we plan each sprint so that we can complete 100% of our work, but I find that 90% or greater on a consistent basis is acceptable because it shows maturity in planning and predictability in implementation so that longer term planning is possible.

The thing to always keep in mind is that Scrum is a framework that will shine a light on those things in your current environment and system that are not optimal. Scrum also gives you the framework to continually improve and solve underlying issues. “Sprint slop” and “zombie stories” are merely another example of the systemic symptoms Scrum will shine a light on. If you follow the framework properly it will also give you the ability to fix the underlying system so that you can be “sprint slop” and “zombie” free.

23 April, 20154 May, 2015

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

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

30 March, 201523 April, 2015

The Theory of Change & Why I Get In Trouble

organizational antibodies, agile, stock photo

As an agile coach that has been fortunate to work at a good number of clients over the years, you get an opportunity to experience some interesting similarities among clients. Some are tragic, some are funny and some are just downright intriguing. I recently spoke with another agile coach and I discovered one particular pattern that I have decided to refer to as organizational antibodies.

The talk in question was about the on boarding of coaches and things a coach tends to experience in the first few days on the ion. As we talked together and related our war stories I noticed that both of us had a something happen to both of us early in our engagements with companies. That common denominator was that both of us found ourselves in trouble with management in the new company within the first week or two of our gigs with our coaching ability or competence questioned or tested.

To hear that others shared my knack for getting into hot water early on was a relief to me. Of course, all of these early issues were resolved in short order, but it brought up a very interesting question of why this happened so frequently. As I look back on my personal experiences and after hearing the same from my colleague, a theory began to form in my mind. The end result is my Organizational Antibody Theory of Change.

The theory is this – there are many in any company who benefit from the status quo. Agile is about organizational change and those who prefer the status quo will find the agent of change as a threat to the corpus organizationus and will do their best to protect their system by attacking the agent of change. In other words, there are people in your company that perform the same role that antibodies provide in the human body.

At this point in my career I fully expect to have at least one of these reactions in every gig I start within the first couple of weeks. In the past it was quite disconcerting for me but now that I have experienced it and expect it, I worry less. The problem is always a tempest in a teapot, a minor annoyance that will fade away as my role is better understood and people realize that I am not a threat. Have you ever experienced organizational antibodies before?