Bookmark and Share
×

Error message

Notice: Array to string conversion in zephyr_bs3_sass_breadcrumb() (line 22 of /srv/apache/apache2/htdocs/sites/all/themes/zephyr_bs3_sass/template.php).

Information Architecture in Agile Projects

The following article is a guest post to Zephyr from Rodney West, Senior Consultant and the Editorial Director at Isos Technology. Isos Technology is a partner of Zephyr and is the market leader in solving complex enterprise challenges from Agile adoption and QA to DevOps and they help teams improve quality and speed delivery.

Agile projects, by their nature, generate copious amounts of supporting artifacts. There is no way around this. It’s just part of the process. These can be anything brief user notes and discussion threads to complex system diagrams and meeting recordings.

Generated artifacts are essential to continuous project evolution. These artifacts paint a picture of where the project has been, are a map of where it currently is and provide a preview of where it may go. They can make it easier to bring on new resources and avoid pitfalls and dead-ends. Unfortunately, information architecture necessary for for project artifacts is frequently ignored. In an agile project, it would be inconceivable to ignore backlog grooming and solid QA processes. However, historical artifacts are often allowed to grow unchecked.

When: Set aside time

The first, and arguably most important, step to incorporating good information architecture into agile projects setting aside time. Relying on “we’ll find some time” usually fails. Constantly changing requirements will wash away this hypothetical future free time. Would you trust backlog grooming to happen without it being regularly scheduled part of your process?  How about QA? Or daily scrums? There is a reason you make sure these are scheduled properly. Information architecture must be the same. It must be a first class citizen in your projects.

I’m not proposing that you tell your team, “everyone will spend x% of their time cleaning up the wiki.” I’m not even saying you need dedicated tasks each sprint. You just need to map information architecture somewhere in your process, whether that means a few hours each sprint, every few sprints, or even part of the release/post-mortem tasks. It should be done regularly and becomes part of your agile culture.

Where: Decide on a structure

Structure is the second most important part of making information architecture part of your agile process. This is the all-encompassing bubble surrounding all project related artifacts. Design criteria, system diagrams, meeting notes, SOW’s and any other artifacts are included. If it has to do with your project, it is information architecture artifact. Given the wide range of potential element types, you will need to lay out structure and ensure it is adhered to.

Fortunately, there are many tools to help you with structure. Choosing a good wiki with strong, flexible document storage capabilities is a must. If the wiki provides native ticketing hooks, the benefits will be magnified over time. The relationship between JIRA and Confluence is an excellent example of this behavior.

Keep in mind the fact that the landscape of your information architecture will evolve. Make sure your structure and supporting tools can keep information well-organized while being adaptable.

How: Develop a shepherding strategy

We have addressed the (relatively) easier when and where of your agile information architecture. Now we will briefly address the how. This is the most complex and personal part of the process. It includes both what you will retain and what form it will be in. There are three primary approaches:

1. Keep everything in its original state: This is the simplest approach. Once an artifact is added, it will never move. On the plus side, you will always have your full artifact history. The biggest drawback to this approach information growth. Eventually you will have an unnavigable thicket of information. No one will be able to find the artifact they need, and you will have violated the tenet of adaptability.

2. Purge outdated artifacts: This very tempting approach involves the removal of artifacts from your information architecture as soon as they become outdated. Following this strategy can result in a streamlined ecosystem with readily accessible information. Unfortunately, this approach includes the inherent loss of historical information potential for accidental deletion of key artifacts.

3. Use a versioning/archiving strategy: This strategy retains all the original artifacts. When artifacts become obsolete, they are archived. This provides the best parts of the other two strategies. You retain historical artifacts while maintaining an environment with easily searchable information.

Conclusion

If you are using agile, you are hampering long-term project maturity if information architecture is not part of your process. Regardless of the when, where, and how you adopt, your deliverables will be much stronger once you make information architecture a first class citizen of your projects.

Author Rodney West: Rodney West is a Senior Consultant and the Editorial Director at Isos Technology. He has over 17 years of experience in Software Development, Software Architecture and Technical Leadership in a wide range of industries. His approach to software development focuses on the interaction between corporate culture and development processes in the delivery of software.