Tag Archives: Agile

How we can work smarter

Leave a reply

question markDeakin University’s CIO William Confalonieri’s paper The CIO Reborn. Emerging from a profound identity crisis to seize the future sets a number of challenges for enterprises, including the following:

  • How do we pioneer new customer engagement strategies?
  • What delivery models best fit the challenge of digital disruption?
  • How can workforce enablement make us more able to adapt to this new, still forming digital environment?
  • How do we build a culture of sustainable enterprise change?
  • How can we assist the business to reinvent itself from the front-end?

I would add to that list, how can we offset the financial risk associated with predicting our digital future?

ADOPTION OF AN AGILE LEAN MODEL

An Agile Lean model sees enterprises utilising the following principles:

  • That business value based prioritisation will get rigorous consideration into planning
  • That self-managing cross functional teams are the engine room of adaptive delivery
  • That embedding a build-measure-learn cycle allows more attentive response to customers
  • That a mindset of continuous improvement will drive enterprise change
  • That incremental delivery will offset the financial risks of big bang delivery

HOW THIS MODEL SUPPORTS TACKLING CHALLENGES HEAD ON

New delivery models = better engagement with business

The key strength of Agile methodologies is intensive business engagement. In traditional projects the business provides requirements and then exits until the project is delivered. Using an Agile approach, the business works hand in glove with technology teams. The business is available on a daily basis to plan, answer questions and approve the incremental delivery of work.

Incremental delivery = offsetting financial risk

The risk of the big bang approach to technology delivery is twofold:

  1. Digital disruption may have changed the landscape by the time the project delivers
  2. Return on investment is not realised until the end of the project

Agile incremental delivery offsets these two risks by:

  1. Providing early delivery of features to fit an ever changing market
  2. Immediate return on investment through deploying the most highly prioritised features first

Improved customer engagement strategies = success

The following Lean Startup principles closely engage customers to enable enterprises to succeed:

  • Validated learning through testing our assumptions about our customers
  • More innovative accounting to set the right milestones and measure progress
  • Implementing a build-measure-learn cycle to understand how customers respond, and then learn whether to pivot or persevere. This accelerates the customer feedback loop.

Workforce enablement = greater engagement

Agile teams are self-managing and more productive than non-Agile teams. Teams are comprised of the following roles:

  • Product Owner – who defines what is going to be built and is the conduit to the business, primarily responsible for prioritising delivery of assets based on their business value
  • Scrum Master – the servant leader, who removes obstacles on behalf of the team, monitors in-build activity and manages the flow of reporting information
  • Developers – the engine room of the team who are empowered to suggest improvements to product features or team processes

Agile is a pull model, where teams commit to sustainable delivery of work, rather than a push model, where a Project Manager delegates work. This model of workforce enablement leads to greater engagement, idea generation and ability to respond to a still forming digital environment.

Building a culture of sustainable change = continuous improvement

Building a culture of sustainable enterprise change is a mindset change for many organisations. Organisations can foster change by:

  • Supporting teams in adopting the Agile practice of reflecting on how to become more effective, then tuning and adjusting accordingly
  • Creating opportunities for individuals and teams to learn about Agile best practice through brown bags and guest speakers whose ideas may rock our own
  • Encouraging continuous improvement, and investing in the technology and expertise to support it

Supporting business reinvention = creating new job roles

Enterprises need the right level of support to introduce the Agile Lean practices that will see them tackling challenges. Agile Lean Methodologies cover many concepts and principles and are not something simply learnt by attending a course. Key to supporting business reinvention is creation of job roles that fill the following gaps:

  • Provision of Agile coaching, to support practitioners in the delivery rhythm, until they become self-organising to deliver independently
  • Support for the Senior Leadership team on coming up to speed with Agile practices
  • Identification of gaps and opportunities for improvement in Agile practices
  • Development of an Agile framework that will fit both operational and project delivery teams
  • Examination of what program management means in an Agile context
  • Investigation and implementation of a model for scaled Agile delivery
  • Adoption of a successful model to encourage practitioners to share ideas through communities of practice within win outside of the organisation
  • Support to develop a greater emphasis on building the ability to measure into everything we build

 

How Lean can a pizza be?

Leave a reply

lean-pizza_croppedThe other week a diverse group of Agile, Scrum and Lean practitioners from the Geelong area got together at the Waterfront Kitchen to figure out just how lean a pizza can be!

