I realized something about Agile today: It forces you to redefine your job description. In particular, it gives everyone on the team the same one: Ship valuable software to the customer. The ways we help with that are different because of the different roles we’re in and the different skills we bring to the table. My job, though, is not to coach the team. My job is to ship valuable software to our customers, which I do by helping the team improve. If we’re not shipping, I can’t say that it’s not my problem because it’s not my job.
Entries in lean & agile (23)
My friend Judd has a phrase for days like today: Working the heavy bag.1
At work, I’m going through what is effectively my fourth Scrum team startup. I say “effectively” because while there is some continuity among those teams, there have been new people and technical changes. There have been enough of these that they’ve basically triggered a re-forming of the team each time. And each time we get a little better at it. This latest one is tricky though, because we’re running into some deeper cultural divides than we have in past, due to the differing backgrounds and organizations the team members come from. There are real problems here that we have to work through. I’m thankful to the team for pointing them out and keeping us from sweeping them them under the rug, as has happened so often in the past. This isn’t an exhibition match. What we’ve got here is a twelve-round title fight.
It is frustrating at times. My manager and I both got a bit punchy this afternoon due to the mental energy we’d expended trying to corral some of these issues. At points over the last few weeks, I’ve wished these problems would just go away. They’ve seemed to be too big, too difficult, too entrenched for me to handle. At times I feel like I’m just waiting for the bell so I can drop my gloves.
I’ve come to realize two things recently that help me to deal with this. First, I don’t have to have all the answers, and I don’t have to solve these problems alone. Yes, I’m the Scrum Master. I’m the keeper of process. I’m responsible for making sure we do Scrum and that we do it well. I’m also not the team, and these are team issues. It’s my job to put on my coaching hat and take these problems to the team. They need to own the solutions; I need to help them get there.2 It’s only partly my fight, and what the team really needs now is a good cornerman.
Second, this is what I signed up for, whether I realized it or not. The important thing is to dig in, pay attention, and fix things instead of wishing they were better. This is the work I’ve been wanting to do for years. If my arms are tired from punching, it’s because I haven’t been doing the right exercises. Now is the time to develop some new muscles.
1 Judd likes to work out, so many of his metaphors come from the gym.
2 And I should be getting help myself from my Product Owner and the rest of the management of the organization.
Rather than ramble on further about my skiing weekend, here's something that I wrote a month or two back but never got around to posting. Warning: Software geekery ahead.
For a while now I've been telling our team at work that in order to do Scrum well, we need to raise our technical game.1 There are certain process demands that Scrum makes on that we can't respond to without improving our technical practices. We've been pretty aware that slicing User Stories is something we need to get better at2, but recently I've started to think a lot more Test-Driven Development.
Last week was the perfect storm of influences pushing me to do it. I'd done Alistair Cockburn's Elephant Carpaccio exercise at Agile 2010, and I was curious to see other people on the team take a shot at it. On Wednesday, we ended up using it as an audition piece in a technical interview, pairing up me with the candidate to pair-program it. Matt and Kevin were intrigued enough by it that they tried it themselves on Friday, with me facilitating. In our debrief afterward, we talked quite a bit about Pair Programming3 but we also touched on testing during development. I later gave the exercise a try on my own, trying TDD it using C#'s System.Diagnostics.Debug.Assert() to write test cases.4 It went okay, but it seemed like there was a lot of overhead.
Fast-forward to Saturday morning, when I'm catching up on posts to the XP mailing list. I noticed a post where someone was asking for pointers to good TDD resources, and someone replied with a link to James Shore's Let's Play TDD screencasts. In fifteen minutes, I was hooked.5
As it just so happens, I've been needing to write a little bit of code. For the RPG design I'm kicking around I needed to look at some slightly complicated dice odds in order to make some decisions. In the past, I've coded up a quick Monte Carlo dice roller6 to simulate probabilities. This time, I downloaded Visual C# 2010 Express and NUnit so I could try out these things I'd been seeing.
Thus far, it's great. It's really pulling together a lot things I've been reading about recently: good development tools support, tight feedback loops, expressive names, small methods, seams for separating and sensing, the Single Responsibility Principle, etc. I've been seeing how these could potentially apply to projects at work, but actually getting my fingers working on them is completely different experiences. There are some intriguing flow state things happening here that I can't quite articulate yet.7 But the big takeaway is that no matter how much I'm going to be dealing with the people and process side of this software project at work, I need to up my technical game as well.
Addendum: We ended up hiring the interview candidate in question, and she now reports to me. During our one-on-one on Friday, she expressed an interest in learning more about TDD. We agreed to work through Let's Play TDD videos and practice together.
1 I've become particularly aware of this because of things like Martin Fowler's article on Flaccid Scrum.
3 Which really deserves its own post.
4 I believe this marks the third time I've used C#.
5 And insanely jealous of the JUnit integration in Eclipse, especially combined with the automated code generation and refactoring tools. Now I feel like I'm living in the dark ages with Visual C++ 2005.
6 Usually in python.
7 In particular, it's great for working on a project for thirty minutes (or one Pomodoro) at a time, which is about what I can carve out of my schedule.
This week at work has been crazy busy. Fortunately, what it's been full of has been work I've been wanting to do for a while. The problem with continuous motion is that it's hard to see how far you've come.
As I've been transitioning from technical work to coaching, I've been worried about not contributing enough to the team. One of the practices from Coaching Agile Teams that I've been telling myself that I need to do is the weekly value check:
Each week, sit down and write out a list of the value you delivered - just a little list of the things you helped emerge, the successes that people enjoyed because of your work, and the places you outright rocked! Let this be a personal journal. Assume no one else will ever read it so that you can give yourself the permission to be unbridled in what you right there.
So I did. Earlier in the week, I had scheduled half an hour on Friday afternoon (when I'm often winding things down anyway) to do this. When I started, I though I had nothing to say. What had I accomplished this week. When I was done, I couldn't believe how many things were on the list. I wasn't embellishing; it was honest assessment of how I had added value to the project. Many of them were cases where people told me how what I had done had helped them. Now I feel great, instead of overwhelmed, and all it took was a few minutes of reflection and writing.
I think I'll go skiing.
Today I submitted a session proposal for Agile 2011.
The Agile Conference was one of the key moments for me in 2010. It brought me into personal contact with the Agile community, it made me tremendously more effective at my job, and it opened my eyes to a host of new possibilities. Before the conference, I had naively said that my goal for 2010 was to be a presenter in 2011. Afterward, I told myself that there was so much I needed to learn that that wasn't realistic.
But back at the beginning of December, I attended a one-day conference in San Francisco sponsored by the Bay Area chapter of the Applied Improvisation Network. I had discovered the group entirely by chance, and my experiences there changed my sense of what I knew and what I could potentially bring to Agile 2011. When I started to approach Agile from an improv perspective1, I realized I had something to say. So over the last few weeks I've let ideas stew, jotting down ideas as they've come to me, allowing message and structure emerge slowly from my subconscious. Yesterday I put together a draft proposal, and today I submitted it.2
In a strange way, my years of running RPGs at conventions helped prepare me for this. Convention game descriptions were always due well in advance of the event, and I never had my scenarios completely prepared by the due date. I eventually realized that I didn't need to have the entire adventure worked out, just enough to know what the general shape of it was going to be. It's the same thing here: I know enough that if I had to run the session tomorrow, I could, but I also know where things could use some work.3
I have no idea what my chances of having the proposal accepted are, but the process of putting it together has been rewarding enough.
1 Rather than from an embedded systems or an experience report perspective, which is what I had been thinking about in the aftermath of the 2010 conference.
2 The two-stage accept-reject-or-revise submission process with open comments is a fantastic idea.
3 And if the session is accepted, where I'll be spending my time between now and August.