There are two basic ways to think about new software versions:
- “Oh no, not again…”
Which one you adopt depends mainly on your attitude towards the software to begin with, and how much effort is required to implement it. The first reaction is reserved for software that you like using and for which you look forward to new features and benefits. Software with easy update paths (for example, those that don’t require uninstalling the previous version, don’t break existing files, and don’t require reboots) also fall in this category. The second reaction is pretty much for all other software.
(There’s actually a third reaction, which usually comes up after a new version has been implemented, something along the lines of “Why did they make my favorite feature harder to use/find?” or “Why did they eliminate it altogether?” This case is rather beyond the scope of this post.)
The Motivation for Software Updates
The development of any but the most trivial software is rarely a one-and-done proposition. There are numerous reasons why a new version of a piece of software might be needed:
- Bugs. Despite our best efforts at development, testing, and project management, some bugs will slip through. These need to be addressed promptly, especially if they affect critical functionality.
- Security. No software development shop wants to be the one that failed to provide a patch for a security vulnerability in time to prevent a customer’s data breach.
- Compatibility. Operating system changes, changes in underlying development frameworks, or changes in interrelated software or file formats may require a given piece of software to be updated so that it will continue working as expected (or at all).
- New features. Customers often request new features to make the software more useful.
- Performance. This covers any enhancements not specifically targeted to the preceding categories, including changes that make the software faster, more efficient, or easier to use.
The big picture is that software, especially business software that supports critical business functions, must continuously evolve along with the business. Businesses don’t stay in one place; their product lines, customer demands, marketing strategies, competitive landscape, and business processes all must change over time to keep the business viable and relevant. Their software tools must change over time as well.
Software Updates in an Agile Environment
How do we manage software updates within our Agile development environment?
Really, the approach is not much different from that for new software; the only difference is the starting point. Recall that in the development project methodology we use at AndPlus, the goal of the first version of any software is the “minimum viable product” (MVP), or the minimum feature set that the customer will accept as “working” software. The next version of the software starts from this baseline, plus the product backlog.
The backlog is the list of features, bug fixes, and other changes and enhancements that are needed or requested. Essentially, it’s the development team’s to-do list.
One of the most important phases of the project for the next version of the software is deciding what backlog items to include. For this exercise, we involve the customer very closely. The discussion involves setting priorities and understanding the level of effort required for each backlog item.
Why not just include all the backlog items in the next version? Because doing so runs the risk of becoming mired in a never-ending project. A project becomes never-ending because customers will continually add new requirements during the course of the project, because of the fear that if a request doesn’t make it into the next version, it will never be included at all. This leads to a vicious cycle of scope creep, recalculating the level of effort, pushing out delivery dates, and blowing past cost estimates.
At AndPlus, we prefer our projects to be time-boxed into 100-day development cycles, which give us reasonably-sized projects that are achievable and manageable, and prevent scope creep and stakeholder burnout. If a backlog item doesn’t make it into version x + 1, it will be considered again for version x + 2.
Software development is a journey, not a destination. The end game for a piece of software is not for the customer to keep using the same last version forever; the software should undergo continual updates until such time that it is retired in favor of a brand-new tool.
At AndPlus, we understand this lifecycle, and we follow it because it most closely matches a customer’s needs, which necessarily evolve over time. By implementing a development project approach that supports this evolution, we will continue to provide compelling software to happy customers.