My ELITE Stumble

“Cool! It’s just what we asked for, but not what we want now.”

– Anonymous

Several years back, I was involved in a project to create a custom version of a mainstream stock trading application for a small set of hyperactive traders who executed hundreds – sometimes thousands – of trades every day, and generated quite a bit of commission revenue. We dubbed this version “ELITE”, and put a couple of bright developers to work on it. This was our SWAT team.

The idea went like this: by implementing the advanced features hyperactive traders wanted in a custom version of the application, we can release these features quickly and with little concern for adoption by mainstream traders. What was even more enticing about this approach is that once one of those features was thoroughly vetted by those fastidious traders and had shown to be applicable to the general population, all we had to do was comment out a few #ifdef’s and voila! Every customer had access to this feature.

By any account, the ELITE version was a runaway success! We were responding to those customers quickly and adapting the software to their unique needs. They were trading like crazy and racking up commissions.

In terms of execution, we had little or no documentation to rely on – sometimes just a sketch and some handwritten notes. We sat down together, the business analyst and me, and tinkered with the wireframe until we were happy with it. Then the developers built it and showed to him, and then we would adjust it and repeat the cycle a few times. When we were satisfied we had it right, we made a build, sent it to QA, and a week or two later, the ELITE traders had their precious feature.

What was remarkable about this is the fact that at that time we were still a couple of years away from implementing an Agile approach in any of our projects. We literally stumbled upon a working Agile model, and executed it inside of a Waterfall system. In fact, while these ELITE features were being added to the code base, the mainstream projects were trudging along, business as usual. For every mainstream release, we would release 3-4 ELITE releases. This may not seem like a lot, but for that product, in that timeframe, in that environment, it was indeed a miracle.

Years later, as I reflected on that period, I realized how forward thinking we were, some would say lucky, in adopting a model that was Agile at its core if not in the skin on the outside. True, we didn’t have daily standups or retrospectives, nor a burndown chart or a story board. What we did have is the essence of what Agile is all about: we were sitting down to discuss and design the features, building a working model for the customer to validate, and making incremental changes based on the feedback.

These days, with Agile practices as commonplace as happy hours are, I worry that we might be losing the essence of that Agile experience, namely quickly responding to change and constantly iterating based on customer feedback. There is incessant noise about Agile artifacts and ceremonies cluttering our conversations. Unless we keep the essence of the Agile experience front and center as our guide, and measure every decision we make and every direction we take with that ruler, we risk creating an environment as rigid and unforgiving as Waterfall was. We especially have to be cognizant of traditional boundaries between technology and business getting slowly reintroduced. So stand up, leave your desk, and walk over to the other side of the building. You’d be surprised how a long email chain can be cut short with a 10 minute conversation.

Agile-Waterfall, is that an oximoron?

I was reading a blog post the other day with the provocative title “Agile is a Fad”, and it occurred to me that as Agile practices become widespread and almost ubiquitous, and as some company executives feel the pressure to hastily adopt Agile at any cost, a predictable backlash will ensue, especially when these organizations struggle with Agile introduction and adoption. This backlash will not only come from the leaders of these organizations, but also from Agile purists who foresee the Agile movement being corrupted by companies wanting a quick cure, and a cadre of consultants willing to sell them the magic pill.

So it comes as no surprise that some organizations are getting to a point in their adoption of Agile where they are questioning its usefulness and value. Some are even reverting to Waterfall after "failed" experiments with Agile.

Why is this happening? Agile was supposed to be the answer to all their past woes with timely delivery, customer acceptance, and quality. Yet, Agile becomes a battle of wills between the folks who championed it and those who simply wanted things done. At some point, failure to deliver a product on time leads the non-champions to the conclusion Agile methodology is to blame.

In reality, the problem has deeper roots. It originates with the reason these companies adopted Agile in the first place. Often, the product side of the house wants Agile so that:

a) they don't have to write extensive requirements upfront,
b) they can change their mind up to the point a product ships, or
c) they want to know what's going on inside of the software development black box.

On the other side, the technology side of the house often pushes to adopt Agile so that:

a) they can start designing and coding right away,

b) they don't have to sit through laborious requirements review meetings, or
c) they can show off their handy work early and often.

The fact is, Agile facilitates and supports many of these desires by both sides. Yet, a lack of understanding of the fundamental goal of Agile dooms the experiment to failure in many companies before or soon after it starts. Everyone becomes so focused on the ingredients and steps of the recipe they forget what they were cooking in the first place!

So what is the fundamental goal of Agile? The Agile Manifesto talks about 4 key principles that are highly valued:

-          Individuals and interactions over processes and tools

-          Working software over comprehensive documentation

-          Customer collaboration over contract negotiation

-          Responding to change over following a plan.

Yet, what do these principles help with ultimately? What is the key benefit of using Agile in software development? The answer is:

Facilitating Change that Adds Value at the Lowest Possible Cost.

Think about it... Your work as a software professional starts out with a feature request, enhancement, or bug, i.e. some kind of a change to the product. Everything that follows are steps to facilitate that change, whether you follow a Waterfall or an Agile approach. Yet, where Waterfall comes up short is on the questions of Value and Cost. Every feature that the customer doesn't use is a zero value change. Every delay in delivering to the customer is a higher cost change. A 100% successful Agile implementation is one where every feature added meets a customer need in a timely fashion and is built in the most efficient and cost effective manner.

A fundamental understanding by executive management, key stakeholders, and team members of what Agile is all about is the key to success in implementing Agile in any organization. The artifacts of Scrum, XP or Kanban are there to facilitate change, add value and reduce cost. If your organizations wants to use an incremental Scrum process (some call it Agile Waterfall) that works more seamlessly with organizational boundaries, go for it. If your organization wants to run one team with Scrum and another with Kanban because of the unique qualities of the products and customers serviced by these teams, why not. As long as you can demonstrate "with actual hard metrics" that you are facilitating requested changes that ALWAYS add value at the lowest possible cost, your version of Agile will more than likely be a success.