Scientific Agile

Over a year ago I stated that there were programming process artifacts coming soon. Well I'm happy to state that the first two such documents are available here. One is a development workflow standard operating procedure for enhancing standard agile scrum practice. The other is some basic code style rules. Notice that these are contained in a repository called afterecon-2.0 because I am updating the site soon.

The development process includes a triple estimation procedure which points toward my disposition for agile. I think metrics can be used more heavily. I'm aware that less metrics sometimes improve productivity dramatically, but I'm also aware that having high productivity without a strategically determined goal is potentially a low value proposition. Worse yet, it is a potentially low value proposition which is unable to identify itself as a low value proposition.

Scientific agile relies heavily on metrics and it allows for high-precision value identification and high-confidence timeline estimation. It is possible to carve out blocks of time within a scientific agile project and act as a kanban project during those blocks, but I always recommend cycling back toward the metrics to realign periodically.

Triple estimation involves t-shirt sizing, prospective points estimation, prospective hourly estimation, and retrospective analysis once actual hours are captured. Over the course of several sprints, a natural alignment emerges between points, t-shirt sizing, and hours. This allows hour-level forecasting in a reliable way. Triple estimation, however, is just one element of a scientific agile approach.

Scientific agile also makes use of normalized story naming and tagging, as well as normalized task naming. The result is even more precise estimation of tasks and stories. Estimation and productivity data can also be used for human resource performance review.

Other aspects of scientific agile include experimenting with process change and measuring the productivity impact, creatively querying JIRA for interesting metrics to see whether they can be predicted, like identifying whether certain kinds of features have more bugs logged against them, leveraging continuous employee survey to ensure a quality work environment and continuously search for productivity, cost or other improvements. Metrics can also be pulled from GitHub or other repositories.