This is the first part of a multi-part series on Agile in which we’ll describe:

• What is Agile and why does is matter for your organization?
• How does an application development team adopt Agile to deliver better software faster?
• Who are Business Analysts and what they can do to unlock an Agile team’s full potential?

To begin, consider this premise: enterprise software development is not fun. Traditional software development methods in the enterprise are rigorous, thorough, well thought-out, and even successful (occasionally). It is everything but fun: 100 page requirements documents are not fun to write—nor fun to read. User acceptance testing when software needs to be released in two weeks is not fun. Writing code to build a solution where the developer has no say on scope or schedule is not fun. And when work is not fun, quality and schedule suffer.

It wasn’t supposed to be this way. Technology, at its core, is supposed to be fun. Software is supposed to be an intersection of art and business, where talented developers and managers partner with business stakeholders to drive to one goal: delighting customers. But somewhere along the way, as projects grew in complexity and challenged well intentioned managers, managers started to apply traditional project management concepts from other disciplines in an attempt to instill predictability and standards to the art of software construction. There’s a work breakdown, an end date, and resources. Take the tasks in the work breakdown, assign a man-hour value to each, add it all up and figure out how many resources are needed. Simple right?

No, not really.

Some IT projects fail to meet their targeted completion dates. Other projects fail to meet their targeted feature set. And some fail to meet both.

The reasons behind this are many, but they all derive from the same root cause. Software is not fun. We no longer focus our efforts on delivering working software that delights customers but rather the activities related to traditional project management. Consider the milestones in a typical software development project:

• Requirements document(s) approved
• Architecture document(s) approved
• Test plan authored
• System test cases authored
• User acceptance cases authored
• QA approval achieved
• User acceptance achieved

Somewhere in there actual development happens…uh…doesn’t it? We have gone from watching the baton, working and valuable software, to watching the runners. And when we do that, we look for individuals to blame instead of what’s slowing the team down.

In contrast, consider the milestones in an Agile project:

• User can log in
• User can see inventories of product
• User can see open orders
• User can manually schedule customer delivery
• User can request calculation of optimal routes between customers and warehouses

The focus changes from project plan to working software. When the development team is asked for weekly status, instead of saying, “We’re trying to figure out section 3.4 of the requirements documents,” they are saying, “We’re working on the algorithm to calculate optimal delivery routes.”

Agile is a software-centric implementation of Lean manufacturing. As Lean thinking exposes sources of waste on the shop floor, Agile frameworks with their focus on interactions, collaboration, and continuous improvement, are a response to traditional waterfall methods and intended to refocus the activities of a software development team on that which the customer really cares about—working software.

Note here that Agile frameworks are not processes; they are frameworks that teams adapt and modify to suit the particulars of that team, the product, and their customers. Agile assumes team members are smart and dedicated people who can decide for themselves how best to delight their customers. Sounds fun, doesn’t it?

The next part of this series discusses the specifics of a specific implementation of Agile named Scrum.

We’ll see how to put the fun back into software while providing better estimates, risk management, and higher quality than traditional software development practices.