The Agile Practitioner: Balancing Change

When I got my scrum master certification training, I had the good fortune to be in a class led by Chet Hendrickson and Ron Jeffries, two original signatories to the agile manifesto. During the class, we did an exercise in continuous improvement. We were broken into groups of about six people per team. We were given a net bag full of ping pong balls and an empty net bag. The objective was to move the balls from on bag to the other. The only stipulation was that every team member had to touch every ball before it was placed into the receiving bag. The goal was to see how many balls the team could move in one minute.

In the first round, some teams literally picked out one ball from the originating bag and passed it down the line to the final person, who dropped it into the receiving bag. The teams that did this were moving in the 25-35 ball range. One or two teams had done more like 70-80 balls. They were moving two or three at a time.

In round two, everyone picked up on this, so everyone's numbers went up to around 100 balls. Then, Ron said that the record was all 350 balls in about 35 seconds. For a few teams, the light bulb came on. They, too, achieved a similar result to the record.

What did they do? Maybe you've guessed. Everyone made a funnel with their hands while the lead and trailing members used one hand to guide the balls out of the originating and into the receiving bag. In this manner, the balls literally poured through everyone's hands from one bag to the other.

Out of the Box

Obviously, the purpose of this exercise was to explore incremental versus major improvements. It's fun to be the Ron & Chet show; blowing into town, dropping big ideas, and then moving on to the next group of wet-behind-the-ears practitioners. In real life, at the organizations within which we work, big ideas don't come so cheap.

Whereas small changes fly below the radar, big ones usually meet with more resistance. Often, these types of changes require senior leadership approval. They may require cultural adaptations that not only require approval, but take time and sustained effort to implement.

This is not to say that all changes with big impact are difficult, but if you have been on your Agile journey for some time, hopefully, most of the low hanging fruit has already been picked. Teams that are using their retrospectives effectively will be identifying and tackling “issues,” starting with the biggest ones.

The real challenge comes when all of these big issues have been ameliorated. At this point, the team is functioning well. The current mode of operation is generally moving along without major hiccups. When an issue does arise, it is usually fairly minor and small adjustments are made to mitigate it. This is the time when people are most risk averse, because they have much to lose. Good teams will have enjoyed significant evolution to get to this point and the equilibrium feels very good.

Clayton M. Christensen coined the term “disruptive innovation” to describe the market effects of technological innovation. He was most interested in how the adoption process of new technologies impact business processes and force competitors to adapt. However, his work is also instructive as it relates to internal business processes that may not have direct market impact (although they are likely to have secondary impacts).

A Case in Point

Prior to the introduction of Agile practices, software development organizations used what has become known as the “waterfall” approach to project structure. First, analysts would study the business processes being automated. Working with designers, they would create a detailed specification for the final product. Upon approval of the specification, “coders” would begin writing the software. When they were done (big systems might be done in phases), the quality department would thoroughly test the system functionality and report issues back to the coders for repair. This back and forth test-repair cycle would continue until the quality department in conjunction with management decided that the quality was sufficient to release to the market.

Today, this process sounds archaic, but back then, good organizations would continually find ways to improve this process and some of them got very good at it. In fact, they were so good at it that they were likely the last to change when the Agile wave swept over the software development community.

For others, waterfall was not working so well. So, in 2001 when a group got together to see if they could disrupt the way software was developed, Agile was born. It borrowed heavily from the lean movement being popularized by James Womack and others. The rest, as they say, is history. The results yielded by Agile practices were overwhelmingly positive. Even the best waterfall teams were ultimately blown away by teams utilizing Agile practices.

Are We Stuck Again?

The Agile practice progenitors attempted to anticipate the challenges of being stuck in the box. They built continuous improvement into the process. The problem with this, I like to describe in a series of bar graphs. This is our starting state:

Recognizing that the Blue problem is our biggest, we tackle it first. After we have remediated that problem, our new graph looks like this:

Now, the problem that didn't look so bad before is our biggest problem, so we tackle that one and after we find the fix, our new graph looks like this:

