Making Money With Agile: Tranquil Lake or Shark-infested Ocean?

Introduction

The world is going Agile. Sometimes with intent and caution, sometimes to address a previous challenge, sometimes “just because.”

The benefit of Agile is that a project team is able to get early feedback about its work and incorporate changes every sprint. The risk is that the team uses this discover-as-we-go approach as the primary method of defining the goal of the project. Discovering new needs or changes every sprint can result in there being no end in sight. With no end in sight, management and sales don’t know what can be sold and when.

The approach of discover-as-we-go can go on for months and years, leaving management with no clear way to predict revenue targets and manage cash flow.

Is Agile good or bad?

Yes!

The benefits of Agile are:

• It is a simple project management methodology that breaks work into chunks.
• There is feedback at the end of each sprint and an opportunity to incorporate changes.
• Daily meetings, burn down charts and sprint reviews show progress and monitor commitments.
• The members of the project feel like a team.
• It is easy to learn and adopt.
• It sounds sexy. Do you want to be labeled as “non-Agile or cumbersome?”

However, Agile is not risk-free:

• Agile sprints can cause teams to have no medium, or long-term focus and therefore never finish a version of the product that can be sold.
• The hard work of determining what a customer wants can be avoided by the desire to jump in, code something and feel Agile.
• When Agile is interpreted as, “Just start, everything will work out because of the feedback we will get,” all bets are off.
• Although Agile does include the discipline of determining a release plan, few people bother with that.* “Hey, we are Agile, it will work out.”
• Ambiguous, terribly worded and half-baked user stories fed into sprints to be coded is the first step towards financial challenges.
• Developers, scrum masters and project managers might not have any knowledge or skills in running a business. They are happy when building and coding (which is what we employ them for). Goal setting, selling, revenue and cash flow is not their thing.

What can be done?

• When using Agile, define a release plan (see the red box in the picture) so that there is an end point that can be sold and delivered. The contents of the release will change from the feedback. That is the point of Agile. But to have no idea where the team is going beyond the next two weeks is not good for business.
• Spend time writing and reviewing user stories that reflect the tasks the user is trying to accomplish. Don’t blow off the requirements step as “way too difficult and doesn’t sound Agile.” (See the article, “Selecting an Appropriate Level of Product Requirements Definition“)
• Don’t ask developers to run the business. Coding and running a business are two very different skills. Managers run the business; developers write code. Great managers balance the activities of developers writing code versus defining and finishing something that can be marketed and sold.

Conclusion

I have a friend in China that speaks a few sentences of English. A few times we have gone on day trips to local parks to hike. Concerned for my safety while crossing busy Chinese roads, the phrase she cautions me with before each crossing is, “Be careful; don’t die.” That seems appropriate here too!

If you would like help addressing your agile challenges, please contact us for a complimentary 45-minute chat or just send an email.

[Forward this email to your boss! Subject: Here’s a cool tip for you] Quick Link

* Not all Scrum definitions include a “Release Planning” step. They used to, but the term was retired as “too predictive,” and therefore not “Agile.” You need something.