Follow littlehelper on Twitter

About

via Delicious

Verify that this site is using Green Web Hosting. Web Analytics

Miyagi, the Karate Kid and Scrum

As I mentioned in my last entry, I whipped up a small talk to do at last night’s Melbourne Scrum User Group meetup, which had the rough title ““Being Mr Miyagi and the Karate Kid“.

I scoured the web to find some stills from the 1984 movie and printed them onto A5 paper to show to the gathering, in this order.

  1. Mr Miyagi
  2. Daniel
  3. Wax on, wax off
  4. Sand floor
  5. Paint fence
  6. Daniel punching a target on Miyagi’s chest protector
  7. Miyagi and Daniel (doing a Crane stance) in the style of the Simpsons.
  8. Daniel fighting the Cobra-Kai at the tournament
  9. Daniel getting the girl

The general gist of the talk was that when you’re learning something from an expert, you may not understand why you are doing something at first (steps 3-5) but you’re probably doing it for good reason. Eventually you should benefit from the routine of doing what seem to to be unrelated tasks.

In Scrum, there are only a few roles (Scrum Master, Product Owner and Team Member), artifacts (Product and Sprint backlogs and the burndown) and ceremonies (daily Scrums, planning, reviews and retrospectives). It’s a simple framework that gives a team a focus (step 6) to start from.

Later, more advanced techniques can be used (step 7) and eventually you will have the agility to adapt to the situation at hand (step 8). The outcome of this is better development and a better product that makes the customer happy…you’ll get the girl (step 9).

The discussion after my spiel touched on points such as making sure that you inspect what you’ve been doing at regular intervals  with retrospectives and adapt what you’re doing for the future. We also discussed length of iteration 1 week, 2 week, 3 week, 30 days and even half day iterations.

While typing this up, I discovered a similar post by Jeff Gothelf in New York that relates The Karate Kid with User Experience and agile. Great minds think alike, or at least similarly!

I really enjoyed this month’s meetup and I’m looking forward to the next one.

Being Mr Miyagi and the Karate Kid

Update – I’ve done a follow up post.

I’m doing a talk at the Melbourne Scrum User Group‘s “Lightning Talk meetup” next week.

The deal is this: People take 5 minutes to pitch an idea at the audience.  We follow up with 10-15 minutes discussion and then move onto the next speaker.  We keep going until we run out of talkers or time.

I am going to do a 5 minute spiel which has the working title “Being Mr Miyagi and the Karate Kid“. It could also be called “Do or do not… there is no try” but I felt like being martial arts and not sci-fi :)

No slides, just a few bits of A5 paper. I will update this post, after the fact and let you know how it went.

Change and improvement

This podcast episode of the architecture and design show 99% Invisible from radio KALW in San Francisco appeared in my Twitter stream today via @kjscotland (Karl Scotland).

99% Invisible-30- The Blue Yarn by Roman Mars

I probably don’t have to tell you that the lean concept in software development is adapted from the automobile manufacturing industry. In this podcast episode, a really interesting case study is shown where continuous improvement by reducing “waste” was achieved at a cancer centre in Seattle by adapting the Toyota Production System to healthcare.

Here were some salient points that I thought were notable in this:

Change is hard

“When Dr Kaplan told his staff they were changing the whole way they operate…the response was not pretty…There was a lot of anger…led by the doctors of course”

Change is hard. The improvement at The Virginia Mason hospital was a multi-year project. The driver of all the improvements was the needs of the cancer patients (as well as the need to save money). However this butted against the desires of some of the doctors e.g taking away offices with good views. Changing from a doctor driven experience to more patient driven experience is hard.

A different angle

“We couldn’t conceive of it intellectually until we saw it visually”.

People think they are dealing with an issue intellectually but until they see the situation represented in a different way…using a blue ball of string and a map of the hospital in this example, they might not be able to see where improvements can be made.

Using a different approach identified that waste existed in the form of patients having to wait a lot but until a different approach was…no one identified this. It was just the way things had always been done.

Sometimes people need a kick start. In general, people don’t really like being told what to do, although IMO there are times when this needs to happen but that’s the subject of another post. Helping see issues for themselves allows them to then work with you and their colleagues to solve them.

Jargon

“If you’re anything like me when you hear the phrase ‘management system’ part of your brain begins to shut down. Another part of your brain prepares itself for hearing either a load of complete nonsense or common sense tarted up with unnecessary jargon”

In many walks of life, issues can be over complicated by the use of  jargon. Speaking in plain language is preferable; be careful about introducing terms like “sensei” or “Scrum Master” for example. Providing some terms as a framework can be useful but you have to be careful about them getting in the way.

Effort = Results

Putting in the effort to change yields results, despite the difficulties. In this example, it saved money by making the hospital safer and by eliminating waste and (presumably) helped the cancer sufferers themselves, improving the clinical experience by considering their needs as a priority. User Experience design for healthcare.

Further reading

There is a book about the Virginia Mason experience called Transforming Health Care: Virginia Mason Medical Center’s Pursuit of the Perfect Patient Experience

Amazon page

Publisher page

Here is a review of the first 3 chapters over at The Lean Blog

Lean Blog review

I haven’t read the book but it’s definitely on my “To Read” list.

The 99% Invisible podcast seems pretty good. I’ve subscribed on iTunes and it’s also available on Soundcloud.

Agile Retrospectives – Learning Matrix

When I first started helping out an agile team, we read User Stories Applied by Mike Cohn and then muddled our way through it for a while. It was better than what we had been doing before but the blind leading the blind is a phrase that comes to mind, when I think back on that time.

A little later, I did a Certified Scrum Master course, with Geoff Watts and was introduced to the book Agile Retrospectives. This made many missing puzzle pieces click into place. At first, I thought that my team would find the activities that are outlined in the book to be far too “American”. However, once they got into it, it became apparent that being able to look back on what you’ve done as a team and then identify ways of getting better at it on a regular basis, was hugely valuable.

You can see above, the Learning Matrix that we just did for a new project with a team of 3 developers who haven’t really work together in a structured, agile way before. It’s small steps at the moment but It getting better all the time…which is the point really!

For those that don’t know, the smiley lists things that the team thought went well, the “frownie” lists things that could do with some improvement and the lightbulb are things that you want to implement in the next iteration (yes I know that CI and TDD are odd things to be implementing for Sprint 2 and not Sprint 0!). Finally, the flowers denote people who you want to give special recognition (kudos) to. In this case, it was Pablo for adding polymorphic references and single inheritence to  his Symfony 2 ORM “Mandango”. Kudos!

Story cards for new project

via John's Twitpic

As my lead developer, @johnwards Tweeted…

The pile of user stories for my next project, <insert swear words here>