Transition: More Ideas for Using RUP Phases in Agile Software Development

This is the fifth in a series of posts about using RUP phases in agile software development. (Here is a link to the last post in case you missed it.) The Transition Phase is next.

transitionIf your agile software project makes it through my interpretation of using the Inception, Elaboration and Construction phases, you’ll likely be in one of two situations. Either the software will be really good but containing a minimal feature set, or the software will have an abundance of features but not be quite so good. Either way, lots of work will remain to be done.

The Transition Phase is when good enough becomes great. This is the time for really listening to and watching the people that use the software. They are the ones who truly understand what the software needs to do and how it needs to behave so that they can operate quickly and efficiently. No amount of planning, talking, grooming or testing can replace seeing real people do real work.

Whether you’ve built the minimum viable product (MVP) or decided to go for broke by adding every feature anyone could want (Maximum Requested Features – MRF?), there are several areas the team will have to focus on. An MVP needs to be refined a bit before plunging into new functions. An MRF needs to be refactored and reworked to make it all it can be.

Start by considering the following questions. They are designed to help the team think through the known and potential issues in the software.

  • How does the user workflow compare to the software flow? Software should align with and improve workflow.
  • Does the software speed up or slow down user activities? Software should introduce efficiencies not inefficiencies.
  • Are there occasions when a user must backtrack to recall information? Important information should be readily available.
  • Can the software be operated mostly by mouse OR keyboard? Frequent switching back and forth is wasteful and tiring.
  • Are the displays and menus organized efficiently? Screen clutter creates many opportunities for waste and rework.
  • Does the software respond quickly or at least let the user know there will be a delay? Simple progress bars are not enough!
  • Is the software reliable? Software that loses information is worse than useless.
  • Is the software maintainable? Teams often sacrifice ease of maintenance to meet deadlines.
  • Have technical issues that really need to be addressed been placed in the backlog? They won’t improve with age.
  • What’s missing? Some useful features were likely omitted to meet project constraints.

There are other functional areas that rarely get fully built out in an MVP. They also may be short-changed in an MRF as the stakeholders will inevitably run out of patience and the development team will run out of time. Here are a few:

  • Ad-hoc reporting features
  • Charts and graphs (particularly those tracking trends)
  • Advanced searching features
  • Advanced list sorting and grouping
  • Notifications, reminders and/or escalations
  • Data import/export functions
  • Additional security layers based on user roles or activities
  • Interfaces to external systems for information sharing
  • System administration features
  • Backup and restore procedures

Every situation is unique and yours may not fit neatly into my categories. Regardless, I hope that the items I’ve listed give you some things to think about and some ideas for improving your software system.

It’s not easy to build great software. In my next post, I’ll summarize my interpretation of using RUP phases in agile development projects.

photo credit: Rusty Russ via photopin cc

Updated: December 13, 2013 — 12:25 pm