In custom software development, time will be a key determinant of the success of your efforts. In a fast-paced world, lost time feels difficult – if not impossible – to recover. Three main factors that derail project timelines are scope creep, rework, and external dependencies. All have the potential to accelerate, prolong, stall, or entirely upend a project.
Scope Creep
Though the common term among professionals is “scope creep,” we all know that scope doesn’t change by itself. Rather, we often find ourselves redefining projects and, just as often, such redefinitions are critical for success. Still, the time to redefine a project scope is when we’re working inside our backlog; not during a sprint!
The Project Management Institute cites five key causes for scope creep. To be clear, all are valid. Still, agile organizations focus on thoroughly defining scope within the backlog, so as to not disrupt essential sprint deadlines. The sprint is all about project execution, not project definition.
A healthy product backlog changes regularly, taking into consideration new customer feedback, updated industry trends and internal budgeting discussions. The backlog adjusts with the strategies for achieving business value and supports accelerating your time to market.
Healthy backlog refinement also means the stakeholders are not getting in the way of your software development team. Once the team begins developing a prioritized set of features, they should not be interrupted, with the understanding that those features will be demonstrated to the stakeholders within 2-4 weeks’ time. In this scenario a marketable product often matures faster than expected because the stakeholder and team are in a partnership to develop the most valuable product as soon as possible.
Costly uncertainty inserts itself when the scope of a feature that is actively being worked on by a team is adjusted. In this scenario the team has a difficult time getting footing, having to throw out work, and reset to the newly reprioritized workload. When the stakeholder does not respect the importance of prioritized features and scope is permitted to “creep”, the team cannot efficiently work towards a marketable product.
Like all uncertainties, scope creep has both a cascading and compound impact on project deliverability. A shift in scope often won’t just impact future work, but past work as well, leading to the second key uncertainty: rework.
Rework
By definition, rework is just what it sounds like: having to replicate labor. In agile, however, because there is such an emphasis on speed, rework – to a degree – is unavoidable. Thus, the agile practitioner focuses on whether the project has created unnecessary – rather than necessary – rework. Let’s take a look at the difference.
Necessary rework refers to that which occurs specifically because of customer feedback. The customer has requested something and your team has provided what they asked for. Once the customer has seen it, however, they realize they actually wanted something similar – but not identical – to what you have provided. The customer was unable to make this request, however, without seeing this first version of the feature.
Unnecessary rework, meanwhile, refers to work that needs to be recreated, even though the customer’s wishes have not changed. In some cases, this may be because there was an unclear understanding of the deliverables. In other cases, it could be because the person doing the work simply wasn’t that good or attentive. Regardless, unnecessary rework is the type that you hadn’t planned for, which is why it’s of major concern during a project.
Rework largely depends on your software development process. Minor rework happens in all projects but if it becomes frequent, put a magnifying glass up to it. It is healthy to keep tabs on the frequency and intensity of the rework your software development teams are experiencing. Is the rework related to poor feature prioritization, a weak team member, or an incomplete testing process? As important, when in the process does rework come up with your team? Often being aware of the frequency, magnitude and timing of rework requests can put you on the path for improving rework demands.
Organizations that find themselves with excessive rework should consider the length of their sprints as well. By definition, longer sprints have greater time intervals between customer feedback. As such, the amount of rework that comes out of a sprint review can become exponentially greater than if the sprint period were shorter.
External Dependencies
Conceptually, agile teams rely on a group of people with adequate skills to complete the work required for a given project. Realistically, however, this isn’t always the case and teams will need to rely on resources outside of the sprint team. Such resources are called external dependencies and because they may not participate in daily Scrum meetings or even be aware of how their work impacts the sprint, planning for such dependencies can be difficult.
When deciding on whether or not to use an external dependency, practitioners frequently refer to the Agile Manifesto, which says, “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
Keeping in mind that the “highest” priority is to ship early. Agile organizations should cast a discerning eye to any external dependencies to determine how critical they are to deliver not just software, but valuable software. Obviously, these dependencies sometimes are necessary, but not always.
Similarly, the most productive agile teams do not start a story with an external dependency, unless those providing the work are able to commit to delivery ahead of time. Sprints are short by definition, and work delivered even a day late will set the sprint back from the very start, jeopardizing the team’s mission.
Scope creep, rework and external dependencies all have the potential to derail your project. Preventing each of them starts by turning a critical eye to your past projects. Ask the hard questions: Do you historically adjust scope mid-production, and on a frequent basis? If so, by how much? Are you often unhappy with the end product the team is developing, requiring regular rework? Do you have high employee turnover? Does on-boarding take longer than you expect, every time? Is there one external resource that consistently stalls a project?
Understand the answers to those questions, and you’ll be certain to protect yourself against scope creep, rework and external dependencies – the three factors that consistently threaten delivery dates.
