by Dov Rosenberg –
I recently did an assessment of a Global 100 company’s software development process. The goal of the assessment was to try to determine why they continued to have delayed releases and P1 and P2 problems creep into their production sites in spite of all of the processes that they had in place to prevent them. This company had all of the buzzwords in place: change control boards, peer code reviews, agile development, automated regression testing, continuous builds – you name it, they were doing it. But still, the releases kept getting delayed.
Investigating Delays
During our investigation, our team talked with a wide range of people involved in the SDLC. We talked with developers, tech managers, QA testers, test automators, product managers, release managers – they all had their own viewpoints and opinions of where the root causes were. In many cases, they tended to blame the processes outside of their control.
Work in Process Analysis
With this background information, we dove into some detailed analysis of their processes. We found some interesting things.
Work in Process Analysis
We measured the number of user stories in 3 different sprints for a randomly chosen sprint team (out of 35 different teams). We were interested in the effects of unplanned work on the performance of the sprint team. Figure 1 shows the results of our analysis. We started with the number of user stories that the sprint team added on the first day of their 2-week sprint. We then looked at the number of user stories that were assigned to the sprint at the end of the 2 weeks. The blue bar represents the number of stories that were added AFTER the first day of the sprint. The gray bar represents the number of stories that were originally planned for the sprint. The orange bar represents the number of stories that were incomplete at the end of the sprint. In many of the cases, the stories that were left over at the end of the sprint were NOT the ones that were added after the sprint started.
So, the $64,000 question remains – who made the decision to add the stories to the sprint? And why?
Immediacy versus Urgency
At the end of the day, the Product Owner is the arbiter of what gets done in the sprint. But WHO influences the Product Owner? Turns out there are several potential answers to that question.
Consider these scenarios:
- The Product Owner is in the elevator with her boss and a Senior Vice President and overhears a conversation that happens to involve her sprint team. The SVP casually mentions that one of their biggest customers called him up and asked when Feature X is going to be delivered. The Product Owner knows that Feature X is scheduled several months in the future. The Product Owner decides that it wouldn’t hurt things to shift the schedule around slightly to deliver Feature X sooner.
- The Tech Lead of the team discovers the root cause of an intermittent performance bug that he has been chasing for quite a while. The fix will require a lot of re-work in order to correct the problem. The current production site has been stable for the past couple of weeks, but the busy time of the year is coming up and the servers will get slammed.
- The sprint team has been working on a project for several months and continues to miss milestones due to bugs in the code and the overall complexity of the project. As a result, the schedule is in danger of going past the required due date and the team has eaten up all of the budget with several weeks of development remaining. The due date can’t be changed, so the Product Owner/Manager starts to de-scope the project.
All of these scenarios can be used to justify the reasons why projects slip and go over budget. But the real question becomes:
Is the change considered URGENT? And must it be done immediately?
All features and defects can probably be considered URGENT by someone AT SOME POINT IN TIME or else why bother working on them to begin with? The key part of that statement is TIME.
Urgency is really a measure of the overall business value of something. That value can be measured by cost savings, incremental revenue, increased performance, improved customer satisfaction, or any number of metrics. The higher the value of the change, the more urgent the business should consider making the change.
Immediacy is really a way to stack rank all of your urgent priorities against each other to determine which should be done first. Your boss may give you 10 things to do that are all due tomorrow. You can stack rank them based on complexity, cost, or level of effort. There is a better than average chance you won’t get everything done in time, so your goal needs to focus on getting the highest value work completed first.
Many times, people fail to understand the subtle differences between Urgency and Immediacy. If your boss’s boss asks you when something will be done, it is probably a lot different than if your peer asks the same question. The rank or title of a person can have a direct impact on how the immediacy of a change should be handled. In many cases, the higher-ranking person is not even aware that their innocent hallway or elevator conversations may cause collateral damage to a project simply because of something they said.
Managing Priorities and Managing Change
Project Managers and Product Owners have to have a strong sense of the priorities of their stakeholders. They need to manage these stakeholders and not be too quick to say YES. Just because a project uses agile methodologies that are designed to be flexible doesn’t mean that uncontrolled change is allowed or desirable.
If you continually have projects running behind schedule and over budget. Take a long hard look at the decision-making process of your teams. You may be surprised at what you find.
