Tag Archives: Scrum Master

When playing pool in the kitchen is just that!

The other day, I was copied on an email at work. It was from the IT lead in my organisation.

It went something like this:

Last week, Katrina Kolt (that’s me!), took me on a tour of the facilities at the accounting software company MYOB. I was astonished to see at 10am on a Friday, two young guys in the kitchen, playing pool! No doubt, what they were actually doing, was collaborating on a difficult IT problem!

I responded:

I’m so glad you enjoyed the tour at MYOB. I did too. It is correct that it was Friday, and it was 10 o’clock, and there were indeed two guys in the kitchen, playing pool. I’m not sure though that they were collaborating on a difficult IT problem. I’m guessing that they were just playing pool.

What is true though, is that two team members who work hard, and then take time out to play pool together, will no doubt be able to collaborate on solving a difficult IT problem.

Agile values individuals and interactions and Agile processes promote sustainable development. When you saw two guys taking time out to play pool in the kitchen you saw both these principles in action.

When this guy, albeit in astonishment, referenced an Agile practice in that email, what he was really doing was acknowledging his learning, as a result of a field trip!

Purpose

While it’s nice to turn up, look around a groovy office space, say thanks and depart, if you do that, then you won’t be making the most of a great opportunity.

First up – don’t take someone on a field trip, unless you have a clear vision of what outcome you want to achieve.

I’d worked really hard to get the IT lead to come out on a date with me. We were in the throes of designing our new office space, and I needed this guy to understand how an Agile office fit out could support Agile practices in our organisation. Things like no desk partitions to allow better communication, break out spaces for collaboration, large white boards with video conferencing facilities installed, to allow stand ups between distributed teams and a large area to hold spontaneous celebrations,

Preparation

Make sure you provide background info to tour participants to help achieve your goal. In the case of this guy, who had no Agile knowledge ahead of meeting me, I put together an Agile primer. I engaged him in conversation about Agile ahead of the tour.

Your preparation also needs to include talking with the people who are hosting you, ahead of the day. Explain the purpose of the trip to them. Discuss a suggested agenda. Tell them heaps about who is going to be attending, what their understanding of Agile is, or is not, what level of detail to provide to the guests.

Explicitly check if it is Ok to stop the tour guide to ask questions, or to point something out to the people on the tour.

Check if it is Ok to take photos.

Playing on the day

On the day. Make sure you introduce the people who have come along. Don’t just say. Hi guys, this is my team from [insert organisation]. Make sure you make the tour guide aware of who’s who. This is John, he’s the  IT lead for my company. Use this as an opportunity to remind the people attending why they are here. John’s curious to see how you’ve set things up to support Agile because we are going through this process right now.

This is Paul, he’s our architect, and he’s designed a terrific office space for Envato. It supports Agile practices, but he’s keen to see how you’ve done it here in a much more scaled Agile environment.

When you see people “pairing”, then point out this behaviour to the tour participants. Don’t interrupt a stand-up, but listen in as chickens at a couple of different stand ups.

A good host will arrange for you to be able to chat with the Scrum Masters after the stand-ups, so that you can be walked through how different teams do stuff.

Use the different information radiators on the wall to initiate conversation. That’s what they are there for!

Make sure you thank your hosts and ply them with heaps of extremely unhealthy treats (in the proper Agile fashion) so that they can share these between the teams you visited.

The debrief

Immediately after an awesome tour, you’re going to need and want to chat about what you saw. Allow time for a coffee or lunch to have an informal conversation and compare notes.

But don’t just let the experience of the tour end there.

The learning bit

Make sure that you schedule some time to take staff offline for a couple of hours, so that you can do something with the learnings from the field trip.

After our trip to MYOB I collaborated with the IT lead, to design our new office space.

If you are taking an Agile team on a field trip, think about a workshop that asks three key questions:

  1. What Agile principles do we utilise in our workplace?
  2. What Agile principles did we see in action at MYOB?
  3. How can we adopt some of these to improve the way we do things?

You can create large visual charts with this info to display around the place, so that other teams can learn too.

The wrap

So, back to the IT lead – there have been a few wins:

  • He now knows my name!
  • I got to be involved in designing our new work space!
  • I now have an Agile champion in the organisation.

Party like it’s 1967

Party like its 1967The Agile stuff I’ve been introducing to my team has generated a lot of interest, so I kicked off a series of brown bag sessions at work, to lift the lid on Agile. These are informal introductory learning opportunities held over lunchtime.  People turn up with their lunch, their brain and if they like, some questions on the topic.

Our first session was titled “Party like it’s 1967”. 1967 was an exciting year. It was the summer of love in San Francisco, The Beatles starred in Magical Mystery Tour, The Doors released Light My Fire, The Monkees, I’m a Believer and Aretha Franklin, Respect. An unmanned craft, the Surveyor 3 was landed on the moon and sent back 6000 pictures. Martin Luther King Jr denounced the Vietnam War and tens of thousands of protestors marched on Washington. In Australia, Aboriginals were given the right to be counted in the national census. It was probably not good form for me to mention to my Geelong attendees that Richmond defeated Geelong in the footy grand final.

