Categories
agile scrum

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.

Categories
agile scrum

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.
Categories
agile scrum

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.

Categories
agile scrum

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.