1. Every software project is constrained by time, budget, and scope.
2. The old truism has it that the customer may choose only two of the three.
2.1. Vendor promises, hype cycles, new methodologies, new tools, artificial intelligence, and silver bullets cannot alter these project constraints.
2.2. In large organizations there is no single customer.
2.2.1. Executives control the purse strings. They have an idea of how long the project should take and how much money they want to spend. But they have only a vague notion of the scope.
2.2.2. Line of business managers have an idea of the scope and the features they want but very little negotiation power on the time and budget.
2.2.3. Therefore, most projects begin with an implicit or explicit decision to fix the time and budget.
2.3. Problems arise when the schedule is determined by the wrong people (senior managers, leadership and executives) at the wrong time (at project start before scope is analyzed).
2.4. Analysis of and negotiations around scope are often left to the software team and the line of business customers who will work with the team.
2.4.1. The software team has no negotiation power on scope.
2.4.2. The customer curates the list of features. This list might or might not be possible to implement within the time and budget. More often than not it represents everything the customer wants along with everything they need.
2.4.3. Therefore, it is rare that the scope is in alignment with the time and budget.
2.5. Even when at project start the scope is triaged, curated, and prioritized the customer’s natural desire to have all of their features can overwhelm the project. This is scope creep.
3. Given a relatively fixed time, budget, and scope creep the project will end in one of three ways:
-
- Senior stakeholders adjust the time and budget.
- Scope is reduced.
- Developers do a death march to close the gap.
4. More often than not, time and budget are non-negotiable. And line customers do not want to lose any of their features. Some money might be found, and some scope might be curtailed. But practically speaking, if nothing substantial is done the death march is the only option left.
4.1. The death march is a fool’s errand and should be avoided at all costs.
4.1.1. Failure to avoid the death march means the team has accepted responsibility for the inevitable slippages that were baked in from the very start.
5. If Agile principles are followed, then there is a remedy.
5.1. The disciplined development team finishes all stories in the sprint.
5.2. The team must work like the proverbial man in the grocery store: stick to the list, no browsing, and move with efficiency.
5.3. At the end of every sprint the working software could be deployed to production if the customer wishes it.
5.4. If these principles are followed then time, budget, and scope are never the development team’s problem to solve. For if time and money have run out the product can still be shipped. And if all features have yet to be implemented, then it is up to the customers to decide what they wish to do.
6. Wise developers distinguish between what they can and cannot control. They work diligently on the former and let go of the latter.
This is the introductory post in a four part series walking through the process of creating a project in Visual Studio and building out a complete CI/CD pipeline to get that code into production on Azure using Azure DevOps.
