So, should an effective scrum master encourage their team to take regular breaks, even when the pressure is on?
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?
- 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.
- 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.
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.
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
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
- Write UA content
- Review UA content
- Update UA content
- Tech Comms is now included within the sprint. This will help people see it as part of the product.
- The team have some understanding of what I’ll be doing for the project.
- I know who to speak to about each piece of work. This used to be a bit of a problem.
- Review tasks will need to happen before the story is done.
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.