Tag Archives: agile

A Week in the Life of a Agile Coach – Monday Morning

I thought it would be interesting to share a day-by-day rundown of what a typical week looks like for me.  The names have been changed to protect the innocent (or guilty!) but the events and activities are literally what I do week to week.

A new article will be posted each day this week and I’ve tried to keep them as short as possible.

Week 1 – Monday Morning

8.45-ish – Monday’s always start off with meetings so I make it to our head office downtown and head up to see how the guys from the previous team I was working with are doing.   It’s iteration planning day for them and Joe, their scrum master, asks a few questions about  how he can help them figure out how to task their user stories.  The team is having a hard  time switching from the old way of being told what to do so it’s not coming naturally to them.  They’re finding they have quite a bit of un-finished work at the end of the iteration so we sit down and look at a few of the stories to be presented and I offer some suggestions for tasks they could create and remind him that they should limit work-in-progress so they can finish a story before moving onto the next one.

We talk about possibilities for tasks based on the stories that will be presented with the key message to Joe that he shouldn’t be the one to hand these tasks out.   I remind that the team will figure this out, they may need to some poking from him so at least now he has some ideas he can guide the team to.  Joe heads off to his planning session so I stick around and chat to a couple of other folks before heading out to my first meeting.

10:30am – I’m filling in as a Scrum Master for another team and next up is a meeting with the Product Owner and some other folks on our Product Definition Team.  Our next iteration is starting in a couple of days and the Product Definition Team’s goal is to make sure the stories are ready for the team to pull in.

We draw up some sample wireframes on the whiteboard with the help of the usability person we pull in when needed, take some photos with my camera phone and upload them to the stories in the tool we’re using.  They’re crude but good enough for the team to work with.

Now that we have almost 2 iterations of work ready, according to the team’s velocity, we grab some lunch and informally chat about some cool ideas for future iterations or suggestions the team had last week.  When necessary I scribble some notes on cards for reference later on.

1:30pm – After lunch I meet-up with the other coach (who’s also my boss and mentor) and talk about the Estimating and Planning class we’re preparing for new teams that will be starting up soon. We plough through the slides pretty quickly and get on the same page about balancing the theory with fun exercises.  After that we talk about challenges we’re both having, brainstorm some ideas and co-ordinate what we’re going to work on for the week.

3:30pm – I head back up to our other office where I’m based to see how the team is doing.  This happens to be our first true pilot team working in their 6th iteration and so far so good.  The team really gets it and have already implemented some automated testing, a new build process using Bamboo and have really impressed the business with how much great quality work they’ve been able to do.  I log in to our tool, check the burndown and talk to a couple of the guys and see if there’s anything blocking them that I need to help out with.

Unfortunately the team isn’t co-located yet but we all sit pretty close to each other.It’s great to see how motivated they are working this way which makes it possible for me to spread myself around and not be 100% dedicated as their Scrum Master.  Not ideal, but doable in this situation and the team is providing much more value than “the old way”.  There is still work to do but the motivation is there and some of the “test first??  automate your tests?? the hell you say!” comments are changing to “oh, you know what, if we had some automated tests that xyz thing would have been a lot easier to take out

4:30pm – As the day is winding down I check our general Agile Support mailbox, respond to a few questions and then send out some invites for an Agile training session I’m delivering on Thursday.  To close off the day I check our internal blog to see if anyone has commented on the last post about Retrospectives I added last week.  One of the PM’s in another group wants to find out what real internal teams have done to improve so I send him the link to our wiki where we post our iteration information and retrospective notes so everyone can see them.

A quick check on tomorrow’s calendar reveals that it’s iteration review day so I’ve got a prep meeting, iteration review and retrospective for the afternoon so I figure it’s time to head out and rest up for the busy day tomorrow.

What it means to be Agile

I remember when I first started learning about Agile, and Scrum in particular, it seemed that everyone had a different interpretation of what it was.  Some folks consider it religion, some folks find Agile is an excuse to not plan or they simply don’t know how to plan so ‘being Agile’ seems like an easy way out.

Baptism by fire and blogs filled with wrong information wasn’t going anyway quick so I figured it was time for some training.  After I finished my CSM, it was pretty clear that Scrum is easy, but implementing Scrum is really hard.

There are some great articles out there about Agile but Travis Birch from Berteig Consulting posted an excellent article on what it means to be Agile. Some people think the ‘art of possible’ and other Scrum mantra can sound a bit hokey at times, but it really is a big shift in mindset to use Agile/Scrum effectively and Travis’ post is one of the best written posts I’ve read that summarizes what Agile is.