Remember how bad it was before Agile? The failure rate of software projects was astonishing; on the order of 35% of all software projects failed to produce a viable product. And we know a high percentage of products that were “viable” weren’t very good. In terms of making software, pre-agile projects often just didn’t work.
Agile projects are more likely to succeed, and the approach is wildly popular with development teams. It’s a huge win to go from mostly failed software projects to those that—more often than not—produce something of some value, but we should expect more.
Too often, agile projects deliver software that fails to align with what the business was hoping for. It works, but lacks coherence and the balance of priorities is off. If you have a good agile team, a product backlog can be filled with, frankly, anything, and the team will create some kind of software from it. Good agile teams will make meaning from what they have, but is it what the business wanted them to actually make?
Why Doubling Down Doesn’t Help
This is a known problem, and many techniques have been developed to address it. Most involve doing “better” agile—fine tuning ceremonies or trying to get more engagement from stakeholders.
There are limits to these fixes, however. First, an agile team can’t control the structural forces hindering business engagement. In fact, doing “better” agile in many ways increases the likelihood that the business will struggle to engage with the agile team effectively, because it requires the attention of key employees who have competing demands.
Second, “better” agile may make things worse. From a business perspective, agile is fundamentally and defiantly weird. It is very hard for strategic, results-focused managers to understand or buy into the ceremony-driven, emergent, spooky way that software gets developed in agile environments. That lack of buy-in can really damage an agile team. Companies will find managers who “hack” the agile process and end up micromanaging sprints. Or they will abandon the agile team entirely and hope for the best, which is good for agile teams but almost certainly bad for the business. This essential weirdness of the process, and the struggle to convey it to businesses, is a weakness that the methodology has never fully addressed.
In our experience, the introduction of models to the agile process solves both these problems.
Why Agile Models Work
Models are conceptual sketches that can take the pressure off user stories as the only portal for the business to convey needs and get common understanding.
Models aren’t requirements as most people envision them; they are not direct instructions about how to build a system. Instead, they describe essential concepts in the system that help foster deeper understanding. Models communicate INTENT, as opposed to, say, an interface design specification.
For many developers model creation is nearly second nature. White boards in programmer rooms are covered with models, although they aren’t always explicitly called that. The models tend, for the most part, to focus on local problems about specific user stories in the context of a sprint, usually for software (code) and user interfaces. But the real power of models is coordinating understanding for stakeholders.
Bring The Models (Out of the Sprint)
If teams want to convey broader understanding in agile projects, they must bring models out of the sprint and use them across an entire release cycle or project. The model will fill in gaps where user stories and software are inadequate to aligning stakeholders on Priorities, Purpose, and Vision.
This is the hard shift that is required for most agile teams, because there is a fear that the models will start becoming cumbersome, unnecessary requirements. This is a valid concern, so we believe that project-level models should fit into some very specific criteria:
Collaborative—Done together.
Sufficient—Good enough for understanding and no more.
Replaceable—If conditions change, make a new model.
Specific—Must be about the function of the planned system, the users of that software, or their interactions.
Shared—Should be in a shared repository for use across the entire project.
Project-Level Backlog Models—Should be about the project, not about individual sprints.
Transformative—Backlog Models—Do not have to be tied to any specific feature or user story in the project.
If you’ve read this far, you likely have an agile project in motion, or one that is about to begin. Is it too late to get modeling into the effort or to improve communication? No.
Add Models to your Backlog Today
Start with a “zeroth” iteration that involves your major stakeholders and production team. Basically you will be doing an audit of user stories in the presence of the business team, and asking two major questions:
Across the entire set, what are the user stories that seem to have the most in common? What are some words that they have in common?
Does each user story get at a core need of the system? Would you be excited or happy to have a sprint be the outcome of this story?
The answer to question one will show the implicit structures across user stories. The answer to question two will reveal that some user stories are unloved, incomplete, or confusing. That’s okay.
After this first meeting, your team will have homework:
For each pile created when asking question one, spend some time generating a few basic models that business could use to defend or support. The most common model would be personas or wireframes, but any sustainable model will do.
For each user story that gets a “no” or “meh” to question two, ask if the user story needs to be rewritten or better explained. In the case of a better explanation, consider whether you can build any models that fulfill the criteria above to make that improvement.
Make Understanding Part of Your Agile Manifesto
Part of this effort will be painful: you may need to review and possibly rewrite your user stories. This is okay; you may find that some user stories can be either collapsed into another story or thrown away. The way that we would approach this is to approach it like an alignment effort with your stakeholders where the goal is to create models that are explicitly not user stories, but create common alignment with business and development. The three we most commonly recommend are personas, wireframes, and user journeys.
Finally, your team should come together and commit to three things:
Execute a user story audit that basically asks: “Based on what we now know, is this story still correct/relevant/probably scaled in terms of use and acceptance criteria?”
Reassemble the product backlog.
Invite business to work with the models in conjunction with the product backlog to ensure as much knowledge transfer as you need to get their alignment and agreement.
We find ourselves in a time when the kismet of agile has created more, better software than ever before. We believe that the use of models can create a commitment to understanding your clients and stakeholders better than ever before. As a result, we’re creating software that not only works, but creates delight and alignment with the business in ways you could never imagine. Adjusting processes and structure is always a challenge, but the vision of delight and alignment is worth the effort.