Category Archives: Scrum

Lean coffee – not quite an Agile weight loss program

Geelong Lean CoffeeLast month I kicked off Geelong Lean Coffee.

Geelong Lean Coffee is a community of practice for people working Agile/Lean/Kanban in the Geelong area. We’re interested in diversity, and bringing together people who share common practices, be it in manufacturing, higher education, software development, eCommerce, business processes or healthcare.

Lean Coffee runs like a lean enterprise, so items for discussion are identified, prioritised and then discussed in a time boxed fashion – all in an hour. Best of all, there’s no preparation required and you usually have a few laughs along the way!

Since Jim Benson and Jeremy Lightsmith conceived of the idea of starting a group that would discuss Lean techniques in knowledge work in Seattle in 2009, dozens of groups have sprung up. Jim and Jeremy didn’t want to start a whole new cumbersome organization with steering committees, speakers, and such. They wanted a group that did not rely on anything other than people showing up and wanting to learn or create.

Since joining Deakin University six months ago, I’ve been incredibly impressed with the receptiveness of the Geelong community to new ideas. Chatting to eSolutions staff and other professionals in the Geelong community, I was sure that getting people together to share ideas about doing things better through Agile could bring value to Geelong. I also saw this as an opportunity for the university to reach out to the Geelong community and show thought leadership.

That’s exactly what happened last month when 12 people from Deakin, and diverse companies across Geelong, gathered at Waterfront Kitchen at 8:00am to start talking. With just a few instructions, two tables of conversations about Agile happened. For the first few minutes we all scribbled topics for discussion on index cards, and then dot voted on these. Once these were prioritised in our “To do” column, we moved the most popular topic into “In Progress” and discussion commenced. At the end of five minutes we voted with a thumbs up or not, as to whether to continue discussion of that topic, or move onto the next topic. At the end of an hour, our “Done” column reflected a whole bunch of interesting topics we had discussed like “How to manage distributed teams” and “How to induct new members into an Agile team”.

If you are in the Geelong area and interested in sharing ideas about doing business better across the Agile space, then join us for Geelong Lean Coffee.

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”.

Can Agile help you tie knots?

square-lashingIt turns out that the stereotype about scouts and knots is true! The other weekend, my little guy had a scout event where teams of individuals construct a raft and then race it down the Yarra River. The materials involved were poles, plastic oil barrels (for floatation) and of course rope, for tying the stuff together. To provide some context here, the only thing between drowning in the Yarra River and getting to the finish line, was the competency of tying the knots that held the raft together.

My kid’s team quickly settled on the knot required as being the square lashing. For those of you who were once scouts, you may know that this is not a straightforward knot. For those of you who do not know this, you can consult the diagram in this blog post. As it turns out, despite all four team members being scouts, only two knew how to tie the knot!

The scouts had a time limit on construction of the raft, and as a self-managing team, it was up to them as to how they managed that time. It made sense to me that perhaps the scouts who knew how to tie the knot, might teach the two who didn’t. After all, a bit of time spent teaching others, could ultimately save time.

However, and this is where things began to unravel, this self-managing team didn’t take that approach. Instead they struggled to complete the 12 square lashings and didn’t. Two team members were frazzled and two were unoccupied.

It was clear to me, not just because it had been raining and the river was running higher and faster than usual, but because the raft was only half-finished, that it was destined for disaster. It sure was going to be amusing though to see what happened!

My son described the raft race as terrifying and fantastic. Unfortunately, without the full requisite of knots, the raft’s path to destruction in the river rapids was swift. Thankfully it survived long enough to get the four passengers safely to the finish line in time to win the wooden spoon.

In Agile, the concept of “pairing” reminds us that it is not only OK, but terrific for people to pair up and teach each other new things. It might take an hour, or a day, or even an hour and then another few hours later on. When you see two people sitting next to each other to jointly complete a task, it’s pairing. Sure, two people spend time doing it, but ultimately it develops the skill base in a team and means that the raft won’t break apart before it crosses the finish line. Also, next time a raft needs to be built, there’s four people who know how to tie the knot.

The sound of Agile

A few weeks ago, I took my friend out for his birthday. I’d organised to head to a free ‘Symphony Under the Stars’ concert. Before you accuse me of taking him out on a cheap date for his birthday, here’s the deal – I did the planning and brought along a sensational picnic dinner (OK, this was mostly “sourced” rather than cooked).

Sometime into interval, after the scrumptious dinner, I surprised him with the cutest double decker mini chocolate cake ever (this was homemade!). He was pretty chuffed, but then, knowing me as he does, his expression changed to fear, and he asked, “You’re not going to sing Happy Birthday loudly and embarrass me are you?”. I responded by singing Happy Birthday very loudly and encouraging those around us to join in, which they happily did. At just that instant, the orchestra had commenced their post interval warm up. I began to notice that their cacophony of warm up noise was morphing into some much nicer sounds… and so it was that the entire audience, accompanied by the 70 piece symphony orchestra sang Happy Birthday to my friend.

