Gears of my childhood

This post is part of an activity from the online course run by MIT: Learning Creative Learning.

Gears of my Childhood

I guess a lot of people might well have said that Lego was the object that influenced them the most in their childhood. I'm happy to be part of that crowd. Lego was a hugely influential part of my growing up and whenever I pick up pieces of Lego, my hands can't stop snapping the little pieces of bumpy plastic together to create.

How has it influenced me though? Slightly trickier. When I was young, it was all about the instructions, and making the toy that the picture on the box told me I should be building. That gave a couple of days play before the toy was broken down and never reconstituted again. I took more delight in making models from the shows I used to watch at the time. I remember building Airwolf several times, as well as the Thundertank, and plenty of TARDISes. In fact, I built a couple of TARDIS interiors only last month with my children watching in disbelief at their intense daddy hunched over their Lego box, taking all the best bits.

But back to that question about how it has influenced me. I like to consider myself a creative person. Could hours spent constructing images from my mind and memory be in some way responsible for that? I've never been afraid to take something apart to attempt to get it working again. Whether that be a broken PC, or fixing the chicken shed. Maybe that's part of the legacy it's left me.

The Doctor's TARDIS

The Master's TARDIS

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.