Unagile Sprints
Categories: Programming
While “agile” software development methodology isn’t precisely defined anywhere (covering a family of methods rather than just one), a common practice is to do development in short regular time-periods named “sprints”.
Unfortunately, there is a common misunderstanding of sprints : they are often treated as “mini waterfall” cycles. This is not beneficial.
Sprints are meant to ensure that the project returns periodically to a releasable (ie production quality) state. Ideally there is a customer who will actually deploy the new version of the product every sprint cycle too; that brings the customer regular benefits while providing the development team with real-world feedback soon after new features are implemented. However even if that’s not the case, at least the end of each sprint delivers something that the customer or customer-representative can experiment with, and provide guidance back to the development team.
The actual features that are delivered at the end of a sprint are not that important; everything that is ready by the end of the sprint goes in, and everything that is not ready must be disabled, removed, or if development is done on feature branches then simply not merged into the release. And “ready” must include being properly tested and documented. The critical thing is to have a production quality product at the end of each sprint.
Regularly returning to production quality state automatically balances the development process, by ensuring that the same amount of progress is being made in testing, documentation, and packaging as there is in coding. A project that produces code faster than it is being tested is in deep trouble.
What did I mean by “mini waterfall” cycles above? I mean the unfortunately common practice of attempting to allocate issues to a sprint, in the sense of requiring developers to provide time-estimates for each issue, then calculating the maximum set of issues whose estimates fit within a sprint timebox, and then promising external parties to deliver those features at the end of the sprint - and criticising developers who “fail to meet their deadlines”. Projects managed in the old-fashioned Waterfall process work like that : a large list of features is generated by business analysts, divided up and estimated by developers, promised (along with a delivery date) by marketing - and then never delivered on time (and sometimes never delivered at all). In some ways, “mini waterfall” cycles are better than full waterfall in that the individual issues are smaller, tend to build on existing features, and are estimated based on recent experience rather than being estimated right at the beginning of the project. On the other hand, in a short development sprint with a small team, things like sickness or being called up to deal with bugs in existing code can have proportionally greater effect on the whole cycle.
What is the alternative to “mini waterfall”? It is to simply rank issues in priority order, and then for developers to do their best. Priority order is something that the customer or customer-representative can do well for visible issues, and that developers can do well for internal issues (unlike time estimates). Issues which are prerequisites for other issues or other teams should of course be given high priority - but not fixed deadlines. In the end, to “do their best” is all that can be expected of anyone, and imposing deadlines doesn’t cause any more work to be done, it just increases the associated stress. Push too hard with a fixed deadline, and all that will happen is that estimates will be padded (to cover the ever-present uncertainties of development), or quality will be compromised.
Agile methodologies (eg Scrum) do include a phase of estimating items in the “backlog”. However this is primarily to help in choosing the priority order, and not meant to be promises of delivery dates. This is why some methodologies recommend estimates be made in “story points” rather than days-of-effort.
In summary: don’t assign issues to sprints; instead create a priority-ordered list of issues. Have this list contain a few more issues than it is possible to complete in the upcoming sprint; a longer list is pointless. However don’t expect that all items on the list are completed in the sprint - instead, let the team do their best. But above all, ensure that at the end of the sprint the product is in a releasable (production quality) state.
If dealing with management or customers who simply cannot handle the concept of a “priority-ordered list”, and insist on “promised features” then it is possible to give the top few items from the priority list; as they will be worked on first (and hopefully each issue in the list is sized to be easily implemented in a week or so, even given the unexpected) then this should be reasonably safe. Of course, the longer the list of promises, the greater the probability of not meeting all of them - so leave the maximum possible margin. In marketing this is known as “underpromise and overachieve”; a good principle to follow wherever possible.
This view isn’t universally held; some people seem to claim that it is possible to predetermine the set of features that will be implemented in a sprint. However to paraphrase a well-known principle : “schedule, quality, features : pick two”. Fixing the schedule and the features can have only one outcome!