by Tom Mellor, CST (Part 1 of 2)
The company from which I retired in 2013 has hitched onto the (un)SAFe train (not to be confused with the release train), and I am hearing from lots of people in the organization about it. I have lots of concerns with SAFe, but my primary one is that it moves focus from teams, and the people on them, to management, especially in a hierarchal, top-down command sense. It perpetuates the very problems that we in the broad agile community have sought to resolve over the years!
In short, it gives man
agement the excuse to perpetuate outdated structures, strategies and tactics, and institute a heavyweight process framework that presents a façade of agile. It focuses strictly on “doing agile” rather than “being agile.” It also furthers the arguments put forth by Agile Manifesto signatory Dave Thomas in his blog post Agile is Dead (Long Live Agility) http://pragdave.me/blog/2014/03/04/time-to-kill-agile/. Bob Galen’s concerns reflect mine: http://bit.ly/1bCafF7.
I introduced Scrum into my former organization in 2004 where we first used it clandestinely on a project to bring Health Savings Account marketing and operations capability into the company. We had to accomplish this in 90 days, and we had to work with a vendor (who didn’t have a clue what Scrum was). A rather irreverent line from the business had caused me to want to tackle this work by trying a new approach I had read about in a software development publication written by Scrum co-creator Ken Schwaber. I was intrigued by its simplicity, so I emailed Schwaber.
I joke in my Scrum workshops that when I contacted Ken Schwaber about trying out Scrum at this behemoth company, he thought I was either the craziest or the stupidest person he had met who wanted to give Scrum a go. I am not sure which side of the coin I fell on, but I do know that we defied expectations and delivered the product in the time demanded. We did it using a small team that worked in 2 week Sprints while I got corporate BS and process crap out of the way so we could deliver.
We used Scrum without any formal training. Schwaber had invited me to attend a CSM workshop in Chicago in February 2004 (one of the early ones, if not the first one), but I told him I couldn’t go because we had to start the HSA project. “Any advice?” I asked him. “Yeah. Read the book I wrote with Mike Beedle (Agile Software Development with Scrum 2001 Pearson) and follow it. Then let me know how it goes.” So it went, and we delivered that product within the 90 days. I got a “medal,” or at least a congratulatory letter, from the CEO of the bank division of our financial services company. The VP of Finance, a fellow named Jack, who oversaw the bank division, wondered how we did it. “We used Scrum – a lightweight framework that allows us to pivot and react quickly. We were Agile.”
“Well,” Jack said, “can you use Scum [sic] on a big thing?”
“It’s Scrum. How big?” I asked.
“Big – a complete rewrite of our mortgage system.”
“When does it need to be finished?” I asked.
“8 months from now – by the end of the year.”
“How long did it take to produce the existing system?”
“Two and a half years.” Jack looked at me with that you-will-tell-me-yes look that executives knowingly give.
“This isn’t magic, Jack. We cut out a lot of bureaucracy and process crap in this HSA work. We won’t be able to do that in a large project, especially one that involves intensive government regulation.”
“Give it a try. We’ll support you in getting that ‘process crap’ out of your way.”
“Ok, but no promises.”
“Think as Yoda: ‘Do or do not. There is no try.”
We didn’t deliver in 8 months, we delivered in 9. We developed a simple interim solution that can seemingly only come about when a real team collaborates constantly. But, the success of the mortgage system project unleashed a torrent of interest, and soon my surreptitious activities were unmasked.
I didn’t wish to foment organizational change. My purpose was selfish: improve the odds that we would deliver a better product faster. I had plenty of skeptics, but none of those people were on my teams using Scrum. So, soon the whole IT department was abuzz with this newfangled approach. Before you knew it, we had a couple dozen coaches in place and an “agile enablement” unit up and running. And, Agile was getting sucked into the Hairball[i].
Tom & Family
Tom Mellor has been actively involved in business and IT for over 36 years. A seasoned professional, he has worked in both large and small companies serving in a multitude of capacities and functions. With a rich history in Agile, Tom is passionate about the adoption and use of agile-based product development approaches and in 2004 introduced Agile and Scrum framework into a Fortune 50 company. Tom has been a Certified Scrum Trainer since 2008 and served on the Scrum Alliance Board of Directors from March 2008 through October 2010 including a term as chair from September 2009 until October 2010. Purpose driven work for Tom means helping organizations, their leaders, and their teams do modern Agile-based product development processes effectively and he helps them do this through consultation, training and coaching.
[i] Intricate patterns of behavior have created a Gordian Knot of Corporate Normalcy (conformity with the corporate mindset)…This is the Hairball….and the nature of Corporate Gravity is to suck everything into the Hairball, which is derived from and dedicated to the past. There is little room in the Hairball for original thinking or creativity. To orbit the Hairball is to find balance and joy without becoming entombed in the bureaucracy. You can achieve orbit by finding the courage to be genuine, to look for and promote the finding of better ways rather than following the pallid path of corporate conformity. It is risky, but rewarding. – Orbiting the Giant Hairball; A Corporate Fool’s Guide to Surviving with Grace by Gordon MacKenzie (Viking 1998)
