An Agile environment offers many benefits (and challenges) to the company, to the technical writers, and to end-users. It is, without doubt, a challenge in and of itself because each sprint, each chunk of time between deliverables is much shorter than in a standard, non-Agile development cycle. Where once we planned 6-8 months ahead (and sometimes even longer), now we speak in intervals of two weeks to four weeks. We don’t speak of dozens of new features, but of a handful at most. In Agile, we are tasked with working within tight and regular deadlines. Before focusing on the challenges (another post), I want to focus first on the benefits, and there are many.
For the Company:
- The best time for a company to promote a product is when it is new and fresh. By releasing regular updates – every 2 weeks or 4 weeks, the company is constantly announcing new features and regularly offering new incentives for new users to try their “updated” system and for existing users to upgrade.
- In the past, with a 6 month or yearly release, the company would come out with a long list of new features. While this new product may attract tremendous attention in the market, five months into the new development cycle, as its competitors are announcing new features, the company appears, to the outside world, as being behind, stagnant, quiet. By releasing smaller amounts of features more often, the marketing department has more to work with, more hype to generate.
- We all know that every product has bugs. If a company releases a product every 6 months or once a year, it is faced with the option of release “patches” – which, from a marketing point of view sound like…exactly what it is. The product didn’t work – we’re going to patch it (fix it) until the next release. In an Agile environment, you avoid many patches simply by including the bug fix in the upcoming release. Even in a worst case scenario, where a user discovers a bug the very day they upgrade, relief might be only 2 weeks away. In this case, Agile companies work with releases and hot fixes. A hot fix might be released for a show-stopper or a critical bug. Otherwise, one release away, the worst bugs are hopefully eliminated quietly and without much fanfare.
For the Developers:
- By doing away with much of the standard work flow, developers are no longer working alone. Rather, they are part of a team and the team succeeds or fails as a unit. https://www.writepoint.com/blog/what-agile-brings-to-the-company-and-to-documentation/ https://www.writepoint.com/blog/what-agile-brings-to-the-company-and-to-documentation/ https://www.writepoint.com/blog/what-agile-brings-to-the-company-and-to-documentation/Knowledge is shared.
- Downside for some engineers – they sometimes find themselves doing QA; upside – they sometimes find themselves doing QA 🙂
- By dividing the “new features” requirements into segments, the developer should have a more granular schedule for deliverables. Instead of having 6 months to develop a set of features, each feature is “chopped” into smaller chunks that are likely more easier to estimate.
- Rather than finding out 5 months into the 6th month cycle that the developer will not meet the deadlines, the schedule is more fluid in an Agile environment. A developer that can’t meet the 6 month deadline will be monitoring progress on a regular basis (once every 2 weeks or once a month, depending on the sprint interval). This means that the company will know, well in advance, if the schedule is slipping, and estimates can be adjusted as needed.
For the Technical Writer…stay tuned!