Agile is a set of methods and practices conceived in 2001 by 17 software developers who craved a radically different approach to the way teams developed software. In her virtual presentation on March 26, Heather Shelley provided an introduction to and a brief history of Agile, and used examples from her extensive experience to show how Agile was designed to work and how it actually works in real life (IRL).
Before Agile, most development teams used the waterfall methodology to develop software, which relies on extensive specifications, longer lead times, and longer development times. Waterfall releases include alpha and beta stages, with large investments of time and effort behind each release. A primary drawback of this methodology is that it is difficult to make late changes in development, which could be driven by changing customer needs or expectations, ever-evolving hardware demands, or the competitive landscape. Teams cannot react quickly to change.
Agile development is primarily driven by user stories instead of specifications. In Agile, development cycles are much shorter and release cycles are reconfigured as sprints and iterations. With development happening in smaller chunks and much more quickly, course corrections can happen faster. Although each iteration may not be perfect, teams can build on what they have done and develop products through an iterative process.
What Does Moving to Agile Look Like for Technical Writers?
Because Agile development is iterative and not linear, it can be an uncomfortable transition for writers. Writers are usually outnumbered, and the environment can be intimidating. Agile teams tend to be more fluid, where people jump from project to project to support. It can be more difficult for writers to build relationships and product knowledge. Everyone will have different experiences, however, because no two Agile environments run in exactly the same way.
Heather suggested that technical writers in an Agile environment need to be both “plotters” and “pantsers.” Plotters outline the entire story, whereas pantsers tend to write “by the seat of their pants.” Plotters can get stuck if things don’t work out according to plan and can paint themselves into a corner. If things change at a certain point, it requires a lot of rework. Pantsers might end up doing more work than necessary, and may have to throw things out as the scope changes. In an Agile environment, technical writers become very discerning about what is necessary to include, learn how to find a plot where there appears to be none, and become comfortable with the concept that perfection doesn’t exist.
Helpful to Know…IRL
The Agile Alliance put together the manifesto and the methodology (the theory), but teams put that theory into practice. When transitioning to Agile from waterfall, new Agile teams often morph Agile and waterfall development into a hybrid (“Waterfagile”). Teams can also be overconfident about the amount of work they can complete within the first sprints and iterations. At first, teams experience upheaval and confusion, and teams may not think that Agile is working. Members will often bite off more than they can chew and will feel like they are failing.
Eventually, teams new to Agile will realize that there are stages of team dynamics and development that people must work through before they work efficiently and effectively. Teams need to realize it is a skill they must build, and no organization really does Agile “by the book.”
Agile: What’s in it For You?
Solid experience! Soft skills like team building and relationship development, project management, technical skills development, increased flexibility, and confidence. Technical writers tend to be very good at spotting silos within organizations and among different teams because they have a bird’s eye view of documentation projects. This perspective can be immensely valuable to project teams and organizations.
Technical writers working in Agile also gain experience using a variety of software tools. Agile tools include Jira, Basecamp, GitHub, Kanban, Leankit, and VersionOne, among others. While these software tools are important to learn to use, it is much more important to understand why a certain tool is used instead of knowing the tools themselves. Heather reminded us not to get hung up if we are not familiar with a specific tool. That’s something we can learn along the way!
Heather finished up with some helpful advice and resources for learning more about Agile. It was an informative discussion for those both familiar and unfamiliar with Agile. Thank you, Heather, for taking time to share some of your extensive Agile experience with us!