Get the right people reviewing your work

Choose your reviewers carefully.

At the first sprint planning meeting, I was chuffed I had some User Assistance tasks added into the sprint backlog. It was a sign that we were integrating into the ways of the scrum. However, when it came to the reviewing task I'd asked to be added, I didn't pay enough attention to the purpose of the task, and therefore might have got it assigned to the wrong person.

The point of the reviewing task at this stage of content development, where the user assistance is very bitty, is to ensure its technical accuracy. I'm going to be looking after style and grammar, so what I need is for someone to tell me that the program works as I've described.

My instinct was to assign this piece of work to a business analyst, as I immediately consider them to be the subject matter experts. And that's true, when we're dealing with software written from specs, or full topics. But, when all I've got is five sentences outlining a rudimentary procedure, all I need is for the developer to tell me that I've got it right.

So, I might have got this wrong, for this task. But, the beauty of planning in these two week sprints is I can learn from this mistake and pay more attention next time.

Joining a second sprint team

I started with a second agile team today. This is a really exciting project and there's a lot to get my head around. So, joining the sprints has meant that although I've now got a lot more meetings in my calendar, I have also got daily access to the team putting this product together. That makes for a much easier experience when it comes to finding out what I need to enable me to write some user assistance.

And yes, my calendar is looking busier. With two sprint teams running concurrently (albeit a few days lag), there are now two days every ten working days that have the potential to get wiped out with meetings. And although there were gaps today, it was hard to get stuck into any of the high attentive tasks that I needed to get moving with. By default, the gaps got filled with easy stuff like answering emails, and filling in expense forms.

I don't envisage this remaining a problem, and even if it does, I'd sooner find myself with a bit less time, and with more information, than less information and oodles of time.

The tasks I got added were the three I added to the first sprint team's list.

• Write UA content
• Review UA content
• Update UA content

Although I only added them to one of the user stories.

There is definitely the potential for me to add a lot more to this project. There's still a lot I need to understand, and research on. I could have asked for a research task to be added, but I didn't see much need in it. If I'm doing a research task where I'm going to need input from the other sprint members then there's benefit in doing that, but otherwise, it felt like I was just clogging up the sprint backlog.

One thing I do need to sort out is my allocation spreadsheet. When you're working on one sprint team, it's easy to work out your capacity and plan accordingly. When working across teams, with different start and end dates for sprints, it's much harder.

So many meetings

Wow, so after getting agreement from the scrum teams, the meeting requests started to flood in.

For a while now, my calendar has been pretty quiet. I made the mistake of withdrawing from many meetings because whilst the Tech Comms team was working to a waterfall method, and everyone else was scrumming it, we were getting information we wouldn't be using for weeks. It all seemed rather pointless.

Now, of course, we need to be in the thick of it. So, I've received invitations for planning meetings, review meetings, retrospectives, daily stand-ups etc. My calendar suddenly looks a lot fuller. That's going to take some getting used to.

The first big day of meetings was yesterday. We had:

• Sprint review
• Sprint retrospective
• 2 planning meetings

That pretty much wiped out my calendar for the rest of the day. But how useful was it?

The sprint review highlighted stuff I'd missed out on by not working in the previous sprint. It gave me some detail, and I know the people I need to talk to about the work.

The retrospective was OK, and generally constructive. Rather than give everyone a load of post it notes and ask what worked well, we went through the teams' list of unwritten rules and asked whether we were doing these. I thought that provided a good framework for the meeting and kept it brief and good natured.

The planning meetings - well, never having been to a planning meeting I didn't know what to expect. I had a list of stories I wanted to get added into the sprint, and was doing my best to work out which of the existing stories might need some content adding. I had been worrying a bit about this, but there was no need. It was obvious which stories needed content writing. For each of those stories, I got these 3 tasks added:

• Write UA content
• Review UA content
• Update UA content

The Review UA content task was important as I now know who will be reviewing the content for this work, and it needs doing in order for the team to claim the storypoints.

Although yesterday felt like a bit of a slog, I feel like we've made some great first steps.

1. Tech Comms is now included within the sprint. This will help people see it as part of the product.
2. The team have some understanding of what I'll be doing for the project.
3. I know who to speak to about each piece of work. This used to be a bit of a problem.
4. Review tasks will need to happen before the story is done.

And another bonus is that I don't need to keep a separate task list for this work at the moment. I have a good idea of what I'm doing for the project for the next two weeks.

First steps towards Agile

Our entire Products & Services team (R&D) are working to an agile development method, following Scrum. Up until now, the Technical Communication team (two of us) have been working in the traditional waterfall approach. But, last week my colleague and I agreed to start working more like the rest of the department. This week sees the first steps in that change.

Why change? A question I've been asking a lot recently, but I guess the drive for the change has been building momentum over the last few months, leaving us in a position where working our own way, just doesn't seem sensible any more.

• The project teams have demonstrated that agile works for them.
• Spread across multiple projects, the Tech Comms team are always at risk of clashes for our time. Working outside of the process that everyone else follows only risks exacerbating that problem.
• Speaking to colleagues across the business, I discovered that other Tech Comms teams are working to an agile methodology, although not within specific project teams.
• At the TCUK conference, most people I spoke to, were working closely with their development teams within scrums, with no real problems.

So that's the why, now the how.

Although we had the feeling through casual conversations we'd had with the different development teams that they'd welcome us working with them in scrum, we wanted to ensure that they were all in agreement that this was the right thing to do. We also wanted to make sure that we were working with the teams in the same way. We're only a small Tech Comms team and we don't want to be working in different ways across four different projects.