Lean startup is a method for developing businesses and products first proposed in 2011 by Eric Ries.  Based on his experience working in several US startups, Ries claims that businesses can shorten their product development cycles by adopting a combination of business hypothesis driven experimentation, iterative product releases, and what he calls validated learning.  The concept has wildly taken hold outside of the startup arena, as it promotes enterprises reducing market risks by iteratively building products or services to meet the needs of early customers, thereby sidestepping the need for huge initial project funding and expensive product or system launches and failures.

Lean startup aligns really closely with Agile, which harnesses an iterative, rather than extended development cycle to better fit product, system or process development to what users need or want.

Geelong Lean Coffee, the community of practice I founded some months ago to get Agile practitioners in Geelong meeting to share ideas, organised the event.  We teamed up with another newly formed community of practice, Geelong Entrepreneurs, to bring together likeminded professionals invested in using Agile, Scrum and Lean startup to succeed.  The evening was sponsored by Deakin University as a means to contribute to building economic, social and human capital and facilitate conversations about Agile in the Geelong and Deakin community.

The guest speaker for the evening was Simon Cuce, the Software Development Manager from Xero Accounting Software. Simon told the great story of how Xero have grown from a startup in 2006, to a globally successful enterprise using Agile, Lean and common sense. Topics covered included how best to manage the product backlog, good conduct at the daily standup, how Xero uses a variant of the Spotify “tribes” model, and much more.

What really impressed us was Simon’s description of the enabling culture at Xero.  It’s an environment where staff are empowered to do a great job and where innovative ideas easily bubble to the top.  At Xero, business value is equated with customer value and coupled with the Agile framework, teams can quickly pivot to get great features to market.

The benefit of events such as this, is that Agile practitioners can learn from others in the community and contribute their knowledge to building a Digital Geelong.  Some of the conversations on the night saw Geelong professionals collaborating with the guest speaker about spinoff ideas that utilise APIs to develop new products collaboratively with Xero.

We are enormously grateful for the university’s support of this event.  Being able to have access to the wonderful Waterfront Kitchen after hours provided a central venue for all to attend, and if you measure value based on the calorific content of the incredible salami pizzas served on the night, then all who attended could attest to the enormous value of the evening.

Applying Lean Startup thinking to product development

Leave a reply

railway_station_500x377This morning on my way into work, I was traveling from a different train station. Totally unfamiliar with the station layout, I was for a moment, confused about which end of the platform to stand on. I would be exiting the train at Southern Cross station, and I wanted to be at the Collins St end of the platform when I exited. Another passenger must have registered my puzzled expression and asked me if he could help. I explained that I needed to commit to waiting for the train at one end of the platform, or at the other end, and that I would either be very wrong, or right. At that moment the thought struck me that this was a good analogy for Lean Startup thinking in product development. If I was right, then I’d have only a short walk to catch my next train. But if I was wrong, then I’d know just as soon as I arrived, and I could correct my path.

In his 2011 book, The Lean Startup, Eris Reis proposes that key to the success of new product ideas is testing your assumptions. Rather than launching with a fully-fledged product, on which you have expended huge amounts of effort and money, he advocates for pushing to market at least some features, to test your assumptions about what would be useful or attractive to customers. This allows you to fail early and inexpensively, or succeed early too!

There are a few approaches to this. One is what he calls “smoke and mirrors”, which is more an approximation of a product than the real thing. It provides some functionality for customers, but this is not necessarily driven by the end state processes or software. Instead it simply approximates the end state, so that you can test if the end state is going to meet customers’ expectations, ahead of investing in building the end state.

The advantage of taking this approach is pretty clear. You can validate your assumptions before investing the resources to build the end state. In the university, this type of model could apply if we were building a new online form to replace an existing process. Our product vision might be an end to end process that collects the information required from students and manages cross faculty exchange of information. Taking a Lean Startup approach, perhaps we could build an interface that collects the information, simply to validate that it will be compelling for students, but retains some manual manipulation of data, just until we validate we are collecting the right data and have created a form that is compelling enough for students to engage with. Obviously the “smoke and mirrors” manual part of the process can be replaced with a digital solution once we have validated our assumptions, and perhaps pivoted to find the optimal way to collect the initial information required.

