There’s an impression among some software developers that agile approaches like Scrum, Kanban, Lean and XP only apply to software products, not other types of software. That impression likely results from naming conventions such as “Product Owner”, “Product Backlog”, “Releases” and “User Stories”.
While many of us associate software with desktop applications, there are many types of software. The tools and techniques used to build them vary. Here’s a short list of common types:
- Application software – desktop applications
- Middleware – distributed systems software
- System software – operating systems, device drivers, etc.
- Databases – storage systems
- Firmware – low-level control software
- Programming tools – compilers, debuggers, etc.
Then we have software for smartphones, tablets, game boxes, and other interactive devices.
Product focus is a good thing.
Software doesn’t have to be sold to consumers in order to be described as a product. I think having a product focus can be a good thing for any software team. Products generate revenue. They keep companies in business. They have to be as good as or better than the competition.
Software development groups focused on internal users often lack the competitive energy that product groups have. I encourage everyone to think competitively regardless of the nature of the software being written.
The concept of releases also applies to any type of software development. Many projects seem to operate on the “one and done” principle — write lots of code, test it, release it — done. Toss it over the wall and it becomes someone else’s problem.
This attitude may succeed for small and narrow software solutions. Any software system tied to a major business process will require active user participation to validate functionality and identify defects. Furthermore, significant changes and upgrades will be needed as the business evolves. Plan on it.
User Stories don’t only apply to non-technical people. The user could be an external system issuing a request for status or data. The user could also be a system administrator making configuration changes.
Don’t get caught up in semantics.
Interpret the terms common to agile development within the context of your environment. Define ‘user’, ‘story’, ‘release’ and ‘product’ in terms that make sense to you and your team.
The concepts of short delivery cycles (sprints), brief, descriptive requirements (stories), and prioritized work lists (backlogs) can be applied to every project.