The common thread in most advice and critique I receive is around the apparent complexity of managing the dependency tree from the tooling available. The theory behind the dependency tree is not simple. The practice of optimizing the tree using the Gantt generation tool presents a significant technical barrier to many project managers who may not be software developers themselves.
The second category of critique lies in the resistance to what appears on the surface as process overhead and the inertia around and resistance to process change as each organization differs from the practical examples I provide. While this book is an endeavor to elaborate and underscore the principles which are most important, leaving room for an infinite expression of practices, it is not possible to write an infinitely long book of examples. So, I will instead give some thoughts to how we can think about the principles themselves, and progressively iterate toward the Agile Codex method in a low-risk way, both culturally and organizationally.
Tooling
The answer to both difficulties starts with tooling. I have found it easiest during the development of the theory to use the spreadsheet-based generation tool. I enjoy the repetitive literalness of cell formulas, and because I understand the theory of what it is trying to do (and because I wrote it), I can also easily tweak it as I get better ideas.
At this point, I also almost intuitively understand the heuristics around sequencing and assignment to get to the optimal dependency tree. It does not take me many iterations to get to the plan and to adjust the plan. During a typical release cycle, I refresh the chart once a day, make a couple of tweaks at a time, if necessary, and move on. This process is usually less than ten minutes.
I have not used a project management tool which does this tree generation. The process for using existing and powerful tools such as Jira involves exporting .csv files, sorting them, and pasting them into the data area of the Gantt generator. Tweaks to sequencing and assignments made in the Gantt then need to be manually performed in Jira to keep them synchronized – as Jira is the source of truth and board that the engineers work from.
There are also times, especially early in learning the process, when software developers do not structure or maintain the status of their work according to the principles. The grooming process helps influence the structuring in the right direction, and that disconnect has always been short-lived.
As for maintenance, the Agile Codex flow diagram is a great help in distilling responsibilities and has evolved from the need to address process drift in individual engineers over time. But there are always some who simply do not maintain the level of User Story and board hygiene for which the Codex asks.
After generating the tree, it is not difficult to see these hygiene outages because they most often surface as unanticipated gaps in the plan and calendar / effort drift caused by unidentified dependencies or mis-sequenced work. The conversations I have had with the developers when these occur are largely responsible for the efficiency and low overhead of the process as it exists today, as I have iteratively adapted it to be as practically useful as possible in response to their implicit objections.
Both from the perspective of the management and the maintenance of the tree and plan over time, there is no question that there is a lot of room to continue reducing this overhead, and to create feedback loops in the tooling itself to help everyone execute and maintain their work with low overhead and alignment.
Moving forward, I can imagine a Jira plug-in to close the iteration and synchronization gap by eliminating the export / import step and the manual work to affect Gantt changes back to the tooling source of truth. This plug-in would also manage the complexity of applying optimization heuristics to play out and choose between scenarios. Lastly, it would generate useful metrics and reporting, such as the “calendar time / customer value delivered” charts discussed in Chapter 17, “Metrics.”
Synchronization Gap
A plug-in which can directly interact with the project’s core data store would be able to obtain the latest source-of-truth at any time. Provisional updates could be made in the plug-in interface until a scenario is chosen, at which time a transactional update to the core data store could be applied.
These provisional updates could take the form of differences from the core representation, much as a historical, materialized snapshot view would be used.
Using this snapshot approach, multiple points in time could also be stored, reconstructed, and compared with other materializations at any time.
From a user experience perspective, this would remove the export / import step and manual synchronization work, and which in turn would eliminate the risk of errors during manual synchronization steps in either direction.
Heuristics
Blindly iterating through all scenarios in order to optimize a large project would be mind-numbing for a human. Even a CPU which probably does not feel those particular emotions would suffer from the time-intensive nature of the work. Additionally, in most projects there will be a fair number of equivalently optimal scenarios. The perfect optimum would not be able take into account external factors which an algorithm cannot know.
I have found myself using a fair number of basic heuristics, though, which could be provided to an optimizer as metadata for a rules engine.
Who Can Do What
A taxonomy of skill areas, either fixed or dynamic, should be constructed and managed by the system.
Allow User Stories to be characterized according to the skill areas they relate to.
Allow software developers to be labeled according to the skill areas they have expertise and interest in.
Allow software developers to also opt out of receiving work in certain areas.
In addition to skill area, allow skill metadata to also indicate and optimize matches based on the skill level of the User Story and software developer.
Risk Ranking
The plug-in should allow a scoring or ranking of User Stories based on technical risk criteria attached to the User Stories.
How Perfect Is Perfect Enough?
Allow User Stories to be indicated as opportunistic.
Who Is Available, How Much, and When?
Allow software developers to indicate planned time off.
System should account for limited availability of software developers during company holidays and weekends.
Allow one to set percentage availability of a given developer over a given amount of time or set of times.
Factor in availability when scheduling work.
Dials and Knobs for Scenario Planning
Different weightings with respect to specialization, gap allowability, deadline strictness, and risk will generate different optimized scenarios.
Make It Easy to Visualize
It should be simple to see what optimizations contributed to a given scenario in order to apply the “last mile” of human heuristic in the final choice.
Reporting
Snapshots should allow for complete rewind and replay of alternate scenarios.
Between two snapshots, explore customer value delivered versus calendar time versus scope cut. Changes should be auditable on any and all of those axes.
Changes in commitment dates should be trackable.
Requirements escape is surfaced by the creation of a Child User Story during QE and PM / UX Review phases. These should be trackable.
Quality escape is surfaced by the creation of a Child Bug during QE and PM / UX Review phases. These should be trackable.
Lastly, User Story life cycle is more than just DEV work. Time-to-close through QE and PM / UX Review should also be measured and accounted for. While PM / UX Review is relatively lightweight, QE can be more involved and must be balanced with other, asynchronous QE work such as automation, broad product integration testing, and other QE project initiatives. Ideally, QE would be tracking QE work using the Agile Codex method as applied to QE projects, and would emit compatible signals directly to the same system of record.
In all project tracking systems, not only is quantity at a snapshot useful information, even more important is measuring change in quantities over time, and the change in the change as well. Understanding the direction gives the opportunity to monitor and alert on possibly impactful deviations and areas for improvement. It also implicitly normalizes some of the qualitative measures that go into translation of reality to metrics over time.