A Milestone approach to deadline driven projects – Part 1
When you pick up one end of the stick, you pick up the other. The term “feature driven” is usually associated with Agile and the term “time driven” is usually associated with waterfall. Every project has Features that produce value to end user and a date when the these features are completed and their value is unlocked.
There are two leading methodologies you can choose to define software development process. First is waterfall which is a sequential model where software development is segregated into a sequence of predefined phases including feasibility, planning, design, build, test, production, and support. Second is Agile methodology that follows a linear sequential approach while providing flexibility for changing project requirements, as they occur.
In Agile world, a project will be delivered by you into production when it reaches to a point where value is unlocked. It is fine to compromise on time.
In Waterfall world, a project will be delivered by you into production when it reaches a certain date. It is fine to compromise on features.
Why not deliver all the features within a specific time limit? Well, you cannot because you are restricted by the theory of constraints.
As per above notorious triangle, you have multiple teams of fixed size. You can only throw that many resources in each team for a project that does not violate the law of "weakest link in chain". This constraint pretty much limit your options to be either "feature heavy" or "time heavy".
You have many teams and each with their unique capacity to deliver their outcomes. It is important that you clearly define piped bandwidth of each team and remove any congestion in outcome pipe.
Now If you picked up the “feature” stick , CONGRATS !!!. You are on your way to Agile. Get your sprints started. May the dark forces that feed on deadlines never cross paths with you. You can immediately stop reading further as this blog post does not apply to you.
If you picked up the "Time" stick, you have my empathy. Because you ended up here it is better that you make below disclaimer to all your stakeholders.
You are executing a "deadline or schedule" driven project and process is NOT AGILE.
Then take a deep breath and chant "mini waterfall, mini waterfall, mini waterfall". Anyone telling you anything else is playing you out. You have picked up a stick with "NOT AGILE" written all over it. If this clarity of thought does not exist among your stakeholders then tensions start escalating among them such as:
- Your engineering and business owners can’t agree on how many features can be completed by the deadline.
- Your user Experience aka UX team, as creative they are, assume that law of time does not apply to them. Misinterpreting waterfall as Agile, you start bringing changes to a project iteratively which has dooming effect to most real world project with time deadlines.
- Your engineers feel that UX and business owners refuse to acknowledge that a change requested to already agreed scope is almost always greater than either of them assume at their end.
- Your business owners believe that all changes are simple (adding a button, changing the layout or simple reporting) and can be done if engineers are willing to work a little harder.
And that is how trust is LOST among your stakeholders.
Go back and see the top of the triangle. It said "Quality" right? To deliver quality features to production, your teams need to agree on factors such as scalability, stability, security, maintainability, performance, and extensibility. These fancy engineering terms often trip non engineering stakeholders in your teams and all hell breaks loose. Your teams dig out old emails, torture any data they can to misrepresent their perspectives. You witness this getting ugly and things do escalate quickly, some teams become scapegoats, some team members leave the organisation, project never gets delivered, new teams are formed and the cycle is repeated endlessly while your end users wait indefinitely.
But it need not be that way. In the part 2 of this blog, you will be introduced to a term called "Milestone approach" which is proposed as a creative solution to manage deadlines. Please note this is waterfall process and any similarity to Agile is purely coincidental. There are two things for you to remember:
Time is FIXED: When stakeholders ask you to deliver by a specific date, you must accept that any scope changes, however necessary they may be, will always have impact your deadline.
Estimation accuracy: A predictable schedule requires accurate estimates hence your teams must make best efforts to furnish estimates, with uncertainty stated in time ranges, and in time units (e.g. hours, days, or weeks) appropriate for that uncertainty. This will help you with scope refinement.
In the part two of this series we will take a look at milestone process and explain how you can apply the process in your projects.