As you can imagine, after we solve problem the Grey problem, the Blue problem will once again loom large. We tend not to look at the magnitude of our problems in any sort of absolute scale. They are all relative. Eventually, high performing teams are fighting for smaller and smaller improvements.

Breaking out of this cycle requires (dare I say it) a paradigm shift. This fact is not lost on some of the progenitors of the Agile Manifesto. Ron Jeffries, who I mentioned earlier, has this to say about “Agile:”

“So it breaks my heart to see the ideas we wrote about in the Agile Manifesto used to make developers' lives worse, instead of better. It also saddens me that the enterprise isn't getting what it could out of the deal, but my main concern is for the people doing the work.”

This was part of a post entitled Developers Should Abandon Agile. Kent Beck, another signatory to the Manifesto, has offered a similar lament. The catchy title notwithstanding, Jeffries is not actually proposing the abandonment of agile practices. He is suggesting that the “agile industry” has co-opted the original intent and created a situation in which poor implementations abound. I wrote another article about the idea of abandoning Agile practices last year. Agile practices are not the issue. Those who espouse the demise of Agile are at best discouraging the group-think that has taken hold in the industry, or worse, just grabbing some attention for themselves.

Real Innovation

This brings us to the most challenging aspect of continuous improvement. What do you do when you've run out of problems to solve? The study of biological systems provides further insight into the nature of the challenge.

Researchers have learned that all biological systems seek equilibrium. Humans are yet another biological system. Once we achieve equilibrium, we are happy. It is the ideal steady state, so we hang onto it as long as we can (I'm generalizing somewhat here as we probably all know individuals that are constantly creating disequilibrium in their own lives).

Eventually, our environment changes. It is this environmental change that disrupts our equilibrium and forces us back into adaption mode. New environment – new problems to solve. However, what if our environment isn't changing? Can we still evolve? As mentioned earlier, big changes require senior management engagement and significant time and effort.

As a scrum master, I look for experiments that can have an impact without creating disruption at an organizational level. I am fortunate to work at a company that leaves most decisions about how to operate to the individual team. Nonetheless, I regularly face teammates that question the value of risking hard won productivity with experiments.

What is most important is to characterize anything new as an “experiment.” As you probably know, experiments start with a hypothesis about the effects and outcomes of doing something different. In the case of team improvement experiments, if it has the anticipated outcome, the team will continue doing it. If not, they should learn from the experience and use the newfound knowledge to craft a new experiment.

We may not go from dozens of balls (as in the previously mentioned game) to hundreds, but it is part of our jobs to continually improve, even when things are going well. Even when performance will suffer in the short term.

For example, let's say there is a great new programming language that will allow teams using it to write more reliable and scalable code in 25% less time. Thus, in addition to reducing time to deliver new functionality, the new code performs better, which reduces rework. This all sounds great, but at first, while the team is learning the new programming language and its tools, they are going to go a lot slower. Some people call this the hockey stick effect. It is hard to get buy-in for these types of initiatives, but teams that periodically make investments like this can ultimately maintain a leadership position.

There is great pressure to standardize and use “best practices,” but sooner or later, a new player comes along without any baggage and changes the world. To prepare ourselves for this type of competition, we must be willing to disrupt ourselves. If we are not improving, then we are learning. This willingness to take risks in the name of continuous improvement is at the heart of agility. We do quick experiments. Learn fast. And adapt. Now, go out there and shake those bushes!

PDF Version

Bio
Latest Posts

Tom Bellinson

Mr. Bellinson has been working in information technology positions for over 30 years. His diverse background has allowed him to gain intimate working knowledge in technical, marketing, sales and executive roles. Most recently, Mr. Bellinson finds himself serving as an Agile Coach for ITHAKA, a global online research service. From 2008 to 2011 Bellinson worked with at risk businesses in Michigan through a State funded program which was administered by the University of Michigan. Prior to working for the University of Michigan, Mr. Bellinson served as Vice President of an ERP software company, an independent business and IT consultant, as chief information officer of an automotive engineering services company and as founder and President of a systems integration firm that was a pioneer in Internet services marketplace. Bellinson holds a degree in Communications with a Minor in Management from Oakland University in Rochester, MI and has a variety of technical certifications including APICS CPIM and CSCP.