Agile Expectations: Introduction

October 3, 2013

This post contains draft of content intended for an upcoming ebook: Agile Expectations: What to Expect from Agile Development, and Why. Blog posts will be organized under the “Agile Expectations” content on the left-hand side for easy reference. I welcome your comments and feedback! – Dave Moran

The inspiration for this guide comes from my own agile journey that began with one development team in 2005, quickly migrating to all of our teams. In fact, the title of this guide began life as a document I started with our management team early on during our agile adoption.

In 2005, I was working for a software company as the Director of Software Development. We had just completed development of a large, complex product that no one in our organization felt was a rewarding, satisfying experience. The only satisfaction came in claiming victory; claiming being the key word.

We had a lot of fixing up to do. The schedule pressure had been enormous, the requirements continually shifted throughout the development effort and sections of the code – despite this being a 1.0 release – really needed re-factoring. The pressure to cram too many features into a first release had led to inevitable shortcuts by tired, overworked, desperate developers.

It was this team that approached me about trying agile development. I’ll confess that I didn’t know that much about agile development at this point in time. I had heard of it and read a little about it, and I had even attempted to learn more a year or so prior to this from some XP (eXtreme Programming) developers that I met at a development conference.

These developers didn’t sell me on agile, not by a long shot. I was simply told that, “There’s no other way to develop software.” Worse, their attitude clearly conveyed that I was an idiot in their eyes for using any other approach. But they didn’t explain what was different or why, and it was clear that they had zero interested in making an attempt. Needless to say I didn’t come away energized to take a closer look at agile.

However, agile was continuing to gain worldwide attention, and given our own experience I was certainly willing to trust the professional judgment of my staff to experiment and learn more about it first-hand. And learn we did!

We learned a lot by making mistakes. We weren’t completely uniformed. We read books, sent people to conferences and invested in some training. But we didn’t bring in an agile coach. Hindsight is always 20-20, and I can honestly say that skimping on training is a mistake and a coach would have been worth the investment because we a) underestimated what we were getting into and, b) made mistakes that could have easily been avoided.

Case in point: Fairly early on in our agile adoption it was becoming clear that our organization had conflicting expectations about what it meant to be agile. Development teams were embracing autonomy (freed from us meddling managers), but with one team we lacked transparency and visibility into what the team was working on (other than a very high-level statement of intent) and what their rate of progress was. There were no demonstrations of working software and no information-sharing of any kind.

This was a symptom that trust didn’t exist between management and the development teams, but as I was learning more about agile it became clear to me that this was “adjusting” agile development to be something that is isn’t supposed to be as well. Other, not-so-subtle clues were in abundance. In management meetings I heard things like, “We’re losing control!” and in development meetings I heard statements like, “Agile is whatever a team makes of it.”

In response, I drafted the beginning of a document that I titled, “Agile Expectations” that the entire management team collaborated on to complete. This document – only a few pages long – established a baseline understanding for our entire organization. This wasn’t the end of our understanding, it was only the beginning. But I view it as an important step.

As I’ve branched out to being an agile coach and interacting with other companies in my community as they adopt agile, I’m seeing a recurring pattern. Organizations want to adopt agile, but they either feel that agile is already close to what they do today and/or they have a strong desire to retain a great deal of what they do today as they adopt agile.

Either way, a good many organizations aren’t expecting much in the way of change with their agile adoptions because they are underestimating what they are getting into, just as we did. I’m not advocating making sweeping changes because you are adopting agile, mind you. There’s nothing wrong with making changes a little at a time. Taking on too much change all at once can be very disruptive to organizations. Adopting agile is akin to fixing an engine while the engine is still running. We need to adopt responsibly.

However, there is danger in under-investing in some knowledge acquisition about what agile is all about. To achieve the benefits of being agile you need to understand what I was seeking to understand from those XP developers I met: What is different and why. This situation and my experience inspired me to create an Agile Expectations lunch and learn presentation to bring to companies considering agile. The next logic step was the creation of this short guide.

I don’t want to see you invest time and effort to change to something new only to discover later that you aren’t deriving any benefit as a result of that change. Make no mistake, agile is change; and if you are sincere about adopting agile you will be changing how you approach software development, so let’s set that expectation up front.

Declaring agility sets expectations in peoples’ minds. If you are a leader stating that you are agile – but you are only agile in certain ways and not others – it is best to be very clear on this point and your intentions going forward.

Consider what happens if someone is hired believing that you are an agile shop (because you told them you were), but discovers that your “agile project managers” are predominantly managing and executing traditional projects and that your organization has done little more than adopt some agile vocabulary – with no intent of actually changing?

Aligning expectations is critical; otherwise you will create counterproductive friction within your organization. As you discover in this short guide, even one agile team working in a non-agile organization will face challenges because no person or team in today’s business world works in isolation. It is best to understand what those challenges are up front.

My goal with this guide is to help you understand what to expect from agile development by explaining what is different and why so that you can make informed decisions about what you are adopting and when. Please let me know if I’ve succeeded or failed in that mission so that I know what I need to continue doing and what I need to improve!