Tag: Prioritization
Just Rebuild It – Tales from the Trek – We Don’t Need Requirements
Technology Upgrades – Self Documenting (?)
I’ve been on several projects where the goal is to replace an existing, mature system with a brand new system in a new technology. This is generally a huge investment in time and money, fraught with risk, and results in almost the same functionality. Still, it can be necessary due to the old software being dependent on unsupported or non-secure technology and exponentially increasing maintenance costs. In a way, it’s like making the decision to replace an old car rather than repair it.
On nearly every project of this type that I have experienced, the project sponsors have insisted that we could cut out, or at least drastically reduce, business analysis. Their reasoning was that because the new system simply had to work exactly like the old system, the new system was already “fully documented” in the form of the old system.
There are a number of reasons why assuming that the old system “fully documents” the new system is a mistake. I’ll address one of them here.
Rebuilding Bugs and Poor Functionality
Often, software that’s running on outdated, unsupported technology has a lot of bugs and poor functionality that haven’t been addressed. Any changes to the system have become risky because the system is so fragile. If the only direction given to the development team is to rebuild the existing system as is with no additional analysis, the team will literally be building the same bugs and functionality into the new system. There’s no good way for the development team to know if something should be changed without at least some investment in business analysis.
The end result is that the users and project sponsors are even more frustrated with their investment in new software only to end up with the same problems. Even worse, sometimes, building the bugs into the new system costs more money. Imagine how much more it would cost to try to literally rebuild an old car exactly as it is rather than build a new car with the same basic functionality. It would take effort to make the brakes squeak just like the old car, have it shake at high speeds just like the old car, and randomly stall in the middle of intersections just like the old car.
The money spent rebuilding old bugs would be much better spent on some business analysis.
Feedback
What challenges have you had with generating requirements when replacing existing systems? What actions have you tried to address the challenges? I’d love to hear your stories from the trek.
Prioritization and Quality – Tales from the Trek – The Hoarders
Impact of Prioritization on Quality
As I’ve mentioned before, a key aspect of building quality software is ensuring that it does what the users need it to do. In my experience, the backlog of feature request (whether written or held in the stakeholders’ heads) is always much larger than what the development team can build in a short period of time.
When the backlog gets too big, people could spend more time managing the backlog than actually building anything. What is more likely, though, is that most of the backlog is ignored, and the clutter causes great ideas to get lost. I have seen cases where key customer issues ended up unaddressed for months until the customer complained a third or fourth time.
Idea Hoarding
I sat down with one of my clients to look at their backlog, and we found that they had over 400 backlog items that had not even been viewed for more than a year. They had more new, high-priority work coming in than they could deliver, so their backlog was growing. Clearly, nobody was ever going to review, let alone work on, the items that were over a year old. I suggested simply closing the backlog items that hadn’t been touched for over a year, but the client didn’t want to remove any items from the backlog without first reviewing them in a meeting with a team of key people, which was not going to happen.
The discussion reminded me of an episode of Hoarders where they were trying to convince someone to sell most of his 27 tool boxes. He agreed that 27 might be overkill, but he still didn’t want to sell them and insisted that the average person, who wasn’t a handyman like him, would need at least 7 toolboxes.
Time to Declutter
When a backlog gets hopelessly large, you may want to consider declaring backlog bankruptcy (based on the concept of email bankruptcy) and simply close all items that haven’t been looked at in over a year. If that sounds scary, I can understand. I tend towards hoarding myself, and I hate the thought of getting rid of something that might come in handy later. If declaring backlog bankruptcy, it may help to keep these ideas in mind:
- When there are too many backlog items, they are all ignored. The best ideas can’t break through the clutter.
- Business changes so quickly that most ideas more than a year old aren’t relevant any more.
- If an idea in the backlog is truly that important, it will get entered as a new entry again. In fact, if it’s that important, it probably was entered multiple times and has already been implemented.
- You can always search on closed items if you really, really want to!
Keeping the Backlog Under Control
Once you cleaned up the backlog, you want to try to keep it manageable. It helps to have a weekly triage process where the items are reviewed and prioritized. Some decisions that should be made during the triage process are:
- Is there any realistic chance this item will get resources in the next year? If not, close it.
- If the item is going to remain open, assign it to an owner who will take responsibility for getting the item onto the schedule.
- Enter the date the issue was last reviewed.
- Assign a priority and effort to the item.
I’ve found that it’s easier to identify which issues to review if you create a report that shows the priority of each item, the date it was entered, and the date it was last reviewed. This type of report helps ensure that older items are addressed.
Feedback
What challenges have you had with backlog clutter? What actions have you tried to address the challenges? I’d love to hear your stories from the trek.
Prioritization and Quality – Tales from the trek – Priority 0
Impact of Prioritization on Quality
A key aspect of building quality software is ensuring that it does what the users need it to do. In my experience, the backlog of feature request (whether written or held in the stakeholders’ heads) is always much larger than what the development team can build in a short period of time. However, prioritizing these features seems to be difficult for people. Everything seems important, so everything gets priority 1.
Of course, if everything has the same priority, the stakeholders are de facto allowing the development team to prioritize the features. This can be a problem because the development team often doesn’t have the visibility to all of the factors that may determine the importance of the feature to the company’s success.
Here’s one example of a client who had an issue with prioritization, and how we arrived at a working solution.
Going Live too Early
A client had a new system replacing an existing business critical system. Unfortunately, their existing system had reached its technical limits before the new system was fully tested, and management made the decision to go live without much testing. Of course, the results were predictable. There were many errors in a production system that had to be fixed right away.
The “prioritization” method initially was that end users would come into the room of developers and tell them that they needed to drop everything and work on whatever issue the end user mentioned. The problem was that many different users were coming in each hour, and the developers didn’t get a chance to finish any task before being told to drop it and work on something else.
Getting Organized for Quality
The first thing we did was set up a SharePoint list where users could report their issues. We created a process where the users would report their issues in SharePoint. Then, I would triage the list and assign the work to developers. This simple improvement resulted in a huge increase in productivity for the development team because they could complete tasks without interruption.
However, we weren’t always working on the most important issues. Users were choosing the priority, and every issue was the highest priority to that user. Even when we met with representatives from all departments together and set definitions for priorities, every issue was priority 1 on a 3-priority scale.
Priority Names Matter
Our original 3 priority levels were called “High”, “Medium”, and “Low”. Because all issues were production issues, people didn’t want to minimize any by calling them “Medium” or “Low”. Everyone agreed that the issues were not all the same priority, but they weren’t willing to prioritize using those names.
First, the client came up with a category called “Priority 1 – Urgent”. This was higher than “Priority 1” and the client felt comfortable putting some items in Priority 1, and some in Priority 1 – Urgent. Still, way too many items were in Priority 1 – Urgent, so the development team was still choosing the priority.
Then, the client decided that the most critical items would be in a new priority called “Priority 0”. This was reserved for the top 5-7 issues to be worked on immediately by our 5-person development team.
This worked! The client was completely willing to prioritize into “Priority 0”, “Priority 1 – Urgent”, and “Priority 1” even though they were not willing to prioritize into “Priority 1”, “Priority 2”, and “Priority 3”. Just by changing the names of the priority levels, we were able to accomplish the goal of dividing the issues into 3 different levels.
We could then focus on the issues that brought the most value to the system.
Feedback
What challenges have you had with prioritizing features? What actions have you tried to address the challenges? I’d love to hear your stories from the trek.