Agile Development Series - Agile Hierarchy Conclusion
Introduction
In my previous blog article, "Agile Development Series - Epic Hierarchy Is Needed", I introduced the idea of incorporating a hierarchical structure into agile project management tools. This concept aimed to offer a more comprehensive view of a project by tracking its completion relative to the features being developed. However, after further reflection, I’ve reconsidered my stance. While I still see the potential benefits of such a layout, I now believe that agile tools may not be the ideal platform for it.
Separation of Concerns
In software development, the principle of separation of concerns is critical. It posits that a software system should be broken down into distinct sections, each handling a specific concern or responsibility. This approach reduces complexity, improves maintainability, and enables parallel development.
When it comes to agile project management tools, the primary objective is to facilitate the planning, tracking, and reporting of work items—such as epics, stories, and tasks. These tools are tailored to support agile methodologies, offering features like sprint planning, backlog management, burndown charts, and velocity tracking. Their design is optimized for team collaboration, transparency, and adaptability.
Over the past year, since my initial blog post on this topic, I’ve come to a new realization: the hierarchical layout I originally proposed might not be the best fit for agile project management tools.
Reassessing the Hierarchical Layout
The challenge I’ve encountered in many agile projects is the lack of a clear, visual representation of a project’s sub-components in a hierarchical manner. A breakdown of the project’s architecture, overlaid with status indicators, can be invaluable for understanding progress, identifying bottlenecks, and making informed decisions. However, the architecture of a solution often doesn’t map cleanly to the project’s breakdown of epics, stories, and tasks. In other words, the architectural structure of a system is rarely a one-to-one match with the project management hierarchy, regardless of the tools used.
This realization has led me to reconsider the placement of such a hierarchical feature. Instead of integrating this layout directly into agile project management tools, I believe it would be more effective as a standalone tool or artifact. This new tool could complement existing agile (or even waterfall) platforms by linking project-level tasks with the architectural components of the solution.
By doing so, it would offer a more holistic view of the project’s status, highlighting the completion of features, components, and sub-components. Furthermore, it could visualize potential hotspots, bug counts, and other metrics at the architectural level, enriching the overall project management experience. Ultimately, what I’ve learned is that there needs to be a clear separation of concerns between project management tools and architectural visualization tools.
In the following image, I have defined a standard microservice architecture.
Imagine the same architecture with an agile project status overlaid. The gray components represent areas with no status. The numbers and component backgrounds represent how many stories have been completed vs assigned. This concept is represented in this image.
Conclusion
In conclusion, while the idea of incorporating a hierarchical breakdown into agile project management tools initially seemed promising, I’ve come to realize that this might not be the best approach. Instead, the solution likely lies in the development of separate tools that integrate seamlessly with agile platforms. These tools could offer detailed architectural insights, enabling teams to visualize project components and their statuses at a granular level without disrupting the core functions of agile project management.
By maintaining a clear separation between project management and architecture visualization, we can ensure that each tool remains optimized for its specific purpose while still providing a comprehensive and integrated view of the project as a whole.
Ernie Paschall