Category Archives: Scrum

What to do when you first meet the team you’re coaching

Leave a reply
Starting to Coach a Team

Victoria Schiffer & Russell Baghban, Agile Coach Camp Melbourne 2017

How do you approach first contact with a team you are about to coach? This was the question I posed at Agile Coach Camp Melbourne, where I facilitated a session on this topic.

Four brave souls volunteered to role play a team meeting their Agile Coach for the first time. Each team member played the part of someone new to Agile. The team member’s responses varied from apprehension and fear, to curiosity and even bravado. It was a hard gig for the Coach!

I’d like to thank the 15 or so engaged folk who generated the ideas so ably summarised by Victoria Schiffer and Russell Baghban’s visual depiction of the session. Here’s my deeper exploration of the ideas shared.

Start with a warm handover

It’s easy to know when the coach’s sponsor hasn’t provided a warm handover of the coach to the team. It sounds something like this – “I’m not seeing the output I’d expect. I’ve brought in an Agile Coach to improve things”. This isn’t a warm handover!

Sponsors can set a coach up for success by being honest, but not brutal – “I know you are working hard. We’re still encountering road blocks as we implement an Agile way of working. Given that this is new for us, I’ve brought in an Agile Coach to support you.”

Sometimes a coach will find there’s been no expectation set of what the coach’s role will be. In the absence of any handover whatsoever, the coach will need to explain what a coach can do. How the coach will support the team, is an ongoing conversation.

Form a coaching triangle

A coaching triangle refers to the relationship between sponsor, coach and team. Before beginning to coach a team it’s essential for the coach to understand the sponsor’s expectation of the coach, and of the team. This is tricky, as the coach may discover there’s a need to influence or coach the sponsor, to guide an effective outcome.

Establishing a good relationship with the team is essential for the coach, but keep your expectations for the first meeting at “let’s get to learn something about each other”.

The coach must also be aware that the team’s relationship with the sponsor is most likely one of history and expectations. While it’s great to be a catalyst for new ideas, a good coach seeks to ensure the team and the sponsor are in step.

Listen listen listen

Michael Bungay Stanier expresses it best when he says, “Get comfortable with silence”. When you are meeting a team for the first time, the temptation is to launch into a description of who you are and what you want to achieve with the team. Some folks even suggest that putting together a coaching contract should be the first thing on the coach’s agenda.

Resist the urge! Consider starting with, “Tell me about you guys”, then simply listen listen listen. Sure, you might ask a few questions along the way, but in Bungay Stanier’s words “bite your tongue and don’t fill the silence”. The silence that follows a question you’ve asked is the person thinking, and that’s great!

Don’t set an agenda

Truly… don’t set an agenda for the first meeting. Let that meeting be an opportunity for the folks in the team to talk, and to tell you what they want to tell you. It’s the first best time to get insight about who each individual is, and how they interact. Is there someone who is quieter than the others? Why might this be so? Do individual’s perspectives cohese, or diverge? Is there defensiveness, resistance or hopefully curiosity about what comes next?

Don’t feel you have to direct the conversation – let it unfold. Sometimes holding the first meeting in a coffee shop, rather than a meeting room, can reduce the awkwardness, and help folks feel more comfortable.

Express curiosity, but don’t solve problems

When you are introduced to a new team, the perfect prop can be the question. “How does your work fit into…?” This allows a team to explain their understanding of both their work, and the obstacles they face. This is not the time to solve problems, but rather to express curiosity and learn more.

Bungay Stanier again, talks about “Taming the advice monster”. There will be a time to discuss approaches and even offer advice, but not in the first meeting with a team.

The wrap up

The best wrap up is to leave folks ready for what might come next. Propose another opportunity to meet. Suggest the team might think about things they are curious to learn more about, or some of the obstacles they mentioned in this meeting, and take it from there.

If you do choose to put in place a coaching contract with the team, you’ll know when it is the right time, but it’s rarely at the first meeting.

