Working Agile at The PEER Group

By Ursula McCloy

Our company produces software products (APIs for developers) and uses those products to produce custom software solutions for the semiconductor industry. Some products/projects are run in a traditional waterfall methodology, and some in an adapted Agile methodology; we can't be completely "Agile" for many reasons - stakeholder expectations, the type of software we produce, and our support/integration model for customers. But, for the products we can run Agile, we try!

We're a Microsoft house, so use VSTS (Visual Studio Team System) to capture requirements in "work items" that are associated with a specific iteration (sprint).  In the VSTS user interface, there are several "tabs" that are used to group information associated with the work item; our VSTS administrator created a unique Information Development tab with custom fields in it. 

At the beginning of each sprint, the writer(s) on the product assess its user stories and flag it if it requires some kind of documentation deliverable. Unlike pure Agile recommendations, we seem to have many tasks that don't always impact the end user, like "upgrade the xxx robot driver to include HOME and FACE commands" or "change the logging level of component X to improve performance."

We have a free-form entry field for describing what might need to be done, which document it affects, and any history we want to capture about decisions that were made or outstanding dependencies. This is used both to evaluate the work at the beginning of the sprint and describe the written content we actually produced.

Writers also flag whether the user story goes into release notes, and if it does, write the content as soon as the functionality is finished.  That way, we can run a query right before the product release, and it spits out the release notes for all the user stories.  We do this for bugs as well.  I love it because you can write the content while it's fresh in your mind, and you're not left reviewing 600 work items a week before the product release.

If multiple deliverables are affected by the user story, we just indicate which ones are being worked on. We don't make separate tasks for each deliverable. If there are multiple related user stories for a bigger "epic", we will just attach a task to one of the user stories, and leave the other stories alone. If the total amount of time to complete the documentation exceeds the sprint timeline, we will defer one of the tasks to another sprint, or "split" the task into two and assign to different people within the same sprint. If we don't get something accomplished like we had planned, we'll push the whole task to another sprint.

The actual User Stories are resolved by developers/closed by QA without reference to the documentation work. We sometimes complete the docs work in the same sprint, sometimes not - depending on whether we are dedicated to the project or not, whether we're trying to "batch" work on a single deliverable (e.g., it's annoying to touch the online help every single sprint for a few small changes), and whether the work is completed early in the sprint or near the end. Although this doesn't tie docs to the "Definition of Done", it makes everything work much more smoothly. 

After a few sprints have passed, we'll go through the list of requirements/reported bugs and follow up on any that slipped through the cracks, to make sure every one of them has been evaluated for their effect on the documentation. It's hard when things get too far behind - sometimes developers or QA are no longer available as resources (moved onto another project) and for user-based documentation, we sometimes miss the opportunity to improve shortcomings in the GUI, because it's just too late. 

At the end of the release cycle, we sometimes have content that could be investigated/elaborated upon/improved next release (due to lack of budget, time, or resource availability). We create separate work items for each, and they go into the backlog.  We'll sometimes pull them into subsequent releases if we're not crushingly busy - actually that never happens.  So realistically it's the death knell for anything that goes into the backlog! 

How do I like writing in a more Agile environment? I love it! I've always been able to participate fully in the development cycle of any project – it's been part of our corporate culture since the beginning. But it's the personal interaction, solving issues in real time, and everyone working on a team that is a completely different experience. Would you rather read a 20-page spec, which was written by one person from their limited perspective and out of date the day after it was written, or sit down with the entire team for an hour and figure out how a feature should work? It makes for a better product, better documentation, and a better working environment all round.