Kris inspired this post with her musings on doing UX in an Agile environment. Echoing her concerns, here are some lessons I learned working as a writer in that setup. Agile emphasizes on minimal planning and doing things at short intervals or iterations. In a way, every iteration has a specific, measurable goal, which is usually goes like this: complete X by the end of 25 March. If that goal isn’t fully achieved by that date for whatever reason, it is deferred to the next iteration. So, if X was only 75% achieved, 25% is deferred to the next iteration.

In my experience, Agile worked great for the developers and QA/testing folks but not as well for the UX and documentation folks. The primary reason was the constant flux in what emerged when an iteration ended. For example, if feature A was completed at the end of iteration 3, I’d document it the way it was looked (the user interface) and worked. However, in the planning meeting for iteration 4, somebody would point out that some UI element for feature A needed to change. Now I had to redo the documentation for the same feature in iteration 4. Additionally, in the same planning meeting, somebody else realized that a feature already completed in iteration 2 needed an enhancement. They’d put that as a task in iteration 4. I now had two repeat tasks. Add to this, every iteration typically had documentation reviews by these cross functional teams. Now, because each iteration typically lasted for 3 weeks at the maximum, the review task would be deferred to the next iteration. This meant I couldn’t mark my writing task as complete for the iteration although from a purely writing/authoring perspective, it was, indeed, complete. The resultant confusion for the writers bordered on chaos simply because it was too hard to keep track of what was going where. Kris explains this quite nicely:

I think when it comes to restructuring the workflow of a product to make it significantly better, executives need to understand there is a time for Agile, and a time to redesign, and redesign efforts take more in the range of 2-6 months to complete, in my experience. It all depends on how much is “surface” redesign, such as moving things around on the pages and creating a nicer look and feel vs. how much the deeper code has to be modified because features need to work completely differently than the developers designed them.

And nails it accurately here:

Do we need the internal motivation of a release every 4-6 weeks to make things happen? Customers don’t necessarily demand a release once a month, they just need bugs fixed and problematic features redesigned so they can perform their tasks better…Why do we have to release something once a month?

In other words, efforts to “quicken” the time to market shouldn’t compromise the “big picture” of the product. Ultimately, any product is the sum of its parts. The efforts should, really stay focussed on incrementally improving the product–in an Agile mode or no–than on making newer releases purely for its own sake, or worse, by a fear of the imaginary market monster.

In the end, the documentation folks were nicely frustrated. You can begin documenting a product if these conditions are met at the minimum:

• A reasonably stable feature set
• An interface that’s at least 80% frozen

Writing in our industry typically involves explaining things to other people. The better the writer understands what he is writing about, the less he has to rely on other folks for technical/product inputs. And to better understand, the writer needs to work real-time with the product that doesn’t change with every iteration. Ultimately, we solved the problem by beginning the actual writing work quite late in the game–that is, when we were reasonably sure that everything was pretty stable and changes would be minimal but we were present in the daily scrum, planning, and iteration-end meetings.

The biggest takeaway personally from Agile was how it offers a ruthlessly-close project tracking mechanism, and the scope it provides to build great professional relationships because you’re a small but tightly-knit team working really closely.

Tags: Agile, Agile in UX, Kris on Agile, Software Development, Technical Documentation, Technical Writing & Agile, Technology, Writing in an Agile Setup