Get Yer Heads Out of Your Agile
For the past few years, both on customer projects and also on internal development projects, we have used the Agile Methodology*
I add the asterisk because no one seems to agree on what exactly agile should be, and no team I’ve ever seen (even within an organization) does it the same way.
What is called Agile Methodology* tends to boil down to:
- Use Jira
- Assign work in manageable chunks of time called Sprints. (Sprint length will definitely vary.)
Managing work through Jira is effective and things get done. Bugs and remediation are handled efficiently as well. These are good things, and there are lots of upsides to Agile* which is why it has caught on, but as someone with a few gray hairs and time in consulting I’ve found something missing. What I find missing in most agile projects is the big picture documentation. Full disclosure, I have a degree in English and began my career as a technical writer working in traditional waterfall projects. That said, I miss the SRS and SDS documents.
The SRS and the SDS – the System Requirements Specification, the System Design Specification – these are big documents that take a lot of time and effort to create.
They are useful, but costly, and large documents like these are the reason people do Agile in the first place. They represent a front-loaded effort to design a solution. They take a lot of effort to create and maintain. Agile dispenses with them, managing development projects through iterations. The problem I’ve seen is that without a big picture document, people spend most of their time looking at the trees rather than the forest. This can also be compounded on projects with multiple dev teams. If one hand doesn’t know what the other is doing, you end up with an inefficient system.
Solution? It falls to the Project Owner to work with the Project Manager to make sure that context is included with tickets. Empower business analysts to make sure the Why of a change is included in the ticket. Combine this with creating more verbose epic tickets that make it easier to see the big blocks of the project and you’ll move a long way towards improving awareness on your teams, without the monumental effort associated with heavy documentation.
Rule of thumb: When writing and updating tickets, if 30 seconds more time providing a bit of context will save me an HOUR of reading related tickets and all their comments, for God’s sake, PLEASE DO!
Author