Another way that Reis suggests arriving at an optimal product is through releasing something that may not entirely constitute a minimum viable product. He argues for putting aside our deeply held beliefs that we can only launch an end state high quality product. Where a product provides new and exciting functionality for users, assumptions about if it will be useful and compelling for users, also need to be tested. By launching with just one feature, instead of a planned 10 features, users can still interact with the product and provide feedback and requests for additional features that can be built in response to this.

In my work environment, this might look like us responding to some website feedback about a certain feature that users would like to see on the website. We might develop the beginnings of this feature and then advise the users who requested it to have a go at interacting with it. By engaging in a dialog with users around the beginnings of the feature, we are most likely to be able to shape it in such a way that it best fits users’ needs.

Resisting the urge to hold back until a fully featured version is available can be a huge mindset change. Essentially though, this type of scenario is typically played out with early adopters, who are the intelligence behind driving future features and pushing the boundaries of the Internet of Things. These users tend to be heaps more tolerant of early prototypes and appreciate engagement on development of product features.

My first scenario in this post was about being right, or very wrong. Obviously the stakes aren’t very high, when all I’m doing is choosing between which end of the train platform to stand on. The idea in Eric Reis’ Lean Startup model, accords with this though. Test your assumptions early and always, when the stakes aren’t high. Users will appreciate it, and so will those holding the purse strings to your product!

The “What’s next?” of Agile – Business value part 2

Leave a reply

what-next-300x188Having covered some basic concepts of business value based prioritisation in my previous blog post, this one is for those who want to take the next leap into backlog grooming.

Prioritising initiatives based on business value makes sense, because it helps you see return on investment. But what happens when you have a whole bunch of initiatives that all contribute to something that is highly valued, such as improving user experience.

My team was recently in this situation. Scattered throughout our backlog were a whole bunch of stories that loosely fell under the umbrella of optimisation activities. Many of them didn’t have sponsors in the business, so there was no one to plead their case. Some of them couldn’t demonstrate a huge improvement in user experience, but would deliver efficiencies for our internal workflow, and hence help free up our time to deliver other initiatives with high business value. Some resolved what we call “technical debt”, which refers to the eventual consequences of poor system design, software architecture or software development within a codebase.

So, it was clear that these stories had business value, but how would we decide “What’s next?”.

I decided to go back to a classic Agile technique that sees you measure the business value of a story against the ease or difficulty in actualising it. My approach is always to involve the team, so I ran a workshop where we gave these stories their own time in the sun. We looked at each of the stories and rated their business value on a scale of 1 (low business value) to 3 (high business value). Then we rated the stories on 1 (easy to deliver) to 3 (hard to deliver). For each story we were able to derive a priority rating by dividing business value by ease of delivery. For example, we decided that creating reusable form assets had a business value of 3, and an easy of delivery of 3, so its priority score was 1 (3/3=1). Another story had a business value of 3 and an ease of delivery of 1, so its priority score was a 3. (3/1=3). This allowed this story to be prioritised above the reusable form assets.

When we ordered the stories we’d been grooming by their priority rating, the prioritisation felt pretty right!

This technique was useful for us, both because it made us really consider the stories and their business value, but also because it helped us truly prioritise pieces of work in our backlog. What we also learnt was the power of putting our heads together to make the assessment around “What’s next?”.

The “Why are we here?” of Agile – Business value part 1

Leave a reply

why are we here questionI recently delivered some lectures to Deakin University undergraduate and graduate project management students on Agile. To get an idea of who was in the room, ahead of starting the planned presentation, I asked the students what they were studying. There was a smattering of business students, some computing students, a law student here or there and a bunch from diverse fields such as event and arts management. What would my message be to this assortment of students who would be working in fields so diverse from each other? That Agile is driven by prioritising delivery based on business value, but that business value looks very different depending on where you are!

I like to use examples drawn from my real world business experience, and in this case, it’s kind of obvious that when you are prioritising user stories within a backlog at Telstra Digital, you’ll be looking for those that will lead to increasing sales of products online and reducing costs of servicing customers through online self-service. User stories that accord with this business value will bubble to the top of the product backlog and within any epic, you’ll decided just how many stories deliver enough business value, before tackling the next epic that again delivers this business value.