It was, whether you were around to remember it or not – BIG!

The aim of the brown bag, was to plan project “Party like it’s 1967” using Agile. During the session, attendees put together user stories to deliver all that was required for a groovy 1967 themed party. The user stories looked like this:

  • As the event coordinator, I want a venue, so that Katrina can hold her party.
  • As the event coordinator, I want music, so that I can evoke the atmosphere of 1967.
  • As the event coordinator, I want invitations, so that guests can come to the party.
  • As the event coordinator, I want food, so that guests can eat at the party.
  • As the event coordinator, I want entertainment, so that guests can enjoy the party.

Thinking through the venue story, the participants artculated the following acceptance criteria:

  • The venue can comfortably accommodate 100 people.
  • The venue has an area for quiet conversation and groovy dancing.
  • The venue is in the south eastern suburbs of Melbourne.
  • The venue décor has a party, rather than corporate, atmosphere.
  • The venue must allow pictures to be hung on the walls.

Whilst planning the party in an Agile way, the team talked with the Product Owner and learnt heaps of useful stuff like what the  the most popular colours of 1967 were – turquoise, pink, orange and sunshine! They also had the opportunity to be Scrum Master  for an hour and be involved in a self-managing Agile team. It was a fun session and the image with this blog post shows what the team looked like after planning “Party like it’s 1967”.

The Hoodoo Gurus do Agile

Hoodoo-GurusA few days ago I happened upon the iconic album cover from the Hoodoo Gurus 1984 album Stoneage Romeos. Initially a cult inner-city act, their popularity expanded due to regular airplay on radio station Triple J and nationwide pop TV show Countdown.

I had organised a field trip for my team to the offices of accounting software company MYOB, to see Agile product development in action. There in the groovy breakout space was the cover image of the “Gurus” first album. Let me be perfectly clear here, back in the eighties when I followed the band around the pub circuit, I wasn’t imagining that thirty years later I’d relate their meteoric (in my mind only) rise to fame with Agile product development methodology!

It did get me thinking though, that just like Agile methodology, the Gurus were a bit out there. Agile emphasises business people and developers working together daily throughout a project. Likewise, it recognises that the most efficient and effective method of conveying information to, and within a development team, is face-to-face conversation.

On our field trip to MYOB, we saw these principles in action where about four standups were being conducted simultaneously, with Developers asking Product Owners questions about features, and confirming how they could drive forward their activities for the day. The sound in the large open space office area was that of people involved in face-to-face conversation.

As visitors to MYOB, the team unanimously commented on the passion shown by the Scrum Masters who hosted us on our tour. It turns out that it isn’t just a principle in the Agile manifesto to build projects around motivated individuals and give them the environment and support they need, and trust them to get the job done! We saw it in action.

True, the Hoodoo Gurus had a different sound to other eighties rock bands that had come before them, but championed by radio station Triple J, their non-mainstream sound took hold. In my organisation we are amongst the first teams adopting Agile. It means that we are doing things a bit differently to satisfy our stakeholders through early and continuous delivery of valuable software.

When inducted into the 2007 ARIA Hall of Fame, the announcement stated that the Gurus were one of the most “inventive, lyrically smart and exciting” bands from Australia. “Inventive”, “Smart” and “Exciting” – sounds a bit like Agile to me.

Minions rush to Agile

MinionsI was recently beyond excited to hear that the Minions are set to star in their own film, a spin-off/prequel to the 2010 Despicable Me and 2013 Despicable Me 2.

In case you haven’t seen these movies, Minions are yellow henchmen who have existed since the beginning of time, evolving from single-celled organisms into beings who have only one purpose: to serve history’s most ambitious villains. So admittedly, they are driven by serving evil, but their industrious cuteness is what won me over from the very beginning, and continues to make me laugh every time I see their silly one or two eyed selves.

Minions were also the stars of  my team’s recent training. The focus of the workshop I put together was on understanding roles within an Agile context. It’s best explained by picturing an Agile team sitting in a room (of course if you picture the team as Minions, there’d be no sitting!).

The Product Owner would be nearest the door, because he/she spends a lot of time outside the room talking to stakeholders to define the product/initiative and to prioritise features. The Product owner is always available at standups to listen to the Developers and communicate the product vision.

The Scrum Master might be close-ish to the door too, because in the most diplomatic but firm way, he/she wants to ensure that the Development team is free of (admittedly well intentioned) disturbances from outside the team. The Scrum master is always at standups, checking the choreography of the event and keeping one eye on the Agile card wall to encourage the whole team to commit to pushing stories through the sprint. The Scrum Master is the team’s cheer squad.

The Development team would be further inside the room, so that they can get on with what they need to be doing – building the asset. By arrangement, the Product Owner and Stakeholders are invited to sit with the Developers for walkthroughs. The Developers always feel they can catch up with the Scrum Master about in sprint activities or obstacles. Likewise they feel confident to seek product decisions from the Product Owner.

Suffice it to say that in the Minions’ world everything has a happy ending. Translating this into Agile terms – assets are delivered on time, with the features our stakeholders and users need and want, and the team has a bit of fun along the way!