On two different projects, for two different clients at two different stages, we found the same difficulty: a scrum board and a set of design pages did not make the current position clear enough. Projected progress was unclear too.
Better organisation helped. But once a problem was visible, more administration was not necessarily the way to solve it.
Use checklists to make gaps visible
We used point-of-view checklists to help stakeholders review a solution. A security checklist, for example, could name the important requirements and link each one to the relevant design and user stories.
This reduced gaps between expectations and delivery. It also made reviews faster: a stakeholder could see which stories were still open, rather than reconstructing the position from several different sources.
Design checklists helped confirm that design pages still agreed with the work being done. Documentation should describe the evolving system rather than become an archive of decisions that no longer apply.
Inspect what is actually running
There are diminishing returns from trying to relate planning material to reality. A running service can be inspected directly. A service running in a suitable production environment can be inspected without having to explain the quirks of a development setup.
A preview version can support this without replacing a stable version that other services depend on. The useful question becomes what is already available, rather than what a project plan says is finished.
Describe the work as services
Breaking a project into layers of services makes dependencies easier to understand. Some services already exist, some your team will create, and some depend on work by others.
A dependency on another unfinished service introduces uncertainty. Integration testing can help, but it has a cost. Where an existing production service already provides the required functionality, using it can greatly reduce delivery risk.
Change the architecture when the architecture is the problem
A checklist may reveal that a data platform needs to move several terabytes quickly. It cannot make the network provide that throughput. It can make the requirement visible, identify who provides the service and show what must be demonstrated before the dependency is reliable.
Likewise, repeatedly raising tickets for access to a source system has a different delivery risk from using a reliable self-service mechanism. Better reporting can expose the delay; a better service can remove it.
Managed database services gave us another example. Work that would otherwise consume days maintaining backups could be handled by the underlying service, changing the amount of effort required to operate the solution.
Be organised enough to find the real problem. Then look for an architectural solution before investing in ever more detailed administration around it.
This article comes from Cloud BI Limited’s consultancy years. Today we are building our own products under the youmightaswell brand, starting with Hours.