I really liked the approach we took to assessing business value at Australia Post. Increasing revenue and reducing cost were on our menu of business value criteria, but we further categorised this into significant increase to revenue, or minor increase to revenue. We did likewise for cost reduction. This allowed us to prioritise a significant cost reduction initiative above a minor revenue increase initiative. We did take into account customer experience improvement initiatives, but these were always quantified in terms of how they would impact revenue increase or cost reduction.

In a university environment business value can be harder to quantify. At Deakin our measures are closely tied to our LIVE the Future 2020 Agenda. Learning relates to offering a brilliant experience where you are and where you want to go. Ideas relates to making a difference through world class innovation and research. Value relates to strengthening our communities, enabling our partners and enhancing our enterprise. Experience relates to delighting our students, our staff, our alumni and our friends.

So how do you truly evaluate if the products and features you are delivering add business value?

I like to ask the “Why are we here?” question. DeakinSync is Deakin University’s flagship online portal that allows students to access what they are likely to need in one place through a single logon, be it timetable, access to their school or faculty, email, industry placement info, or other important information. Students can even access the learning space, Cloud Deakin, to view lectures, interact with other students and submit assignments. The customer experience of DeakinSync as a single personalised experience for students is incredibly high, but once again its business value relates to how it aligns with the LIVE the Future Agenda.

The DeakinSync team know that the product’s rationale is to aggregate services and provide a fabulous experience for students, something we value very highly at Deakin University. By asking the “Why are we here?” question, it reminds the team that features still in their product backlog can be prioritised based on how closely they will align with product’s ability to enhance customer experience, drive retention, reduce costs associated with providing great experience and support Deakin as a sustainable enterprise. The message about business value then, should be that you need both to align with your enterprise’s core business drivers, but also to look at what your team individually contributes to this bottom line.

When playing pool in the kitchen is just that!

Leave a reply

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.

In Agile hills are epic

Leave a reply

Hill-training

Some of you may be aware that earlier this year, I started running. This is something I’ve tried to avoid in my life up until this point, because, quite frankly it has seemed too hard. I always blamed this on the hills around my home, not my lack of fitness. So recently, while running up a hill, it struck me that a hill is just a mindset. To put you in the picture, my usual 6.5km run, starts with the steepest hill ever, followed by downhill, about 2km of level running, then up and down another hill, before returning on the same route.

Mentally, I tackle the run by breaking it into manageable chunks. Firstly there’s the uphill run, and it takes longer and certainly more effort, than the downhill run. The level part is really quite straightforward. I size the second uphill and downhill part by comparing it to the first one. It’s not quite so bad, but maybe this is because my legs are warmed up and no longer objecting to the cold winter’s morning.

At a certain point, during my run last weekend, I began wondering if my approach was because of my Agile mindset. Agile looks at a body of work and calls it an epic. Here’s an example of an epic: “As a student, I want to submit a Change of Enrolment form online, so that I don’t have to fill out a paper based form”. An Epic is further broken down into “stories”. These are the smaller chunks of work that need to get done in order to deliver the epic. These might look like this: “As a student, I want to be able to fill out a form and hit submit, so that I can get an acknowledgement of submission of the form”, and “As a student, I want the form data I submitted to be emailed to the faculty, so that it can be approved”. The advantage of breaking an epic down into stories, is not just because the work can be tackled in these smaller chunks, but because it’s easier to estimate the amount of effort required to complete these chunks of work and schedule accordingly.

In our team we size stories according to small, medium, large and extra large. When we go to size a story, we look at it relative to other stories. So in the case of the Change of Enrolment story, if we previously completed a similar form, we can estimate the size of this one, by thinking, that last time that form was a medium, and this one is more complex, so we’ll estimate it as a large. Estimation is run as a group activity in Agile, and this helps the team use their joint knowledge of our history of typical tasks to agree on an estimate.

Agile values relative sizing, rather than absolute sizing, because it acknowledges that sometimes you need to size something without all the information to do so. Certainly, it’s best to have as much information as you can, but given that there is often time pressure to define a project timeline, relative sizing, is a way you can develop a fairly accurate estimate.

So, back to my hills. It’s clear to me that sizing the hills, helps me break the run down into bearable chunks. I know, as I approach my second uphill bit, that there will be a downhill bit that’s just 2km from home. Sizing makes the run feel achievable. I’d even go so far as to say that it was probably estimation that helped me complete my first ever fun run – the Mother’s Day Classic, where I’m proud to say I placed 3775th! During my practice run, I even sized the notorious Anderson St hill on the Tan, as less grueling than the hill of horror near home. Right now, I now have my sights loftily set on a 10km fun run. After all, it’s just 6.5km with a couple more stories.

And finally … Agile up in lights at Southern Cross Station

Leave a reply

Talk-moreThe other morning, on my way down to work in Geelong, I spotted the following illuminated sign at Southern Cross station, “Desk less, Go talk to Jen, three desks away”. Well, I thought, now it seems that even the Victorian Government is supporting Agile!

Agile emphasises the concept of communication within a team. Various Agile “ceremonies” facilitate team members conveying information to each other face to face. If you visit an Agile workplace, then throughout the morning, there’s a certain choreography around this type of communication. Teams will spontaneously get up from their desks, head to a spot where they can congregate, and whilst standing in a circle, they’ll one at a time communicate what they need to tell each other to keep the team’s work moving for that day. This is not a meeting, it’s a “stand-up”.  The aim is to communicate with each other, specifically on the work that the team has committed to completing during that sprint (iteration). Each person takes a turn to describe: 1) what they completed the day before, 2) what work they intend to complete that day, and 3) what obstacles they need to resolve, to move their work forward. It’s really efficient to be able to catch the right person to resolve an issue there and then. Conversations, usually go something like this, “I’ve just finished putting together this form, and now I’m finding that the thing won’t submit. Can anyone give me a hand to figure it out?” or “Katrina, can I catch up with you straight after stand-up to understand out how we move forward with ….”

In our team stand-up is holy! You don’t miss it, you don’t come late and you don’t waffle on about stuff that’s not directly related to completing the work in that sprint. It’s the one time in the day when you know everyone is present, listening and ready to resolve roadblocks.

Another ceremony that punctuates a sprint, is the “retrospective”, or “retro” at the end of each sprint.  This is not a post implementation review! A post implementation review takes place when a project has been completed, there is no opportunity to change things, and the project team may be on the cusp of being disbanded. A retro is the opportunity to acknowledge the stuff that’s going well, recalibrate what’s not working and address things we are still confused about. There are a whole bunch of creative ways you can do this, but essentially it all comes down to the team feeling open enough to structure their communication into three questions:

  1. What should we be doing more of (i.e. what went well)?
  2. What should we be doing less of (i.e. what didn’t go well)?
  3. What still puzzles us (i.e. what do we need to define more)?

Where a team is able to communicate comfortably, retro results can be powerful in continually adapting learnings and making a commitment to doing less of the stuff that’s holding the team back. Agile teams are self-managing, so they are empowered to make decisions on the sort of things that help them achieve the best velocity on their throughput, such as the duration of their sprints (work iterations), or how they estimate their work.

The outcomes of retros might look something like this:

  • “The way we figured out resourcing for this sprint really worked for me, because it meant we got through all the work in the sprint”
  • “It didn’t work for me that some people missed the beginning of our planning meeting, because it mean we didn’t have everyone available to commit to the work in the sprint.”
  • “I’m still confused about what our course of action is when we have been waiting too long for approval on assets to go live.”

Back to Jen, who is just three desks away. Agile hates email, and to a certain degree instant messaging. If you send someone an email, wait for the response, read that response and find you have another question, wait for the response on that question, you begin to understand just how inefficient it is to have sent the email in first place. Where you need to ask someone something, you look up, see if they are at their desk and go over and ask them the question. If it’s a question that will help a single team member or the whole team get on with what they need to be doing, then having a culture where you can resolve it quickly is essential.  Agile is an extremely respectful way of working, so if someone is focused on a task that they cannot deviate from, it’s also ok to say, “Will it work for you if we catch up in 5 minutes?”

In a well-designed Agile workspace there are breakout areas where a few people can go for a more extended conversation. These aren’t bookable meeting rooms, but rather comfortable areas where team members can collaborate for 10 minutes or half an hour as required. These physical spaces support team members coming together for spontaneous problem solving.

Where teams are geographically split, you can’t just pop over for a quick conversation. IM is useful, but tends to be a bit like sending an email and waiting for a response. The telephone is good and Lync video is even better. In fact, it’s sensational!

Given that adopting Agile communication, is not only effective, but also great for your physical health (all that getting up from your desk), consider giving it a go!

Lean coffee – not quite an Agile weight loss program

Leave a reply

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

Leave a reply

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