In a conversation recently, I was reminded how being agile is awfully like being pragmatic.
We were talking about topics of interest to project managers like estimation and forecasting and measurement.
One of the topics discussed was about grooming the backlog, and backlog sequencing strategies: Walking Skeleton vs. feature by feature? Do you build just bones, and then add the skin? or do you build one complete body part at a time.
Another topic was about “sprints as phases”: requirements works a sprint ahead of development, testing works a sprint behind – this strategy might work for a longer duration effort (many sprints), but not as well for a shorter duration (4 or less) – it might drive you to more shorter sprints than fewer longer ones.
Yet another topics was about planning margins or slack. Budget or Schedule margins are not on the surface agile concepts, but when they are valuable or necessary risk management tools, they must be implemented in ways that do not interfere with measurement. A budget margin implementation means that I have the ability to spend more but stay on schedule. Pragmatic strategy for that is to overstaff at the beginning, and reduce staff as velocity stabilizes as sufficient, and risk is retired. Adding staff in the middle of a project decreases the stability and predictability of the team.
Our last conversation was about choosing a sprint length. Sprint lengths should be consistent – so that the measurement (velocity) is useful for projection. Sprints should be immutable – once a sprint is started, it cannot be shortened or lengthened. If there is a need to have “variable” length sprints then a shorter consistent measurement period should be adopted (weekly) so that the feedback loop doesn’t elongate. Last, the shorter the overall project, the shorter the sprint size – again, so that the feedback loop is timely enough to make adjustments.
There is no one right way – just ways that make more sense and ways that make less sense. We all learn more from failure that we do from success – but using a framework that fosters timely feedback and rapid adjustment provides ability to see failure coming and get better faster.