Iterative Development and Incremental Improvement
Iterative development is the process by which you release software in iterations – small, incrementally better versions of your software. People usually think about this solely in terms of enable the most valuable capabilities first, then the next most valuable capability next.
That’s fine, when your product is new. Eventually (or quickly!) you will reach the point when the next most valuable improvement is not to add a new capability, but rather, to make an existing capability more valuable.
Everything is an Upgrade
In a couple earlier articles about organizing migration projects and requirements for migration projects, I wrote about how migration is a bit of a misnomer. Everything is a migration.
My argument in those earlier articles is that the problems you’re solving with your “new” solution are not new. Your customers are currently solving them in different ways. The relevant question for migration projects is around how much your users are changing the way they solve their problems.
[As a slight segue, failing to appreciate this distinction can lead you to a project that is based on a faulty problem statement.]
When you are delivering incremental improvements to your product, through iterative development, you are upgrading your software. You are migrating your users from their old solution to their new solution. It just so happens that you are replacing yourself, as you migrate them from the old version to the new one.
A viable strategy, that appeals to me personally, is to continuously innovate, disrupting your market, before someone else does. With this approach, you are intentionally reinventing your solution, making it difficult for someone else to out-innovate you. This is a great way to approach developing your roadmap strategically.
Your market will change. Rapidly. Do you want to react to your competitors, or keep them on their heels while you stay on the balls of your feet?
The reverberations of the “new” Twitter still haven’t settled, and many of Twitter’s competitors are on their heels – some of them only now realizing that Twitter has always been a competitor and not just “a platform.” The new Twitter doesn’t really change anything about how people use Twitter, except make it (markedly) better.
Avoiding Featuritis
When is it more valuable to improve what your software already enables, versus enabling users to accomplish more with your software? Kathy Sierra introduced us to the concept of featuritis, the idea that too much is too much.
In an article on viral product management, I proposed that by making your software better, you can tap into an altruistic mechanism by which people will promote your product. As an example, I proposed improving the usability of your software as a means to cross this viral tipping point.
One of the key ideas is that making it better for users makes your product better for your company.
Managing “Improvement” Requirements
Now that we all agree that there is value in making your software better [comment below if you disagree] the question becomes “How?!”
Use Cases can be used as the keystone to your requirements arch. Sometimes, user stories are better than use cases, but use cases are perfectly agile. When you’re starting a project, you want to apply an outside-in approach to defining the scope of that project – or more particularly, to define the scope of problems you are solving in your roadmap. This article will talk in the language of use cases, but identical concepts and approaches apply when using user stories as well.
When you have prioritized a use case as “the next most valuable capability to introduce” you add it to the backlog for your sprint. The implementation team then provides feedback that use case is “too big” and you have to slice it up. It is important that you don’t split the use case in such a way that you only solve half the problem.
You also shouldn’t deliver a “bad” product. In fact, the ideal way to introduce a new capability is to satisfice, and not introduce the “perfect” solution in your first iteration. Make your first solution “good enough.” Part of the art is defining “good enough,” but rest assured, it is not the same as “the best you can possibly do.”
Summarizing some key elements from above demonstrates the eventual reality you will face:
- Every problem* your users face is already being solved, you are just providing a better solution.
- There is diminishing, and eventually negative return on adding more capabilities to your product.
- Your first release of a given capability will only be “good enough.” That leaves room for improvement.
*Yes, you can pedantically define “the problem” as “the existing solution is not good enough” – but you still end up in the same place, so why bother?
Eventually, the value of improving something you’ve already released will be greater than the value of releasing something new.
What do you do? You implement the same use case again.
If your product is Software as a Service (SaaS), you absolutely should be thinking about things this way. Becoming better is a continuous improvement objective that is implicit in the economics of SaaS products.
Revisiting Use Cases
Not to be confused with re-use of use cases, revisiting a use case is specifically revisiting – with the goal of improving – the implementation that is already in place within your product. This is a special case of a migration project – you’re migrating your users from your old solution to your new and improved solution.
.png)
You may be migrating to an identical process, perhaps with faster performance than your previous release was capable of. Or you may be improving the procedure (improving usability, interaction design, visual design, etc) without affecting the process. Generally, a “make it better” use case improvement effort will have no more than a minor process impact. Your users are still doing the same thing, they are just enjoying it more, or doing it more effectively.
When slicing use cases to make them fit within a single sprint, you may design them for a single user persona in the first release, knowing that you won’t meet the expectations of a different user persona until the next release. In this case, your non-functional requirements, constraints, or acceptance criteria will be different. Your use case may also be different (in the details) while appearing to be the same. This also common scenario can be addressed with the same approach.
Find that old use case (from several iterations ago) and put it back in the backlog. Remember, agile is about conversation, not artifacts. If you need to add an explanation to the use case, because your team fixates on the fact that it is “already working,” add a qualifier that it needs to be “better.” Then have a conversation, and explain how it needs to be better.
Is Design Part of Implementation?
Some teams organize such that designers (both architects designing code and designers designing interfaces are being addressed here) are part of the implementation team. Other companies treat designers as stakeholders – providing guidance and input to the product managers and product owners.
When a “new design” is being requested from outside the team, include that design guidance as part of the input to the implementation team – through artifact and / or clarification.
When a “new design” is being requested of the team (the designer is part of the team), express the new acceptance criteria to the team. Note that these need to be measurable requirements if they are to be considered good requirements.
Summary
There will come a time when the most valuable thing you can do is improve the user experience for a capability your product already embodies. When that time comes, use the same use case again, updated with the new constraints, non-functional requirements, and acceptance criteria.
Reference: Use Cases for Iterative Development from our JCG partner Scott Sehlhorst at the Business Analysis | Product Management | Software Requirements blog.
