3 Agile Insights or: How I learned to stop worrying and love the Scrum

For over a year, I have been the lone tech writer on an Agile team full of top-notch system analysts. I have to confess that I was nervous about the prospect of spending my whole morning working on the same project, with the same people. And my development skills are limited to HTML and a few ill-advised forays into JavaScript and Ruby. How would I contribute to such a team?

I’m happy to announce that although I am still not much of a programmer, I have discovered some interesting things about Agile. So off we go…

1. Agile is a mindset, not a prescription. When people say they are “doing Agile” or a project is being run as an “Agile project,”  I’ve discovered that there is probably some room for argument. They might be confusing Agile with something else.

The characteristics of Agile were cherry-picked from a variety of software development project approaches, including Waterfall, Extreme Programming (XP) and Scrum. Eventually some developers formally codified these principles in the Agile Manifesto. Although this makes it easier to describe Agile, it also makes it a bit more challenging to define it.

To work in Agile, team members gradually develop an “Agile Mindset” that favors consensus, small changes, continuous feedback and learning, and individual interaction. Being Agile means that team members operate under shared vision and personal accountability, while enjoying the autonomy that allows them to choose how to tackle the tasks they work on.

In my time with the Agile team, I found that this way of working was both more efficient and more satisfying. Each day was organized around value-added priorities rather than a fixed schedule.

2. The Agile Manifesto is open to (mis)interpretation.

In 2001, a group of 17 experienced programmers gathered at a ski resort in Utah to codify their common beliefs by creating the Manifesto for Agile Software Development:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

I recently heard a project manager say that developers don’t like to write documentation because “the Agile Manifesto prohibits it.” As a tech writer and an Agilist, I had to object. Another person in the room helpfully piped up, “People over documentation, right?” No, not quite.

The second bullet above is the source of much confusion. Lazy developers might use this statement to get out of documenting their projects, but the developers I worked with understood that “working software over comprehensive documentation” didn’t mean “eliminate all documentation.”The clue comes in the final, bolded statement: “while there is value in the items on the right, we value the items on the left more.”

In an Agile mindset, documentation flows from working software and constant communication. It may come later in the process, or it may grow out of the user stories that guide each sprint. In a complex project, a technical writer can take on many of these documentation duties.

3. Tech writers have a stake in Agile development. At several junctures, our Agile team was threatened by reorganizations and efforts to mirror our success in other teams. We usually were able to fend off these threats by emphasizing team velocity: it takes time to bring a team through the “forming, storming, norming” stages, and we were unwilling to lose what we had.

But why keep a technical communicator embedded with the team? In my organization, only a handful of other projects had used Agile or Lean methodologies, and as far as I know, they never included technical communicators like me.

Technical communication experts suggest  that even though technical writers on Agile teams focus on content, they can contribute to the team effort by providing usability input or helping with end-user testing. This type of participation creates a more visible role for writers, and allows us to offer more informed opinions—assuming we’ve been paying attention all along, as we should.  It is also important to insist on accuracy by asking questions, gaining access to test systems and prototypes, and learning as much as possible about how the product works.

One of the criticisms of Agile is that its fast pace does not always lend itself to improving the user experience (UX) through testing. My presence enabled us to do a modest amount of usability testing to improve the interface. With limited resources, we performed 20 tests during a single four-month project. Because of the iterative nature of Agile, we were able to conduct two or three tests after each of the latest builds, recording impressions and problems to take back to the development team.

In conclusion, I plan to bring my Agile Mindset to future projects, whether or not they are using an Agile framework. The availability of different project management models means that teams can always figure out a way to work to best meet the needs of end-users.

Advertisements

The dreaded team project

The team project is every student’s worst nightmare. The grim acceptance of yet another doomed academic exercise seems to be an unavoidable part of higher education. Yet, as I tell my students, you will work on some kind of team project in virtually all modern workplaces. With a little bit of planning, you can–and will–survive.

First, let’s define a project. It is

•a temporary endeavor
•focused on achieving a goal
•an allocation of resources: time, money, people, equipment…
•bound by constraints: time, budget, scope

The key to survival is focusing on that first bullet point. A project is temporary. Hang on to that hopeful thought.

It’s also comforting to know that conflict is a natural part of teamwork. Almost 50 years ago, Bruce Tuckman identified his famous team stages: forming, storming, norming, and performing. If you are “storming” within your team project, you can remember that your project is following the Tuckman progression just as it should. (Of course, the problem is that some teams never get past the storming stage. More on that in a bit.)

Meredith Belbin (1981) looked at team projects through a behavioral lens. He noticed that different individuals in a team displayed distinct “team roles” to varying degrees. A healthy team features a fairly balanced distribution of the roles:

  • Coordinator (Chairperson): sets agenda, tracks, coordinates
  • Resource Investigator: finds new info, new ideas
  • Team Worker: looks for his/her part, gets work done
  • Shaper: focuses on action tasks, completing project
  • Implementor (Company worker): turns plans into actions
  • Completer/Finisher: detail-oriented, schedule-aware
  • Monitor/Evaluator: IDs flaws, focuses on outcomes
  • Plant: creative, focuses on big picture
  • Specialist: adds depth, masters a specific topic/area

Knowing that people exhibit their unique set of dominant team behaviors (Plants versus Completers?) helps us understand why we have conflict. Teams truly do have a personality, a mix of traits and behaviors.

The ultimate secret to project success is communication. This involves planning the project (brainstorming, asking questions), establishing a common vision (sharing ideas, setting goals, understanding scope) and time management.

Time management is probably the aspect that causes the most pain. Attending (or efficiently running) the team meetings, meeting deadlines, and completing tasks in a timely manner all contribute to the success of a team project.

Team project tips and coping skills

If you’re about to embark on a team project, here are a few helpful suggestions based on personal experience and Study Skills: Team Work Skills for Group Projects, an article written by students for students.

1. Begin by describing your project. As a group, write a few sentences to establish the exact deliverable (report, poster, PowerPoint, etc.) and what it should cover. Get everyone on the same page, so to speak. It also helps to define what types of work you will need to do to complete the deliverable: research, writing, surveying, gathering stats…

2. Create a project plan. At minimum, a project plan should define the responsibilities of the team members, establish a schedule, and map out conflict resolution.

  • Share email addresses, phone numbers, and any other contact information that could be useful.
  • Decide how quickly team members should respond to project communications: within one day is reasonable.
  • Sit down with calendars and mark off the days that will and won’t work for team meetings. Mark the deadlines of any deliverables, including intermediate steps (drafts, progress reports). Anticipate holidays, birthdays, and the inevitable demands of other classes’ projects. (And be sure to build in time for editing and proofreading!)
  • Hope for the best but plan for the worst. If one team member drops the class/gets sick/stops caring about grades, what will you do? Figure this out on Day One. Avoid some of the “storming” and put your team on the path to “norming”.

3. Divide & conquer–or not? Most team projects take a piecemeal approach: you do the introduction, I’ll do the bibliography, he’ll do the graphics. There’s nothing wrong with the divide and conquer approach–it can be a very efficient way to work. Well, that is unless it’s the last hour before the project is due and you are the person who ends up assembling and editing all those inconsistent, unrelated, or missing pieces.

To reduce frustration, be sure to also build in time for the group to simultaneously work on the project. In this approach, all of you assess your progress, assemble the pieces each person has completed, and identify what still needs to be done. This is an iterative process, depending on how much time you have to devote to the project.

4. Take advantage of collaboration technologies. If you have never used Google Drive for collaboration, get yourself to Google now and start learning! Google Drive is free cloud storage for all kinds of formats: Docs, Spreadsheets, Presentations, Forms, and more. It can be a bare bones substitute for Microsoft Office, and best of all it allows you to share, track versions, and see who added that hideous purple text on page 4. Google also offers video and text chat (IM), so you can work together even when you’re apart.

Other technologies include Dropbox (free shareable cloud storage for files), Doodle (a simple calendaring app that lets you schedule meetings at convenient times) and a whole bunch of others. You can even build a free website on Weebly or Wix or (hey!) WordPress.

If you need a high-powered (costly) solution, look for 30 day trials or academic versions. And don’t forget to check out your school’s site-licensed software. You might be pleasantly surprised at what is available.

Conclusion

Stay positive and stay flexible–you will get through this. Look at it as a chance to build your management skills and snag a good story for a job interview (“tell me about a time you had to solve a problem.”) And if all else fails, seek motivation.