Experiencing Agile: 6 Agile Planning and Analysis Practices to Try

This question was raised by a listener to the podcast we recorded on agile analysis practices with BA coach Yamo. (Find the podcast here.) The specific question that Katie Metcalf asked us was this:

“What agile techniques would you suggest introducing to a software development team that is currently not using the agile approach but would like to get a flavor for the methodology?”

Agile: Disciplined Discovery and Delivery

Let’s clarify. We don’t think of agile as a “big M” methodology.

In fact, we don’t think of agile as a methodology per se. Rather, it’s a disciplined discovery and delivery framework. As we see it, the term “agile” encompasses a number of methods, including lean, Scrum, XP, DSDM, Kanban, FDD, and more.

We shared with Katie the following six points – what we believe are fundamental for doing and being agile. We focus here on agile planning and analysis practices.

1. Use Three Planning Horizons: Now-View, Pre-View, Big-View

Partition product delivery into planning horizons.

Focus like a laser on delivering the most valuable and risk-prone portions of the product as soon as possible (we call this the “Now-View”). Even if you don’t release to the customer during your shorter time horizons, you need to complete a releasable product at the end of each delivery cycle.

Don’t ignore the future time horizon (the “Big-View”). Your release plan and product roadmap are essential guidelines for continual planning and pivoting.

Keeping your day-to-day work tied to these planning horizons takes focus, discipline, and collaboration. Read more about incorporating the three views into your agile planning and analysis here.

2. Product Partners and Value

Successful products are derived through a partnership of three stakeholder communities: your customers, your business (or organization), and your technology team members. Explicitly and collaboratively identify each partner’s desired value. Remember: value is in the eyes of the beholder.

3. It’s the Goal, Not the Role

We may sound like a broken record but it’s so important, it bears saying again: it’s the goal, not the role. The collective goal is to deliver high value product needs—not limit contributions based on titles or roles. Analysis is the entire team’s responsibility. Read more about this, and learn the value of business analysis in Scrum (also applicable to other agile approaches) here.

As partners, explore options for product needs using the 7 Product Dimensions (users, interfaces, actions, data, controls, environments, and quality attributes). Use predefined value considerations to evaluate the benefits and risks of your options, and select the highest-value options along these 7 Dimensions. Assemble the highest-value options into candidate solutions for your next delivery cycle.

This practice allows you to slice product needs into small, precisely understood requirements (chunks), and it takes only minutes to collaborate in this exploration and evaluation.

5. Make Models Real

Explore your product options by using a combination of analysis models and examples. You can use scenarios, acceptance tests, specs in the form of “given/when/then” (à la BDD), or data tables (which you can run using a tool such as FIT orFitNess).