Tag Archives: Iteration

In Agile hills are epic


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

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!