Studies show that breaks are important shocker

Why Relaxation Is the Key to Productivity

So, should an effective scrum master encourage their team to take regular breaks, even when the pressure is on?

Working on multiple project teams

I've been asked by a colleague what my approach to attending meetings when working on multiple project teams and sprints.

This came up again at an end of project review where other team members are working on multiple projects at the same time. So, clearly in this age of scrum, this is a common problem for people.

One of the biggest problems with working across multiple sprint teams is that you spend more time in meetings. The more time you spend in meetings, the less time you obviously have to work in that sprint.

I've found this challenging. My default position was to attend all of the sprint related meetings for the two projects I worked on. This cost me 2 days out of 10. Effectively 20% of my working time was then spent in meetings.

As one of the projects neared its end phase, I dropped out of one project completely as I knew I just didn't have the capacity to do the work for both projects. Attending meetings for a project I wasn't working on, didn't make any sense.

Now, as one project has ended, and I've moved back to the other, those missed meetings have cost me a lot of understanding as to where the project is at. In essence, it feels very much like I'm back at square one with my work. The project's requirements have changed, and I'm finding that the work I've already done is out of date.

So, let's forget about that little blip. Let's assume I'm working on 2 projects again with similar deadlines. How am I going to approach my time?

What meetings do I consider important?

Very important

• Daily stand ups - Keeping in the loop is vital for sprint work. An efficiently run daily stand-up shouldn't make anyone would feel it was a waste of time.
• Sprint reviews - Get to see an overall picture of what the sprint achieved. 
• Detailed sprint planning - Get your tasks added to the backlog. If enough time is given between the high-level grooming and the detailed sprint planning, I don't see why tasks couldn't be emailed to the scrum master for them to include. This would get you out of this meeting as well. This depends on your role of course. If you're documenting like me, or testing, I don't see why you necessarily need to be present in the meeting itself - which often consists of developers hammering out the details of their approach.

Less important

• High level grooming - Again, depending on what role you have. User assistance is likely to be a secondary piece of work off the back of someone else's work, and is unlikely to be a user story in its own right. This changed for me towards the end of the project where I emailed the scum master to get 'finalising' activities added to the backlog, e.g. 'Finalise Installation Guide', 'Finalise Help system'.
• Retrospectives - Our teams distributed the results of the retrospective after the event, so I could catch up in my own time as to any actions. If I had a problem, I could email the scrum master outside of the retrospective.

I guess, it's always going to depend on what your role is, but I suggest that if people are feeling like they're spending too much time in sprint sessions then you should take a close look at the reasons why and try to address.

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.