agile articles « Projects' Little Helper

“Do food”

This is about the pattern “Do Food”, that is found in Linda Rising and Mary Lynn Mann’s excellent book Fearless Change.

Our small team had to prepare weekly reports. We hated this job and the wasted meeting time it took each week.

Someone told me that the next meeting was our team lead’s birthday, so I bought chocolate chip cookies…

It was as though we’d been living in a cave and someone had turned on the lights. People smiled…The meeting was fun. We joked about…the task we all hated. We finished early. All this from a few cookies.

— Fearless Change p.132

Food can have a transformative power that is described in the above story, and research has shown that human societies use food and the practice of eating together to help create tighter relationships. Think of all the times that we eat together with people inside and outside of work. Similarly, having something to eat in a planning meeting, review, or retrospective can have a positive effect on your team.

Rising and Mann go on to mention that food is not always appropriate due to the organisational culture of a company, or the nature of a meeting, and that you should also be mindful of peoples’ allergies and intolerances. There may also be a constraint due to the cost of food, and suggest ways to compensate.

I like the “Do food” pattern a lot. The photo at the top of the post is from an end of iteration review and retrospective session on a project that had a budget for food, and I can attest to the benefits that having a decent selection of food can have. We always tried to be varied, having some healthier options available, and also catered for our colleague James’ gluten intolerance.

Here’s a few more examples of other food selections we had during that project:

Continue reading “Do food”

Creating a Product Backlog — Story mapping

Story mapping is at the front of my mind for a couple of reasons. The first is because I attended a recent agile meetup (under the auspices of the Melbourne Agile Business Analysts group) that covered the topic.* The second is because I have spent much of last week helping out a new agile team to use story mapping for their first agile project, as you can see above.

A lot of people refer to Jeff Patton’s The new user story backlog is a map blog entry from 2008. At the meetup, it was mentioned that Patton admits that he wasn’t the first to come up with the idea of visually representing a product backlog. He views it as a pattern rather than an innovation, as he puts it in his plog post:

I always remind myself of the litmus test for a pattern. If you explain someone a concept and they say “what a cool idea!” it’s not a pattern. But if they say “we’re doing something like that too!” it’s a pattern. I’ve seen this often enough now that I believe it’s a pattern. – Jeff Patton

“Back of the door chunk priority list”

Here’s a war story about a product backlog that was created back in 2006 which is something like what is now commonly known as story mapping. I can see some aspects of the story mapping pattern in the way the backlog was assembled on that project. At the time, I didn’t really have a name for it, but if forced to name it now, it would be, “Back of the door chunk priority list”. Catchy, eh?

Continue reading Creating a Product Backlog — Story mapping

The importance of having “air support”

I came across this interesting Xtranormal video created by the folks at UPMentors via David Joyce’s recent blog post “Agile, Lean, and Kanban, Do They Change Management Thinking?”

You can see what UPMentors have to say about it on their blog post that accompanies the video.

I can definitely see echoes of the different scenes that I have encountered since I’ve been working as an agile manager. I’ve been fortunate enough to have worked on projects where there has been a clear mandate issued from management to allow us to get on with the job. This CEO and CTO level backing has its blessings and also its drawbacks. On one hand, having some top-level management providing “close air support” for us allowed us enough freedom to not be tied into institutional red tape and to be innovative. It allowed us to deliver what I consider would have been impossible to do were we forced to conform to the “standard operating procedure” playbook.

A flipside to this is that we discovered that this was considered by other parts of the company to be receiving “special treatment”. Circumstances evolved such that our “air support” was removed and then all of the behaviour seen in UPMentors’ video started to rain down upon us.

It’s definitely possible for institutional issues, as raised in the video, to be mitigated against although sometimes it can sometimes feel like it’s just you vs the system. It’s pretty hard to fight all of these battles while still trying to work on effectively deliver value for your project at the same time.

So, I’d definitely agree with a lot of what David says in his post. It really helps to have someone flying air cover for you.

I’d be interested to see what you have to say about this. Have you encountered any of the behaviour that is displayed in the video? If so, what have you done in response?

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.

Mr Miyagi
Daniel
Wax on, wax off
Sand floor
Paint fence
Daniel punching a target on Miyagi’s chest protector
Miyagi and Daniel (doing a Crane stance) in the style of the Simpsons.
Daniel fighting the Cobra-Kai at the tournament
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.

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.

Projects' Little Helper

Agile Articles

About

Article categories

via Delicious