Putting one foot in front of the other (part 4)

In a previous post, I suggested some of the fundamental, structural changes I think IT will have to undergo in the next 10-15 years. And to me, these changes are not optional: organizations will have to make them; the only question is who will risk the difficulties and step up to lead them (and reap the substantial rewards)?

With that done, I’ve come back to Earth a bit to kick off a series of more modest posts that look at some of the baby steps IT needs to take to evolve into a truly strategic capability.

To me, once an IT leader adopts the correct orientation of her department as a strategic asset primarily focused on delivering business value (rather than IT capabilities), she has  a number of very tactical areas to address:

  1. Demand pipeline
  2. Structured requirements
  3. Developer-heavy staffing
  4. Agile methods/approaches
  5. Service catalog
  6. Portfolio management (including rationalization)

In this post, we’ll take a look at the fourth, Agile methods/approaches.

Although there are lots of folks with strong opinions on the merits of agile vs. waterfall (I just got around 7.25 million hits for a search of “agile versus waterfall” on Google), I don’t mean this to be a contribution to that debate. Nor do I want to get embroiled in a “my agile method is better than other agile methods” debate. Rather, I want to highlight some of the things about agile approaches in general that I think IT leaders need to consider adopting in their shops, whether or not they decide to become card-carrying agile proponents.

I think the Agile Manifesto is the best place to start developing an understanding of what it means to develop software using agile methods. Here’s what it says:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Source: http://agilemanifesto.org/

As you might have gathered based on this manifesto, agile is nothing if not practical. It’s focused on getting a working software product that delivers value to the end user out the door as quickly as possible. The primary method for accomplishing this is by breaking up the software product into smaller chunks that on their own can deliver value, even though they only represent a subset of the total functionality desired.

Agile methods are also focused on bringing stakeholders into the SDLC beyond just an upfront period of requirements gathering and some UAT before release. They use some combination of techniques, such as joint application development sessions (JADs), prototyping, iterative review cycles, and so on, to keep stakeholders engaged throughout the SDLC to ensure that what’s being built will deliver value to stakeholders. And if there is disconnect, keeping stakeholders involved more frequently helps reduce cost and schedule overruns by uncovering it sooner rather than later.

Agile methods also help an IT organization strike the right balance between chaos and process by encouraging the people involved in the SDLC to practice continuous improvement. When things aren’t working, agile methods dictate that the team put their heads together to figure out a better way right then and there–not after the project is done in a set of lessons learned that no one thinks to read before the next project starts. As part of this balance, documentation is kept to the bare minimum needed to build a quality product; filling out documents and forms for their own sake or for CYA is strongly discouraged, with a significant gain to productivity (think of all the hours you’ve spent over your career filling out needless forms) and morale (think of how you felt wasting your time filling out those forms).

The final word

We’ve only begun to scratch the surface of how agile methods can help transform an IT organization, and the decision to do so shouldn’t be taken lightly or made because agile seems to be the hot thing. The change management required to go agile in a meaningful way is significant, and poorly implemented agile can be worse in many ways than simply keeping the waterfall status quo. Id’ love to hear from folks on all sides of the issue: Have an agile success story? Have you tried agile and failed at your organization? Strong opinions on agile vs. waterfall or on your preferred agile method? Speak up and let us all know what’s on your mind about this–excited for the conversation to get started…


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: