In my initial post discussing the adoption of agile practices in my engineering group, I gave some background on where we were a few months back and how we started to switch from waterfall to agile.
In this post I'm going to get into some details about the practices we have tried and how they have helped us (or not). Before I get into the meat of that though, one of my colleagues, Ram, commented on that first post. He had a very interesting point which gave me pause for thought. Amongst other things Ram said, "did the points estimating really helped us??i personally could not see the benefits out of it."
Chewing this over for a few days has led me to realize there's a couple of important things anyone reading this needs to know. Firstly, what I write here are my observations, and I'm not a member of any of our scrums teams such as (for example) Ram is. For those that don't work with or otherwise know me, these postings are the observation of a manager of a team of engineers. My concerns and observations will, necessarily, be different from those actually on a scrum team doing the hard work. Secondly, I may need to make clearer why I see some things as beneficial -- perhaps they would be obvious to peers, other managers etc. but I would like to share these views also with people on actual scrum teams. I think having a more holistic view of the whys, wherefores and benefits for more than just the team would be useful and (hopefully!) interesting. I know that two of the guys on our scrum teams have their own blogs and hopefully they will post their thoughts on our agile adoption over time. You can find Ram's here, and Rajiv's here. Rajiv already has posted some preliminary thoughts.
Now on to the real substance of this post. I'm going to cover what I remember as the next four items of consequence in our agile exploration: task visibility, proper iteration kick-off meetings, iteration retrospectives and lastly Twitter. Yes really, Twitter.
Truth be told, having a decently detailed understanding at any given moment of what people were working and whether it was going according to plan was historically difficult for me. In part I attributed this to not playing the role of project manager for any of our ongoing endeavors...so of course I didn't know. But finding out when I needed to know was always a tedious process. It felt like it took more time than it should and never left me with much confidence that I had the full story anyway.
Our agile adoption almost immediately started to help with this. We employed two key tools: a simple task board and Basecamp, an online project collaboration and task management tool. The task board was set up in a small room we were able to use on a daily basis for our stand up meetings and was shared amongst the entire team. It took us a while to tease out "good" tasks and longer still to realize that the RA should have tasks on there too. At this stage we weren't really story based, and so the granularity of what was on the board was fairly variable. Nonetheless, being able to see at a glance how many tasks there were for an iteration, how many remained in committed vs. in progress vs. done was very powerful.
This physical task board was augmented by Basecamp. This was mostly popular with the software engineers on the team, and we wrestled for a bit over what should "drive" the stand ups ...the physical task board or Basecamp. Our situation was complicated by the fact that we had team members in both Eastern Europe and India. This led some of us to feel that Basecamp was the way to go, but, ultimately the physical board won out. I think upon reflection this was a good thing -- the simplicity and visibility of the board was key. The software engineers continued to use Basecamp to a greater or lesser extent for most of the remainder of this release cycle.
Proper Iteration Kick-offs
Even before our first tentative steps in the agile direction, we had typically divided our product development work into two week "iterations." This didn't actually afford us that much of a benefit besides perhaps enforcing a certain regular cycle when the PM would check in with the developers and obtain some vague indication of what they might do in the next couple of weeks.
Now the kick-off meetings had much more purpose: what are we putting into the "committed" column of our task board? If we estimate that stuff in points is it <= our velocity? From my perspective this seemed to give us a much more regulated rhythm to our work. Things seemed more predictable -- the team met their commitments. They thought harder and talked more about what they were committing to. Their was greater consensus across the team even though work on different facets of the project was still silo-ed in some ways.
Having seen how this panned out I would maintain that there's really no point doing work in iterations unless you are also measuring velocity in some way. There's just no point -- if you're not measuring velocity all you're doing is arbitrarily punctuating work with some meaningless and frequent end point for no benefit. When you do iterations with velocity however, you start to gather data about the capacity of the team. From this the team can become better at predicting what they can accomplish. There's a straightforward but worthwhile sense of accomplishment knowing you can approximate what can get done in a couple of weeks.
For me retrospectives, and what they imply if done well, are the key to agile success. If (for some odd reason) I could introduce a fledgling agile team to just one new idea it would be retrospectives. I've never been a big fan of meetings, but with a retrospective you can get so much:
- sense of team cohesion ("We're all in this together...something sucks? What would you like to do about it?")
- shared ownership of process (so many people are used to being "told" what the process is...and now there is a chance for them to shape it)
- an opportunity to challenge existing dogmas ("our SOPs won't let us do that")
- a forum for people to shine with insights and ideas that often don't get an audience
- a plan of improvement and a place to measure that improvement
What I also learned was that retrospectives need a great facilitator. It's all too easy for someone to go around the room and ask what went well and what didn't and get fairly anemic responses: "I guess what went well was we got all our committed work done...can't really think of much that didn't work out so good..." Getting people to surface the less rosy side of things is hard. There are of course those who always have views on this kind of thing (I'm kinda one of those myself) but for others it's awkward. Until people find that volunteering this kind of information is not just acceptable but welcomed some skill is required in extracting it. One way of doing this is through just lots of dialog. In a one on one situation people are often more willing to offer up something that's driving them nuts. I often would then try and find a way to toss this out for discussion without specifically identifying the source.
I may stand alone on believing Twitter was a valuable resource that contributed to our agile adoption. Certainly I do not believe I managed to convince any of my peers of my boss to sign up (or if I did they're obviously using a pseudonym and cyber-stalking me). And this despite the copious links to informative blog posts etc. I sent them. Hmm, perhaps I did sent a few too many...
Anyway, personally I found Twitter to be a fabulous new tool for finding reading information relevant to agile. I developed a twice-a-day ritual of scanning my twitter stream and flagging interesting looking links for later reading. I started out with just a few people to follow, but through the way twitter works I was soon discovering others, from internationally known thought leaders through to ordinary people like myself writing about their experiences. With the recently added "lists" feature of twitter I have create an agile list which may be of interest to anyone wanting a starting point.
OK I think that's enough for a post. In the next installment I'll talk about some of the subsequent events including how we started to talk more about a specific agile methodology (Scrum) rather than a general notion of "agile" and some of the technical practices we started to put some focus on.