The infographic accompanying this post is the collective wisdom of those at Agile Coach Camp. During the session there was divergence of opinion on many of the ideas that surfaced. What we all agreed on though, was that change is not prescriptive. Use your first meeting with a team to begin the process of building trust. It is what will be required for the team’s change journey.

Agile Maturity Checks – Use with Caution!

1 Reply

Agile maturity check

Just saying it like it is. My favourite Agile maturity measure is the one in the picture above! I like to invite a team starting out in Agile to create a histogram of how they as individuals feel about their comfort level with Agile. I know that Agile maturity checks are loved by management, but I think they’re less useful to teams.

At work I put some time and thought into developing a maturity model that spans Lean system thinking, Lean Startup, Agile and DevOps practices. I modelled it on Spotify’s team health check, which I do feel is really useful. This maturity check was only moderately useful. I suspect that if you do use it, you’ll make an early maturity team feel a bit depressed and inadequate.

My thinking behind this model was to set the bar of early maturity where a non-Agile team taking their first steps might find themselves. My scale ranges all the way up to mature, which is good practice and I hope, not too aspirational.

It might be most useful to use components of it, if a team discloses a particular area they want to address. The next step might be to use a retro to generate ideas about how they could get from “not yet” to “on the way”.

Take a look at it and use with caution!

  Not yet On the way Mature
Standups We don’t run standups. We run standups sometimes. Standups tend to run over the 15 minute mark. We can’t always see the point of standups. We run standups every day and stick to the questions: what we did yesterday, what we did today, and what obstacles we need to resolve. Standups never exceed 15 mins.
Team rhythm As a team member I’m either too busy or not invited to attend all the Agile ceremonies – standup, estimation, sprint planning, showcase and retro. I mostly attend those ceremonies that I’m invited to – standup, estimation, sprint planning, showcase and retro. As a team member, I attend and contribute to all Agile ceremonies – standup, estimation, sprint planning, showcase and retro.
Process Our way of working is painful. Process gets in the way of us getting stuff done. We have a way of work that is sometimes easy and sometimes hard. It would be great if our process fit us better. Our way of working fits us perfectly. We have just enough process to get stuff done easily.
Speed We never seem to get done with anything. We keep getting stuck or interrupted. Stories keep getting stuck on dependencies. We get through stories, but there are frequently blockers, or process glitches. We get stuff done really quickly. No waiting, no delays.
Requirements Our Agile stories are place-keepers for the work we do. We use BluePrint to articulate our requirements. We are using Agile user stories, but our stories are sometime technical tasks derived from specifications. Our stories are not consistently small, estimable, and independent Our user stories are not derived from a formal documentation process but are captured as business value. They are always small, estimable and independent. We always include acceptance and test criteria.
Analysis Time pressure usually prevents us from having our stories articulated before bringing them into a sprint. We do this during the sprint. Our aim is to get stories ready for a sprint, but accept that sometimes the work just needs to be done, so articulation of stories takes place during a sprint. We have a clear “Definition of Ready”, so we never bring stories into a sprint unless they are fully articulated, including a story statement, acceptance criteria and test criteria
Sizing We aren’t yet sizing our work before bringing it into a sprint. Several team members get together for sizing. We mostly have stories estimated before we bring them into a sprint. We have a regular rhythm of story sizing and involve the entire team in this process.
Velocity We use the stories in a sprint as a guideline or focus for our work. We never complete the stories we plan to complete in the sprint. We sometimes finish stories (including testing) in the sprint. As a team we always finish all the stories (including testing) we commit to in a sprint.
Sprint planning We aren’t yet conducting regular sprint planning. Several team members get together for sprint planning. Sprint planning usually happens, but we usually carry over stories not completed from the previous sprint. We have a regular rhythm of sprint planning that involves the entire team. We all commit to the work in the upcoming sprint and are confident we can complete it.
Agile wall We don’t yet have an Agile story wall. We have an Agile story wall, but it doesn’t necessarily reflect what we are working on, or what is in JIRA. Our Agile story wall is not hugely relevant for us in standups or our daily work. Our Agile story wall is our key source of truth about the progress in a sprint. Anyone looking at it can see exactly what we are working on and where we are up to. It matches what is in JIRA. We use it both in standups and the daily work we do.
Showcasing We aren’t yet showcasing. We showcase when we have something tangible to show stakeholders. This can be between every second and fourth sprint. We have working software to showcase after every sprint. We invite key stakeholders to this showcase and our developers run through what has been built.
Retrospectives & Learning We aren’t yet running retrospectives. We never have time to learn anything. We are too busy for retros and cross team showcases. Time permitting, we run retrospectives. This doesn’t necessarily happen after every sprint. We’re learning lots of interesting stuff all the time. We run retros every sprint. We initiate and participate in cross team showcases.
User experience support
 We are struggling to understand what role User Experience designers play in defining our product and where they fit into the lifecycle. We sometimes tap into the skills of User Experience Designers, but often time pressure prevents us from working closely with them. We have complete clarity on the role of user experience designers in our product development. We integrate their work into stories across all product builds.
User experience integration
 We often find we don’t have time or resources to integrate qualitative (through UX testing) or quantitative (through integration of analytics) customer learnings. We integrate some qualitative and quantitative customer learnings into what we build, but we rarely have an opportunity to run another iteration to further improve our product. We integrate qualitative customer learnings (through UX testing) and quantitative (through integration of analytics) into every feature/initiative we build and deploy.
Testing Testing is owned by the QA/Tester. Functional, non-functional and integration testing is performed at the end of the lifecycle, not necessarily within a sprint. Testing is shared by the QA and Dev. Non-functional and integration testing undergo complete inspection tests. Functional testing is integrated with the build. Testing is owned by the QA, Dev and BA. Non-functional and integration testing undergo complete inspection tests. Functional testing is integrated with the build. Developers practice Test Driven development (TDD).
Build Build is manually performed custom or repeatable, but still manual. Build is performed infrequently. One member of the team owns build. Build is repeatable and automated, but doesn’t happen with maximum frequency. Build is the responsibility of the team. Functional Testing tools (Watir, Selenium, etc) are integrated as gatekeeper events to the build. Integration tests with external tools and products.
Releasing Releases are extremely difficult. Our preference is to release at the end of the project. Releasing is tricky, so we aggregate as much work as possible before releasing. We have a regular rhythm for releasing. It is fast and painless
Collaboration & Communication We consistently find it difficult to get answers to our questions, or resolve issues in a timely way. It is sometimes difficult to get someone in our team to help us out, or resolve a problem when we need it. If we need somebody in the team’s opinion or assistance, we can freely ask that person either at standup or throughout the day and expect a prompt response.
Empowerment – ways of working It’s the job of leadership to suggest how we can work better. It’s sometimes difficult to get traction on improved ways of working, but we give it a go. We feel empowered to suggest how we can work better. Our suggestions translate to real improvements in the way we work.
Empowerment – product We don’t have any understanding of how the customers are responding to the product so we can’t calibrate it. We sometimes hear feedback about our customers’ responses to our product, but incrementing the product in response to this only sometimes happens. Our regular cycle it to respond to learnings from customers. It shapes our backlog.
Contribution We complete our work, but it’s not always clear how the tasks we are performing are critical to the success of the team. We know that the tasks we are performing are critical to the success of the team, but sometimes it doesn’t feel so – . Every day we are at work, we know how our work contributes to delivering a great product. We own creating a great product.
Fun &
Celebrating
Success		 Boooooooring. We do not celebrate successes. There are some smiles about, but celebrating success isn’t something we really do as a team. We have great fun working together. We find ways to celebrate our success.

Teaching fun: the great pancake cookup

Leave a reply

Chocolate-Chip-Pancakes

I recently attended a workshop on developing effective teams. The university I work for is in the earlyish stage of Agile maturity. I’m not. That’s why they’ve hired me. To introduce Agile and transform their digital team.

The workshop facilitator asked us to think about the most successful team experience we’ve had across our career and what made a successful team. The answers to this question came hard and fast – a great leader, enough resources, clarity of roles. I shouted out my answer along with the other participants – FUN! Silence descended on the room. All other participants looked at me. The facilitator responded, “no one has ever used that word to describe why a team was successful.

I discovered in that instant that in this organisation, needed to learn that work could also be fun.

I quickly devised a way for us to combine both an activity to embed a better understanding of story articulation, with teaching the team to have a bit of fun. This project, which in the planning phase I ran with the utmost seriousness, was labelled The Great Pancake Cookup.

The team was invited to an express project inception where we fleshed out our elevator pitch:

For the Digital Team
Who need to have fun through an inclusive team activity
The Great Pancake Cookup is a lunchtime event
That will allow us to enjoy a delicious meal we prepare ourselves, actualise how well we collaborate AND make all other staff insanely jealous as the delicious smell permeates the office.
Unlike other teams, our lunchtime event will not consist of soggy veal parmas or limp burgers, but express our inner Masterchef through both creative savoury and sweet pancakes.

The scene was set. We got right down to discussing our trade off sliders.

Time: We decided on one hour from prep to consumption – preferring to slightly supress our inner Masterchef in favour of having enough time to enjoy our meal.

Budget: We agreed to each kick in about the equivalent of what we’d normally spend on eating out for lunch.

Quality: This wasn’t something we were prepared to compromise on, as we had clarity on our customer base’s expectations – nothing less than scrumptious. We did agree to compromise on presentation though, given our time constraints.

Scope: As Product Owner, I really needed to temper scope creep. Yes – a choice of 10 savoury and 10 sweet toppings was attractive – for the breakfast buffet at the Hyatt Hotel, but could the consumers still feel delighted with perhaps 4 or each? I surveyed them and they thought there would still be good uptake.

The day of the event arrived. As Product Owner, I was busy approving stories so they could be moved into the done column:

As the Digital team, we want to have all the correct equipment available for cooking pancakes, so that we can successfully prepare our meal.

Acceptance criteria:

  • mixing bowl
  • power whisk
  • three electric frying pans
  • two broad blade spatulas (a link to an image of a spatula had been thoughtfully inserted into this acceptance criteria)
  • power board

As the Digital team, we want to have all the correct ingredients available for preparing and cooking pancake batter, so that we can successfully prepare our pancakes.

Acceptance criteria:

  • Self-raising flour
  • Back yard chook eggs
  • Lactose free milk
  • Oil for frying

The Devs were standing by about to plug in the three electric frying pans and ramp them up to 200 degrees. “Wait”, I yelled, “we may have forgotten to articulate one particular story:

As the Digital team, we want to ensure the electrical items we are using are tagged, so that we can comply with the university’s safety standards and so that we do not create an electrical failure, or worse, in the staff kitchen.

A quick consultation and we agreed that the risk of shorting the staff kitchen and leaving everyone else without the use of a microwave was outweighed by the benefit of pancakes. We compromised on using two frying pans.

The event was a huge success, on many fronts.

A team fairly new to Scrum, learnt the rudiments of project inception and story articulation

The team moved from what would be called in the early childhood education arena “parallel play” to “group play”.

We had fun!

We showed those around use that work can be fun.

Most importantly – The pancakes were super good.

What next?

We decided that soggy parmas and limp burgers are sometimes nice, particularly on a Friday when you can get a $10 deal at the local pub.

We also decided that when we do team lunches, we’ll take it in turns to bring in a bunch of moderately healthy stuff we can assemble ourselves. The foodies in the group bring home grown heritage tomatoes, sometimes it’s burritos or bagels and dips.

But it’s the “assemble it ourselves” part that’s important. The interaction of chopping veggies together, chatting while we wait in the queue at the microwave and sitting down to enjoy what we’ve prepared.

 

 

 

 

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

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

Can Agile help you tie knots?

Leave a reply

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.