Staying on Course With Agile

You may have heard that agile is just a bunch of cowboy programmers doing whatever they want; there is no rigor or discipline and best of all…NO more documentation. You may have heard about the agile zealots and that teams are full of these so called “agilistas” just spewing out code with no concern for quality and that you never know when anything is going to get done. You may have heard that others have tried some form of ‘agile’ and that “it” doesn’t work. Well fake news is everywhere these days, and misinformation about what agile is, and the notion that agile doesn’t work is a prime example.

The emotional reactions to agile can range from ‘meh’ to a vitriolic ‘it’ll never work here’. But, for organizations that are enthusiastic about making a transition and infusing more agility into their businesses, it is important to filter out the hyperbole. The facts can set you free. Becoming more agile is a journey rather than a destination, and in many ways, the path can be non-intuitive and overgrown with detritus.

Clear requirements have traditionally been an important first step to understanding the solution space and, just as importantly, an idea of how long it will take to implement it. There is a bit of hubris in this approach. Experience has shown that trying to nail down requirements at the beginning of a project—when we know the least about it—is the worst time to do so. What teams need instead is the ability to learn what a customer is trying to take care of throughout the project and make course corrections based on that emerging knowledge as it grows. Engendering the skill of making course corrections is one of the keys to the agile kingdom.

Experiments, and designing for discovery helps teams stay on course and produce better outcomes than big requirements documents and a lot of up front design. A well-groomed backlog is essential, but it does not mean that every detail is understood and articulated up front. Determining how to implement the details of a solution at the last responsible moment is encouraged because great solutions are based on the most up to date information about what is really needed rather than what we thought was needed at the outset of the project. Balancing when that information is captured and converted into team knowledge is a big differentiator between “doing Agile” and being agile.

That does not mean we don’t do any up front planning and certainly does not mean “No Documentation”. Themes, Initiatives, Epics and Stories all need elaboration and some form of memorialization so that teams can gain some collective knowledge around the outcomes that are going to be most important to customer. That documentation may be concise, and it may continue to be elaborated throughout delivery, but it should be captured in some way that communicates both the what and the why of the effort. The outcomes a customer is after is more valuable to understand than features or functionality. Requirements documents historically focus on the latter.

Far from the misperception that agile lacks discipline, done well, it is actually more rigorous than traditional approaches. Prioritization around value is not just the first step to a series of predetermined steps, but rather an ongoing guiding force as we continually refine our course toward the ultimate destination. Like an airplane navigating to Tokyo, pushed off course by winds and sometimes circumnavigating around bad weather, constant course correction produces a better result than setting a direction and hoping nothing changes along the way.

In a way, IT Leadership reminds me of my flying days. From checklists to navigation charts, pilots need documentation too. They need to know the radio frequencies with which to communicate and the protocols for doing so. And the good pilots are rigorous; they are disciplined. Now, there are some cowboy pilots out there who eschew the rules. Sometimes, unfortunately, they end up serving as a cautionary tale for others. There is an old saying about pilots, and I think it applies to IT leaders as well.

There are old pilots and there are bold pilots, but there aren’t any old, bold pilots!

So, rigor, communication and even documentation really are necessary. The best pilots have a lot of airtime and experience. They are most likely to get you safely to your destination. Indeed, for IT leaders, with large IT projects, there are similarities to flying a plane. Communication as well as both the skill of navigating and course correcting—are essential.

There are both cowboy pilots and cowboy agilistas out there. IT projects and flying can be inherently dangerous, and like so many failed IT projects, there are a plethora of failed agile experiments too. My recommendation in both cases is to look for experience. If you are considering agile, don’t listen to the “fake news”. Find a seasoned agile guide; someone with an approach that considers your environment, your business model and your customers and flexes to help you make the most of your transformation. Experience matters and the success of your journey may just ride on who you’ve chosen to help you navigate the course.