You guys know by now that this is going to be a story about Agile – right? In my team, we are making a bit of noise. When we’ve completed a story, the person who does the finishing, gets to have a turn on our very own toy xylophone to announce, in the most pleasant of ways, that another story is in the “done” column.

Halfway through last sprint, I noticed that we were well on the way to completing everything we’d committed to in the sprint. I felt that this called for a soundful acknowledgement, so during our standup the finale of the 1812 overture filtered through the office, complete with cannons. Was this disruptive? Well quite possibly, but all for the right reasons. It probably made people wonder what wonderful thing had happened. It probably also made some people want to get with the team that’s having the most fun!

It was however, pretty apparent to me after the 1812 overture incident, followed by Parrell Williams’ Happy and Alex Lloyd’s Amazing, (when we did complete all the stories in the sprint), that the team was finding my musical taste a bit eclectic (read “only suitable for those over 40”). I countered with a competition to supply some music we can use when we are happy, excited, kick some goals, or finish a nasty story. Hinting at a past spent in too many 80s dance clubs, one team member came back to me with the sounds of an all-night party mix of Sing hallelujah, Such a good feeling and Ride on time!

Happy-AppleOur other sound is that of our cheery faced 1970s retro toy – Happy Apple. When you tap him, he emits a very soothing chimey sound. Having brought joy to a couple of generations of kids in my family, his goofy face is now bringing cheer to generation digital. Happy Apple has been making some noise as he makes his way around the team as a way of acknowledging when someone shows great agile-ness.

And so back to symphony orchestras. There’s probably no need to panic that they’ll be playing in my workplace any time soon. What is happening though, is that the sound of Agile, like that of Happy Birthday, is getting us to celebrate, collaborate and get the job done.

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!

Goldilocks, Agile & the Three Bears

BearMy web team are used to getting some crazy requests for resolution, but this one was weirder than the average digital project we work on.

Eager to take a collaborative and effective approach to managing digital content development, we are in the throes of introducing Agile methodology. We kicked this off with a workshop that saw us creating a comic book of Goldilocks and the Three Bears. This fun exercise is based on Mark Levison’s Learning Scrum Through Games.

The exercise is a fabulous way for a team to experience Scrum ceremonies, practices and roles, from the ground up. I acted as Product Owner and provided the team with the following unprioritised backlog:

  1. As a parent I can be excited by the book cover, so that I will open the book and read it to my child.
  2. As a child I can see colourful pictures of the characters, so that I can understand the story without having to read it.
  3. As a child I can count the characters and items, so that I can develop my counting skills.
  4. As a sponsor I can showcase my advertisement for home security so that parents will contact me for my services.
  5. As a parent I can get appropriate content for my 4-6 year old child so that they are able to understand it.
  6. As a sponsor I can see my public service announcement about being kind to animals, so that the next generation will improve on our generation.

The team were given the following schedule for a two day sprint. They needed to complete the comic book in two sprints:

5 mins         Sprint Planning (decide how much to do)
10 mins       Sprint Day 1 – Standup (what did you do, what you will do, obstacles)
10 mins       Sprint Day 2 – Standup (what did you do, what you will do, obstacles)
5 mins         Sprint Review (show the work)
5 mins         Sprint Retrospective (what went well, what to improve, what’s still puzzling?)

After the team ran through the first sprint, as Product Owner, I explained that there was another story that I desperately needed to add to the backlog: As a child, I want to see a page in the book that shows what the bears were doing while they were out, so that I can once and for all know what they were up to when they left their house unattended and unlocked that morning!

The exercise was fantastic fun and the learning outcomes were similar to those that Mark Levison reported:

  • Utillise the Product Owner – The team forgot to ask the Product Owner questions, but after the first retro they corrected this. This lead to some great discussion of Acceptance Criteria and Walkthroughs.
  • Chaos reigned – We learnt that the forming stage of a team, can be pretty chaotic, but that it’s possible to still develop product
  • Working software is the only measure of progress – The team didn’t get through all stories in the backlog. Even when a late breaking story entered after sprint 1, they still didn’t ask what might have to come out of the backlog. What they did do really well though, was prioritise which items in the backlog would add value. This lead to a great discussion about Minimum Viable Product (MVP).
  • Roles within the team – The Scrum Master did a good job of checking in with the team if they had any obstacles. We also discussed how to best utilise a team with a variety of skills. I even saw some informal pairing happening!

Most importantly, the team learnt that Agile values satisfying the customer though early and continuous development.

I’d love to hear other Agilists experience at having a go at this exercise, or getting a team up and running. My team were really fired up from the activity, and the very next day we put it into action with our actual backlog.