BrainsLink

Linking the left brain and the right brain

Don’t Just Prioritize User Needs, Prioritize the Process Too

prioritizeMany software development teams go to great lengths to prioritize requirements, features or user stories. (I hope your team does.) It’s a valuable exercise if people take the time to truly evaluate the importance of each request they make or receive.

Do you want to improve your software development process? Apply the same logic to the various elements of your process — prioritize them. Not every aspect of the software development process is equally important. Nor should every artifact be used on every project.

Here are three categories I’ll use to prioritize process elements:

  • Strategic
  • Important
  • Non-essential

As for the elements of the process to prioritize, that’s pretty much up to you to decide. Here are some ideas to get you started:

  • Product vision
  • Project goals
  • High-level software requirements or user epic backlog
  • Detailed software requirements or user story backlog
  • Specifications and other documentation
  • Process diagrams
  • Architecture diagrams
  • Source code
  • Test scripts/code
  • Build scripts
  • Deployment scripts
  • Defect tracking
  • Change management
  • Status meetings
  • Metrics

Now think about this.

What elements of your software development process are Strategic? Important? Non-essential? Here are my definitions. Feel free to re-word to your liking.

Strategic – Any part of the process that is critical to the success of the project. (If you claim that everything is strategic, go to your office. Do not pass the team room. Do not collect your paycheck!)

Strategic process elements are vital to project teams. Teams simply cannot function without them. Think long and hard about what you label strategic. Good project teams can operate with very little guidance. Poor or inexperienced teams may need much more.

Important – Important elements help teams do better. While teams can get by without them, these elements offer things like time savings or improved quality.

For example, automating the deployment process might be important to a team that does frequent deployments but not so much to one that deploys infrequently.

Non-essential – Whatever is left is non-essential. These elements are useful either to the team or to external participants but don’t add much value. I’m not equating non-essential with wasteful. (I suppose wasteful might be a fourth category but I’m hoping you’re better than that.)

For example, tracking metrics might be considered non-essential but it can be a useful tool for improving team performance.

What’s it to you?

I encourage you to go through this exercise. Start with your core team. Do it again with your stakeholders and possibly a third time with your suppliers (internal or external groups you depend upon). You won’t get the same results each time but that’s okay. You’ll develop a list of what really matters and what doesn’t.

Focus on the strategic elements. Do all of them to the best of your ability. Make sure they are complete, comprehensive and thoroughly vetted. They should be part of every project you do.

If any important element is not providing the value expected by the team, eliminate it. Do the remaining important elements well. They should be complete but not necessarily comprehensive or elegant. You might skip them for some projects.

As for the non-essential elements, consider trashing them all. You may want to keep a few around for job satisfaction or team morale reasons. There may be a few that can be improved to the point where they become important (or even strategic).

Focus on what really matters.

photo credit: jakuza via photopin cc

Updated: February 12, 2013 — 10:23 pm
© Damicon 2014 Frontier Theme