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 Makes a Successful Agile Coach?
People often ask me “how does Agile tell you to do <this and that>” and having recently presented the fundamentals of Agile to a large mix of people, the textbook answer is “well, it depends”. Folks who have little to no experience with Agile seem to be much more accepting of the fact that “being Agile” is all about taking the tools, knowledge and frameworks and applying them to your situation. Some though Agile was a software tool, chaotic and very confusing. They are actually very relieved to see the benefits that adopting Agile methods bring. I stress that it’s more about becoming a learning organization and that Agile adoption is about culture first and foremost.
Experiment. Fail. Learn, move on and get better next time around. That is what “being Agile” is all about.
There is no magic formula or checklist to make an Agile adoption successful. It’s up to how willing the individuals are to accept help from a coach or how open they are to getting out of their comfort zone to improve on something that isn’t working. Class after class I get bombarded with questions that range from how QA integrates with an Agile team to “how does Agile tell you to deal with the expense of buying a developer a laptop?”. (yes, that was a REAL question I was asked once).
Esther Derby posted a few months ago about 5 reasons to hire an Agile Coach which leads me to ask what actually makes a coach successful? What makes a coach worthy of self-labeling himself a coach in the first place? These are the top 3 attributes I consider to be the most important:
1) Self-less: A coach must care about the team (and organization) and morally and ethically do what is right. A good coach must possess the desire to work their way out of a job for the greater good of the organization that has invested time, money and most importantly trust in the coach’s abilities. Now in the real world I am quite sure there are some folks who want to extend the gig as long as possible for security or other selfish reasons, but IMO that’s not the point. If you are trying to teach and organization how to build trust, that lesson starts with the coach.
2) Honesty: A good coach must be clear that the road may (and mostly likely will) get rough and there is a chance adopting Agile just will not work if the organization doesn’t want to change. You can say “honesty is the best policy” is a rally-cry or fluffy sounding but it rings true. If you set the expectation that you will be honest regardless of how painful that honesty may be sometimes, a coach will stand to earn the respect and trust of the organization which is a first step towards having that spread throughout the rest of the organization.
3) Guide, Not Dictate: Ok, so this isn’t so much an attribute phrased like the other two, but it’s important nonetheless. As I mentioned at the start of the post, lotsa folks want the “how” without wanting to think about it first. It’s important a coach help the organization/team/person get to the right answer for their situation. An organization needs to learn how to becoming a learning organization and the best way to accomplish that, IMO, is to use the tools, knowledge and frameworks to help people find the answer that works. If teams or individuals are making real attempts and showing true desire to adopt Agile practices, give them the freedom to apply what you have taught them. Let them experiment and maybe they’ll fail, but if they have the desire and motivation, they will learn and improve.
I’ve always bought into the thought that skill and knowledge is never a problem. Skills can be taught and knowledge can be obtained. Motivation and desire are the most important attributes that help organizations or individuals commit to constant improvement.
Agree? Disagree? What other attributes do you think make a coach successful?
