Posts Tagged ‘software’

15 December

Scrum on a Software Documentation Team

In April 2009, I changed roles at work from being a tester to being a contract programmer-writer. As many of you know, this is not my first experience with writing or instructional design, but it is my first experience with being an official member of a documentation team.

The product team we work with is using Scrum and when I joined the documentation team, it was advertised as also using Scrum. Only when I joined did I discover that the team was using a mutant form of Scrum + Waterfall that could perhaps best be described as Stuff Flowing Downhill at Great Velocity and With Little Organization. The only real resemblance to Scrum was the daily “huddle” – except it typically lasted a half-hour for a team of four and was more concerned with approaches than purely status.

The first several months were confusing and prone to bouts of frustration. Work was getting done but, while I couldn’t speak for the other team members, I was certainly not signing up for my own deliverables and setting my own timeframe. I was catching things as they were being tossed at me. Since my personality doesn’t allow me to just sit back and not become personally invested in a project, I offered to help move my team more toward proven Scrum practices but my offers were not accepted. Instead we muddled along and I fought back my desire to help :)

Mind you, I do not think this was because of any ill will or evil intent but I think the situation had roots more in the inexperience of the lead that hired me and in the fact that lead did not have training in Scrum. The lead had read a book about Scrum but I’m not sure which. I was the only team member who had done significant reading and investigation of Scrum, let alone taken a class on it.

About three to four months after I joined the team, the lead that hired me resigned and I gained a new lead. This new lead had no experience with Scrum but did have a lot more experience with leading a documentation team and shipping product documentation. He really got tossed into the morass with a team he didn’t know and a project already at risk. Our product team had no idea what we were doing and where we were and thus were (justifiably) nervous. The lead had no idea where we were either and what had or had not been done. There was no plan, there was process documentation beyond some emails and it was a mess. One lead, a team of three contractors and a huge lot of bugs and legacy documentation – it didn’t look good, I admit.

The day I got the email of the change in leadership, I stopped by his office and introduced myself, then told the new lead I had a lot of feedback on the team, the project and our processes that I’d love to share with him whenever he was ready. He just nodded, looking a bit shell-shocked, and said to give him a few days to get a handle on what was going on. It actually took a few weeks but I was able to start feeding him bits of Scrum processes and suggesting changes to help us. After a few months of introducing change, as well as taking a full time job with my team instead of my contract job, we’re now running a much more Scrum process.

We put up a corkboard in the new lead’s office and went with the visibility of notecards and columns for stages of our process – Writing, Initial Edit, Tech Review, Final Edit, Done. Each team member was responsible for moving their cards and the standup was used for real status updates and blocking issues only. No more talking about how to do something or implementations. I took over running the standups and serving as the Scrum Boss to keep the meeting on track. We stuck with one week sprints because we HAD to get and stay on track and because the documentation team needed to learn Scrum. I felt longer than a week’s sprint was too long given the black-hole history of the team members’ deliverables.

I wrote up a process document to send to the product team members so they would know what our dates are and how the documentation process works. This helped to clear up misperceptions and helped them understand what to expect.

Each of our team members began attending the weekly leads meeting that relates to what section of the documentation they are working on. This helped increase visibility and cooperation with the product team members.

The next step took a lot longer than I’d have liked. I had been pushing my lead into the role of Product Owner. He had the best knowledge of the documentation process overall, the best knowledge and access to the product team’s schedules and needs. And he was the boss :) He was really nervous at not knowing exactly where we were, how we were doing, what progress we were making, etc. His reaction to this nervousness was to suggest scrapping Scrum and going back to waterfall but he did realize it wouldn’t work when I pointed out that it would not help at all to make the switch – instead we would have to start over again. We made a pact to give Scrum a chance.

A month had passed without the product backlog being generated by my lead, despite my promptings. I believe, in part, this was because he wasn’t sure what to do but also because he was involved in trying to hire another team member as well as dealing with the other products he still owned as well as mine. In the third week of my being a full time employee again, I took all the information I had on the parts of the documentation project I owned and made a backlog spreadsheet for it. I wrote some assumption at the top, prioritized in batches according to those assumptions, and did a rough cost estimate on each line item. Not surprisingly, I had about twice as much work TO do as I did time to DO it in.

Once my lead had seen the spreadsheet, the lightbulb really came on. He worked with the other two writers to create the same sort of product backlog for their sections. Because we don’t have enough people for true cross-training, we kept the sections separate for now.

The last two days have been the fruits of all that labor. My lead seemed a bit worried at how the message would be received that we were NOT going to get everything done by the release date. My mantra was constantly “better the devil we know” – at least now we knew exactly where we were, could communicate that and could communicate progress. We came up with a plan for the items that would not make the cut as well. Each project team group has been great when presented with our backlog list. This was the transparency they’d been wanting all along.

Right now I’m waiting for the product team to look at the list items and calling out any changes made in the batch prioritizations I’d made. In the meantime, I’m working from the top of the list.

We stopped the sprint board when I was interviewing, the Thanksgiving holidays hit along with a product preview release, and things got out of hand. My lead has already agreed it will be restarted right after the Christmas holidays. In the meantime, people are working from their backlog lists as well and the standups are reporting status from the writers to the lead.

My lead has gained enough time back to be able to do some writing again, instead of only managing. We will be on the same page as the product team and will have set reasonable expectations of what we will produce by ship time. We even have a plan of how to handle the post-release work that must be done.

I’ve not announced it yet but my boss will soon find out about the sprint retrospectives we need to have :)