We drafted our thoughts into a document (what else) and distributed it to the scrum masters for each team, and invited them to a meeting to discuss. The main process for each sprint was summarised in this diagram.

The teams were all happy to start working like this - we have agreement - and all in a half hour meeting.

Yes, the nitty gritty needs to be ironed out. I suspect that they are using TFS in subtly different ways to manage their development, so we need to spend time with each of them and understand that. We also have one team who aren't using TFS for sprint planning. So, we have to understand at least two different ways of managing projects.

But, I'm pleased that we're doing this.

TCUK: Information Design 101: My thoughts

I attended the Information Design 101 workshop run by Robert Hempsall.

Abstract

(from TCUK website)

In the spirit of the topics of usability and accessibility, Information Design 101 is an introduction to the principles of making information easy to understand. Taking a document collectively selected by potential workshop attendees, this workshop will guide attendees through a number of basic information design techniques, to end the session with a new improved (and easier to use) document. These techniques will include typography, plain language and document structure – all demonstrated using everyday software. This workshop will be a hands on session, with attendees encouraged to bring a laptop with Microsoft Word to try out some of the techniques themselves.

My thoughts

We looked at a form that voters would use to apply for postal voting.

Robert encouraged us to bring our laptops so we could work on a word document and go through the stages with him. This hands on approach was valuable as it made you pay attention to the advice being offered.

There was a lot of discussion about how you can make forms easier to understand and unsurprisingly in a room full of technical communicators, there was a lot of opinion.

Good design, good workflow, and plain English would seem to be key points of this.

I found myself questioning a form I had to fill in a couple of days ago. That very much needed a bit of attention.

I need to go and try some of what I picked up in this workshop.

Presented at TCUK 2012

This blog post is about how I presented at the TCUK conference in 2012. The TCUK conference 2015 takes place 29th September - 1st October 2015, Glasgow. See the conference website for details.

*********************************

It's over. I presented at the TCUK conference in Newcastle.

And survived....

The TCUK conference is an event for technical communication specialists. My colleague suggested it would be a good opportunity for me to present. Not sure if that was secret business code; "opportunities" are rarely fun.

So anyway, if you trawl through some of the past posts you'll see that I've ended up giving this presentation twice before the big TCUK event. These previous events were a good "opportunity" to practice my talk and get used to standing in front of a group of people. Both of those practice talks went well so I was relatively calm about doing this one.

Mine was on day three of the event. I was pleased about this as it gave me a chance to acclimatise to the venue. The books I'd read said that you need to have some control over your environment, so I was keen to see how the rooms were going to be laid out. Was I going to be able to move about a bit, or was I going to be tied to the lectern? After one of the sessions on day two, I had a sneaky stand at the front when no was about so I could see what it was like standing at the front of the room. Not so bad.

My session was in the second slot on day three. In each time slot, delegates have a choice of three sessions to attend. I think there was somewhere between 150 and 170 people at the conference, so I had the possibility of between 0 and 170 people attending mine. During the session before mine, I was finding it pretty hard to concentrate on what I was listening to, and then the audience wanted to ask a million questions. I thought I was going to get to my session late. But, I got there with 7 minutes to spare.

But, there were already people sitting down in the room. I hoped I was going to get the room to myself for at least a couple of minutes so I could practice my mike and maybe practice the opening lines a couple of times. Alas, that wasn't going to happen. I got to the lectern, and saw the mike, but no one to help me. Tiny moment of panic. Thought I'd best leave it alone. If I didn't have any help and no mike, I knew I could probably project across the room well enough. David Farbey arrived and put me at ease straight away. David chairs this conference and does a tremendous job of it. He is incredibly natural and confident when he speaks in front of an audience.

I decided when practising the night before, that I would listen to some music before I had to speak, hoping that would get rid of any last minute nerves. So, I listened to The Killers "Flesh and Bone" on my iPad (low level, didn't want to scare the audience), and that certainly helped; by the time came when I was introduced I was raring to go.

And what happened next?

The talk went much better than I could have hoped. The room was full (50+ people). They laughed in the right places, they listened attentively, and I managed to get a sneaky double applause out of them. Feedback after the session was humbling. A theme running through the presentation is that I hate presenting, so it was really nice to hear people tell me that I was a good presenter.

If anyone wants some good, solid advice about presenting, I recommend
The Presentation Coach: Bare Knuckle Brilliance For Every Presenter - by Graham Davies. It really is brilliant.

Would I put myself through this experience again and do another one?

Well, since my presentation was all about stepping out of the comfort zone, I'd have to say yes, or I'd be a massive hypocrite. I strongly believe that it's important to keep stretching yourself, and seeking out new challenging experiences. It's the only way we'll ever discover our potential for doing wonderful things.

Presenting at TCUK

In a couple of day's time I'll be presenting at TCUK, the annual conference for technical communicators. http://www.technicalcommunicationuk.com/

I'll be doing my talk: Beyond the comfort zone: today you will not be writing a help file.

I've presented this twice before, in different situations. This is most like the first, more formal, presentation, except this time, I suspect I'm going to be miked up. That should make me a bit less worried about projecting my voice, but I don't think I really have a problem with that.

Mine's not until Thursday which gives me tomorrow to see what the gig is with how long people are making their presentations, and whether we get miked or not. I was told 40 minutes, but then we need to leave time for plenty of questions, so does that mean I need to shorten it? It runs at 36 mins at the moment, but if I start talking very fast tomorrow, as I'm liable to do when I'm nervous, it will be shorter (obviously).

What's the worst that could happen?