We are used to natural numbers and we avoid thinking in fractions. When we evaluate the time necessary to execute a task, we assign one unit of time to simple task. We assign 3 units of time to complex tasks to be able to implement, test and correct. We add more units of time when we feel uncertain. The further along we plan, the longer we will estimate the time required to accomplish a task.
The further along we plan, the longer we will estimate the time required to accomplish a task.
As the unit of measurement is reduced, the precision and accuracy are greater. Software development is never straight and forward, there are always complexities and unforeseen events. This reminds me of the coastline paradox (https://en.wikipedia.org/wiki/Coastline_paradox)
If the coastline of Great Britain is measured using units 100 km (62 mi) long, then the length of the coastline is approximately 2,800 km (1,700 mi). With 50 km (31 mi) units, the total length is approximately 3,400 km (2,100 mi), approximately 600 km (370 mi) longer.
This could explain why we sub estimate the cost and effort of long term projects as we follow long term plans. Planning months ahead leads to projects with higher risk of being months behind deadlines. Miss two sprints and we are at least two months late. Trying to bring the project back on track implies the duplication of efforts for at least the same length of the deviation. In some cases this would be impossible as people can’t work 16 hours a day for a month.
Executive plans are short term plans detailing concrete tasks. Each task is similar to the OKR (https://en.wikipedia.org/wiki/OKR) framework unit, a clear statement of a single objective and its key results. We need to break down tasks that take longer than one sprint reducing the complexity to the maximum. We know we have broken down the task enough when we can clearly state its goal and clear key results indicating its success. Breaking down tasks reduces their complexity. Complexity reduction leads to less errors and therefore less work.
Breaking down tasks allows us to distribute the load between participants accomplishing more in the same period of time. Imagine an empty jar. If we try to fill it up with stones, we will see a lot of gaps. Break the stones in small pebbles and put them back in the jar and it is not full anymore. Reduce the pebbles to sand and we will be able to fill the jar even more. The same efficiency can be achieved when we break down our tasks.
“Release early, release often”
The reasons behind the success of the Linux operating system and many opensource projects was described by Eric S. Raymond in his essay “The cathedral and the bazaar” in which he explains the importance of frequent and early releases.(https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar)
Release early, release often (also: time-based releases, sometimes abbreviated RERO) is a software development philosophy that emphasizes the importance of early and frequent releases in creating a tight feedback loop between developers and testers or users, contrary to a feature-based release strategy. Advocates argue that this allows the software development to progress faster, enables the user to help define what the software will become, better conforms to the users’ requirements for the software, and ultimately results in higher quality software. (https://en.wikipedia.org/wiki/Release_early%2C_release_often)
We can “release early, release often” by incremental releases correlating them to weekly sprints. When executing these sprints we use a daily progress control cycle that allow us to detect deviation and take early corrective measures.
Shorter Beats Longer
A “good” Sprint Length then, has to be long enough to produce results, but short enough to limit risk.
Working on well known deliverables makes the difference between doing what you know and knowing what to do.