Sunday, July 12, 2015

Adopting Agile Practices at the Medical Division of ON Semiconductor

By Fei Min Lorente

We started working in an Agile way last year. We began with classroom training and workshops, then retained the instructor on an as-needed basis for coaching. We also implemented a web-based tool called Jira, not only for tracking issues, but to record our planned features (defined as epics and stories), set tasks for sprints, estimate points, and track our velocity. In all of this, I (the lone technical communicator), have been treated like one of the developers. I’m part of the sprint planning meetings, retrospectives, and daily stand-ups.

We are still trying out new processes and procedures when it comes to developing a product, and although we’ve called our way of working “Agile”, our manager is committed to doing what works, whether it’s Agile or not. Agile evangelists will tell you that Agile isn’t really a methodology with a rigid set of procedures; it’s really a set of values and principles that guide you to make the best decisions about how you work. As a result, no two companies working “Agile” are going to do exactly the same thing. In fact, right now, no two groups are doing the same thing either, so I will describe what two of the teams are doing.

Team A is working on a new product, so the documentation is being developed from scratch. We created an outline at the beginning of the project because we had a good idea of what all the features would eventually be, and we still had to estimate resources and schedule, so I needed an idea of the page count. From this outline, I created a skeleton document in FrameMaker with all the subheadings that I knew of at the time. As the developers add new features, they are documenting them directly in the manual. In fact, they cannot consider their task closed until it is also documented, or a new task is opened to do the documentation (but most of the time the documentation is quicker to do than to create a new issue in Jira and then do it, so they just do it). I then become one of the reviewers for the issue, except I’m reviewing the documentation instead of the code. I’ve been doing the usual checks for grammar, clarity, consistency, conciseness, accuracy (I can also try out the feature), sometimes on a change that is as small as a sentence.

We have still allotted time for a complete edit and technical review of the manual when all the features are done (or mostly done), but we expect that the editing and technical review should take considerably less time than if we weren’t doing that on a continuous basis.

Yes, there has been and will be rework because the features change. Sometimes they are reworked because of feedback from our users or the product manager. But the documentation that is released with the product at the end of every sprint is matches that release, or at most, is one sprint behind.

Team B was working on an update to an existing product. Our tasks were defined by bugs and new features that were entered in Jira. If a new feature required documenting, we had to add a task for it, define the work and estimate it. There were dependencies: we had to know that a feature would be included before I could document it, but it didn’t have to be finished before I could start. Several times, the developer ran into problems, delaying the completion of a feature, but we agreed as a team that I could go ahead and document the way it was going to work. Yes, sometimes I had to adjust the documentation again, but it kept us moving forward and avoided the “do everything in the last two weeks” scenario that usually befalls the technical communicator.

After working Agile for about seven months, I have to say that I prefer it to the old Waterfall method. Mostly I appreciate the constant flow of communication: the daily stand-ups, sprint planning and retrospectives. It’s forced us to really think about how we work and how we can do better. It keeps me up-to-date on all the development work; no one has to remember to tell me about a new feature or change that needs documenting because that communication is part of the process. It also gives me an opportunity to make suggestions about how the product works every time they’re working on a new fature. 

Agile isn’t necessarily less work, with all the meetings and rework, but it prevents the massive crunch at the end, and it helps to control management’s expectations because they can get a progress report every two weeks. It also helps us to produce a better product because the constant feedback from customers or those who represent the customers, including me. We haven’t quite settled on the best way to do everything yet, but in true Agile style, we’re willing to keep trying and changing.


An Epic Experience with Agile

By Debbie Kerr

While I am a technical communicator, my role on projects is as a business analyst and not as a technical writer. My focus is on working with subject matter experts (SMEs) to identify the requirements that will be used as the basis for developing software. This is part of the Agile Manifesto: to put customer collaboration over contract negotiation.

For my current project, there are epics, user stories, and detailed requirements. These requirements are part of the process of converting a paper application to a web-based one. The paper application is 30-pages long and has 23 sections, a large number of fields, associated business rules, and an extensive series of validations both within screens and between multiple screens. In general, the epics are the 23 sections that have to be completed in the application. There are approximately 15 user stories per epic and the detailed requirements are all the fields, functions, business rules, and validations. These requirements range from about 10 to 20 pages per section.

Normally, in a Waterfall project, these detailed requirements would be completed from start to finish before development begins. With this project, I write the requirements in iterations, although it can take me several cycles to complete the requirements and receive signoff. There are formal signoffs; however, once development starts, sometimes it becomes necessary to add or modify requirements. I usually capture these requirements in emails with a less formal approval process.

In addition to formal requirements there are also functional specifications that a Business System Analyst prepares after the detailed requirements are signed off. In some cases, the requirements that I write contain enough information that separate functional specifications are not required. This practice is in keeping with the Agile manifesto: to place working software over comprehensive documentation.

An Agile approach means being able to adapt quickly to change. Recently, the day before a demo was scheduled to occur, we discovered that there was a misunderstanding about how something was supposed to work. Since the development was being completed in three-week cycles and the demos for the previous cycles were successful, the amount of change required and the implementation of those changes could be done much more quickly than if it had been a Waterfall project, where the problem may not have been noticed until much later in the development stage, and even as late as the testing stage. Since retrospectives (a type of lessons learned) are completed at the end of each cycle, we were able to identify ways to improve our processes going forward so that this problem does not occur again.

As cycles are completed, a Quality Assurance (QA) Specialist tests the software that has been developed in the previous cycle. Sometimes this testing is automated so that it can be repeated multiple times over the course of several cycles.

In addition to QA, there is also User Acceptance Testing (UAT). This testing ensures that key people can use the software to complete the tasks that they normally perform in their roles. Some of this UAT is being done as part of various cycles and the rest of it will be done when all development is complete. This is considered end-to-end testing and is often associated with a Waterfall Software Development Life Cycle (SDLC). For my project, this type of testing is required because, until all 23 sections have been developed, the completion and submission of the entire application cannot be tested.

Like any project, it will be epic when everything comes together. It will be even better when it is implemented and people begin to use it.