The End of Agility?

So now that Agile software development, Scrum, Extreme Programming, and Lean thinking are all the rage, I have to wonder - is this where we thought it would all end up?

This puts me in mind of the early days of object-oriented programming, when Grady Booch first started drawing diagrams with fluffy clouds. It took about 5 years from the grassroots movement of developers finding that sort of modeling useful, to the Rational Unified Process being created, then mandated by organizations as best practice.

I see the same trend, for better or worse, with Agile methods. We now have certifications, big industry conferences, specialized tools and software (yes, my company included), consultants, trainers, and a few dozen books to help guide a fledgling agilist along the way.

Perhaps less encouraging, I also see more of a trend of mandates from upper management to the development organization that sound a bit like "We will use Scrum, whether you like it or not".

It's been about 10 years now since Agile methods (Scrum, XP, etc.) first took the stage. Ten years is usually about right for maturing a product, but what about an industry? Have we reached the peak of agility in organizations and the state of the practice?

If history is any indicator, the environment is ripe for the "next revolution". As the song goes, "Meet the new boss...same as the old boss".

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams

Agile Project Management: What's In It For The Customers?

One question I'm asked frequently is how Agile project management is different from traditional project management.

Normally I start talking about iterations, planning, user stories, and the like, but I get a decent number of blank stares in response.

I like to think I'm pretty good at explaining things, so I tried to figure out what was missing from my description. Is it the terminology? Do I need more examples? Is this something that non-techies just can't comprehend?

Then it hit me - like all other concepts, products, or services, Agile project management needs to be explained in terms of it's benefits, not it's attributes. The real question people were asking me was "How will this benefit me?", not "How does it work?"

So without further ado, here are the benefits of Agile project management for software teams in customer terms:

1. More Requirements Flexibility (Ability to Undo Screw ups) - because of the quick development cycles that produce working software, an agile approach keeps mistakes shallow, and let's you correct your mistakes or in company political terminology "refine your solution".

2. Reduced Project Risk (No Need to Explain Lengthy Delays and Cost Overruns) - because of the frequent planning and estimating sessions (at least once per month), you'll know very quickly if the project is off schedule, and you'll have control over what to do to get it back on. This leads to better predictability, less embarrassment, and happier stakeholders.

3. Transparent Project Management (Trust, But Verify) - having visibility into which features (stories) are being worked on, and being able to actually use the software after each iteration means that you can verify progress instead of relying on a set of lines on a Gantt chart. This helps with both internal teams and outside consultants.

4. Early Delivery of Value (Can I Have That Now?) - because Agile projects deliver the most important things first, you can decide to deploy a system much earlier than planned if business circumstances dictate that. Sometimes there is enough value in the top 10 features that the remaining 100 can wait. And delivering value is sort of the point of most of our jobs, after all.

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams

The High Cost of Management Indecision

Rob Walling writes about the high cost of management indecision on software projects.

Essentially, the argument is that even wrong decisions allow developers to keep momentum and push a project forward. The cost of reworking areas winds up being less than the cost of delaying, doing nothing, or switching to other tasks. Here's an excerpt about the cost for a team of 10 developers:

If we decide not to make any decisions we lose 10 times $822, for a total of $8,220 per week. Let me say that again: blanket indecision loses $8,220 per week; making decisions (including bad ones) loses $1,680 per week. That's a difference of $6,540 per week.

It's actually a pretty powerful argument for doing everything possible to lower the perceived cost of making a decision for managers or customers. Perceived cost is that fear-driven idea that if you make a certain decision, you'll be stuck with the results forever if it doesn't work out, due to the high cost of changing it.

This is exactly the problem that Agile methods were designed to solve. By reducing the perceived cost, we encourage our customers to make more timely decisions, learn from them, and adjust as needed without incurring high costs.

Of course, this doesn't necessarily apply to technical decision making. "Should I use a database or direct file storage?" is a question that doesn't need a final answer right now. The right question for technical decision points is "How can I encapsulate that?" That lets developers move forward while keeping the cost of future change low.

If it truly does cost more to delay management decisions, wouldn't it be wonderfully freeing to start making some?

Even if you don't have all the possible information you'd like?

Even if you could be wrong?

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams

Scrum Reference Card

Ran across a useful (and free) quick reference PDF for the Scrum Agile method for managing software projects.

Scrum has really gained some momentum over the last few years, perhaps in part from the now ubiqiutous certification program (Certified Scrum Master). It's a deceptively simple framework for Agile project management, consisting mainly of a few rules around creating a product backlog, priotizing work into 30 day "sprints" or less, daily meetings or "scrums", self-organizing teams, and the key: inspecting and adapting continually to improve based on real-world feedback.

Anyway, here's the link, courtesty of Contrado in Australia:

Scrum Reference Card PDF

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams

Agile Project Management and Competitive Advantage

I wrote earlier about what I consider to be the core of why Agile methods work - small wins and increasing momemtum.

Now I'd like to offer a rationale for why anyone managing a software project should at least consider using an Agile approach for managing releases, if not for the actual development itself.

Turns out it's the same rationale as above - small wins.

The primary job of management is to ensure that customers are getting outstanding value (this makes them cheerfully continue as customers), while controlling costs, and reducing risks to the business.

In software development, value mostly takes the form of features - things that help the customer make more revenue, reduce costs, or increase productivity.

Of course, until the features are actually delivered, put into production, and leveraged by the customer, no value can be realized.

This means that your management won't know if they're doing their job until you've delivered software to someone, and they tell you it's solving the problem they had.

So if you put on your management hat, would you like to know this sooner or later?

Looking at the risk side of the equation, the more features that are in development for an extended time period, the higher the risk that customer needs will change. Not to mention technology, market conditions, company budgets, and leadership.

Now, there's obviously a limit to how frequently you can deliver value, isn't there?

Your customers couldn't handle a new release every month, right? What about every week? Shocking!

On the other hand, what if you delivered just one important feature that didn't break anything? Or that didn't require re-training, extensive documentation, tedious software installations, database migrations, follow-on patches, and numerous support calls to take advantage of?

What would your customers think then?

If software vendors (or internal IT development teams) could deliver incremental value whose benefit far exceeded the cost of upgrading, what might customers say about your company or team?

And if your competitors couldn't do this as effectively (for internal teams, your competitors are outsourcing firms), would your customers accept them as substitutes?

Agile methods aren't just about making your programmers happy, they're also about delighting your customers, saving your CEO's job, and mkaing your less agile competitors very unhappy.

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams