Experiencing Agile: 6 Agile Planning and Analysis Practices to Try
(by Ellen Gottesdiener and Mary Gorman)
What practices can you adopt to help your team experience Agile?
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.
Be clear how decisions will be made—decide how to decide.
Collaborate, collaborate, collaborate. Read a briefing of tips for conducting effective collaboration/discovery sessions on agile teams.
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.
4. Explore Product Options Holistically Using the 7 Product Dimensions
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 or FitNess).
Pull the “testing mind-set” forward by thinking in examples and, as Chris Matts says, “breaking the model.”
Consider using your examples and models to specify requirements instead of writing classic text specifications. Read more about agile analysis and testing synergies.
6. Focus on Finding and Fixing Flaws
Learn. Expect to “fail” to learn—it’s only a failure if you and your team don’t use mistakes as a forum for improvement. Conduct retrospectives to “inspect and adapt” at regular intervals.
Honestly and transparently reflect on both process and product.
We are putting the finishing touches on our new book , which provides specific, practical guidance and examples on all these practices. Stay tuned for the book launch this summer. Details for pre-ordering will be in our eNewsletter. You can sign up here for the eNewsletter.
Additional Readings:
- Gottesdiener, Ellen and Mary Gorman. Numerous article on agile analysis and planning and retrospectives (description, links, and more references).
- Draft of the Agile Extension to the IIBA BABoK:
[…] Read much more detail in the entire article here. […]
Hi. I have a little concern. Are there any disadvantages story mapping a project? Is it time-consuming to execute? Sorry for my questions, I would like to know more about the negative if it has one.
Regards,
David
http://sstack-agile.com/
David: I am not following why you are bringing up story mapping in the context of this blog. can you clarify?