Follow littlehelper on Twitter

About

via Delicious

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

Why I started the LAST Mini-conference

LAST Day Melbourne is a one day, low cost, grassroots mini-conference for Lean, Agile, and Systems Thinking practitioners. The day will be structured to allow participation and interaction via workshops and activities, rather than death by projector.

Regular readers will remember my writeup about Agile Tour Sydney. That article had a call to action, regarding doing something along the same lines, here in Melbourne.

When I got back, I was able to enthuse Craig Brown, a fellow co-organiser in the Melbourne Meetup scene and we’ve been working on the idea for the last couple of months.

Originally, we wanted to do something really rapidly, holding the event in March, or even February. The Agile Tour is held between October and December, and I just couldn’t wait that long for Melbourne to have its turn.

Reality stepped in though, as we realised that we probably needed a little time to clear the New Year season and get our ducks in a row. Plan B was some time about now, perhaps just before or after Easter. We needed to have some space between our day and Agile Australia, which is in Melbourne at the end of May.

Eventually, we’ve settled on 27th July. Swinburne University of Technology in Hawthorn are our hosts, and we had to work in with the availability of the venue. We’re also aligning ourselves with the Developer, Developer, Developer day, and also Barcamp Melbourne; both of which will be held directly after our event, and we believe have a similar philosophy.


Craig argued the case that we should be quite broad with our outlook. So after some old fashioned brainstorming,  Systems Thinking, as well as Lean and Agile, were included in the name of the day. I had originally earmarked lastevent.com or lastday.com but the domain name registries had other ideas, so LAST Conference it is. I’m billing it as a “mini-conference” though, as I don’t want it to be a typical, big bang conference. We really want to borrow heavily from the “for practitioners, by practitioners” ethos of Agile Tour, and also the spirit of things such as Bar Camp, and Trampoline Day.

The emphasis on “Thinking” is no accident either. There is sometimes a tendency to have a focus on “best practice”, “techniques”, “tool kits”, and “cook books”; focusing on the How and less about Why we’re doing them.

We’re keeping the day affordable. The “normal” fee for registration is $50 but we’ve got discounts for those who book in early. We want to cover expenses and to encourage a commitment that a no cost event lacks.

I’m really excited about how this event can help the Melbourne agile and lean community.

To find out more:

“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

Agile Tour Sydney 2011

What does Sydney have that Melbourne doesn’t? Well apart from the Bridge and the Opera House, this year Sydney hosted the first Australian instance of the Agile Tour, a series of non-profit, independently organised events held worldwide between October and December. Agile Tour originated in France in 2008 and has since spread to many countries, with the stated intention to:

“communicate massively together, all agile people, in the same period of time to help all cities to promote the ideas around the Agile, a way to manage complex project [sic]. Since 2008, this idea continues to create new stories, new cities continue to join us around the world and we want to accompany them to understand and discuss their vision of the [sic] Agile wherever there will be projects and people.”

The inaugural Agile Tour Sydney was held on 9-10 December at the University of Technology Sydney and was labelled “By practitioners, for practitioners”. Two of its main organisers were Jeremie Benazra and Karan Jain.

I decided that I should go for a trip up to Sydney to see what transpired and see if we could use some of the ideas in the future, in Melbourne. Here is a brief write up and a call to action at the foot of this article!! I would echo Rowan Bunning’s tweet:

Agile Tour Syd turned out to be the most immersive Agile conference experience I’ve had in Australia. Thanks everyone.

Continue reading Agile Tour Sydney 2011

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?