Wednesday, April 20, 2011

Scrum and Telecommuting -- our experiment

Back in December last year I wrote about a pending experiment at work. Half of our scrum team already worked from home, and we wanted to see if things worked better or worse for us if the other half all worked from home too.

After convincing our management to let us try this we targeted starting this in the first quarter of 2011. We planned to try this one sprint at a time, considering at each retrospective if it was worth continuing and what changes we might need to make to make the next sprint better.

As things transpired, we found ourselves keeping this going for the entire first quarter of 2011, and we’re continuing to do it still. As might have deduced, we though it worked our pretty good for us.

At the end of the quarter, I conducted a couple of surveys; one for the team members and one for people outside the team that we interact with. In this post I’m going to share a few of the insights from our experiment and what the surveys revealed.

How was it for the team?
Let’s start with a quick recap of the team composition. There are four people already working from home around the Denver, CO area – three software engineers plus me as scrum master. Then we have three people in Billerica, MA – our product owner and two testers. Finally we had (yes had, but have no more – they moved onto another team during the quarter) two further testers in Hyderabad, India.

There were a couple areas I polled the team on that I felt would help capture a picture of how things worked. The first was how our meetings ran now we were all working from home. Here’s a chart of the responses:

As you can see, we mostly felt that the meetings were no worse off than when half the team was office based, and in fact a few people felt they ran better. That they would run better was certainly our hypothesis going into this, based on the idea that communication would suddenly be equitable for everyone. That is to say we would now all be on a phone and there’d be no more side conversations, people failing to talk “to” the phone etc.

The one interesting point that shows up in the chart and is fairly intuitive too is that the sprint review meeting wasn’t universally considered better in a fully decentralized set up. I was actually surprised more people didn’t feel it was suboptimal, and certainly if you skip ahead to the chart where we asked people outside the team how they found things you’ll notice a few people indicated that they didn’t feel meetings were always better. I don’t know for sure, but I suspect the review more than anything might have been the meeting that triggered that feeling as the others seemed to work well.

The second major question I asked was about getting things done. Here’s the chart for that:

You can see here a lot of what you might predict:
  • it really wasn’t that much of a problem getting a hold of people and working with them (huzzah for IM and the telephone)
  • the ability to focus and get work done was better
  • dealing with hardware and software issues was a little trickier for a couple people
I think there are two important messages. Firstly, those who think you need to be in the office to get work done forget about how much the distractions and interruptions of cube-ville can be detrimental to work. Secondly, you need to be of the “self-serve” type and/or have a good helpdesk that can work with home based users to get through those times when you need help with hardware and software issues.

In addition to structured questions people could provide freeform comments. Here’s a sample of what people on the team had to say:
"Very good experiment, worth continuing, I can always come to office as needed." 
"Meetings are more efficient: less side conversations and greater team participation." 
"Work life balance was much better in this case."
The final question I asked of the team was whether they would like to carry on with this. Not surprisingly the answer was mostly yes. Those already working from home felt probably felt less excited about it all – they don’t have a choice, they’re working from home whether they like it or not.

How was it for everybody else?
Moving on to the survey of people outside out team, the one of the first questions I asked was about the respondents own inclination for working from home. Here’s the responses in chart form:

We’re not dealing with a huge number of respondents here, but still you can see that the majority of people would be interested in some kind of arrangement involving working from home, even if it wasn’t all the time.

Of course the main purpose of surveying folks we work with outside our team was find out if things worked well from their perspective. After all, it’d be no good if our team was thrilled with this but everyone else we interacted with thought it royally sucked.

Here’s a chart showing how others found things:

You can’t please all of the people of the time. As you can see, for three out of the four questions we had a few folks that felt things weren’t an improvement. But as evidenced by the tall yellow bars, for most people it was just fine. This doesn’t totally surprise me…if you look at the communication behavior in an office, people don’t have to be very far away from each other before they resort to IM or email. Put another way, although it can be useful to be able to go and talk to someone face to face, often that is not what people do even when they are in the same office.

The Problem
Yesterday I read an article from Fortune magazine about a survey conducted by technology career site

What the Dice survey clearly showed is that there is a lot of talent in the technology field that would happily work from home. From our small sample above this seems to be borne out for my organization too. However, Dice notes that fewer than 1% of the jobs offered on their site offer telecommuting as an option to candidates.

The article went on to point out that, given the competitive marketplace for talent, one way employers could stand out would be to consider offering people the option to telecommute. The problem I think is that so many managers are scared of this option, seeming to believe that people need to be kept in an office so they can be checked up on, managed and so forth.

Consider, for example the follow feedback I got from the second survey:
“This survey is not fair, because I don't have a baseline for how well the team performs working "centralized" versus "non-centralized". I will say, I am not happy with the level of visibility I have into how much actual work is being done. From my perspective.. You could all be at the beach all day... with one person working feverishly the day before something is due.. or you could all be working hard.. but in different directions... My gut is that I would like to see more throughput from the team regarding what is actually released.. but from my vantage it is very difficult to say if working remotely helps or hurts.”
Of course one could argue against this (I leave that as a trivially simple exercise for the enlightened reader) but the fact remains: many people still think this way. Convincing those that do that managing by outcomes rather than direct observation and the occasional beating pep talk is not only possible but preferable, may just be too hard.

This attitude may also help explain one question which I found the responses to puzzling. Consider the below, which shows the answers given to the question, "Should our team continue working from home?"

I was surprised by how many people answered "If they feel they must." That seems at odds with the number of people that expressed an interest in working from home themselves, but perhaps, subconsciously, people still worry about the true feasibility of it.

What I can tell you, as someone who's worked from home for over three years, and now have done so with a complete team all at home, is that it can work quite OK. Is it as good as all being in an office together? Probably not. But then many teams don't have the option of all being in the same office anyway. And there's a number of potential benefits to having a team distributed like this: attracting the right talent, providing people an appealing and innovative benefit, a good work/life balance and reduced facilities costs to name just a few.

Sunday, April 17, 2011

Excuse me, I'd like to...ask you a few questions

I once worked with somebody who had the following pinned up on their wall for easy reference during the many teleconferences in which they participated:
Use questions for clarity:
  • What?
  • Why?
  • How?
  • When?
  • Where?
  • Who?
  • Which?
Not a bad idea that, a little prompt to make sure you really understand a topic. I don’t have a reminder up on my wall but I always like to try and run through these when appropriate. (Well, and when I remember.)

I was thinking about these in the context of agile software development, and how they can help various roles and guide activities. Let’s look at each of them in turn. I’m going to approach this from the perspective of a team following scrum, but I think the general principles apply to all approaches to software development.

Is everyone office based? In the same office or spread across more than one? Where is the customer? And other stakeholders? Some arrangements are better than others. The answer to the WHERE question is definitely important, but usually something few agile software development projects can influence very much. Most folks would agree that the ideal set up is collocation with an onsite customer. If you can get that…awesome. If not, recognize the shortcomings and know how to mitigate the problems they might present as best you can.

The WHO question can apply to a number of things. Who is on the development team? Who is the customer? Who are the users? And so forth. From the scrum perspective it’s really important to have identified who the product owner is. The product owner is such a key role for successful scrum because of their product visioning and feature prioritization work.

I struggled initially with WHICH. It has less obvious utility than the other questions. I think primarily though it can be thought of as your prompt to consider prioritization. Prioritization is absolutely key in scrum. Which projects should we fund? Which themes do we want to target for this release cycle? Which features are of highest value? Which features are risky or are we unsure how to do?

Everyone involved in a software development effort should be clear on WHAT they’re building. Initially WHAT is primarily the province of the product owner. They start a release cycle by consolidating input from the customer, other stakeholders, the team, their own ideas and provide a statement of what the product needs to do.

The WHY is important, possibly the most important question of all to my mind for a couple of reasons.

Firstly it lets you check that a feature is really needed and worthy of a place in your product backlog. With something akin to the five why’s technique you should be able to explain the necessity for every feature in terms of one of the following business values:
  • Protect revenue
  • Increase revenue
  • Manage (reduce?) cost
  • Increase brand value
  • Make the product remarkable
  • Provide more value to your customers
Product owners should be very clear on why anything in the backlog is needed. If you as product owner find you can’t tie a feature to one of the values above then you might want to ask yourself if you’re sure it’s needed.

Secondly, once the whole team understands the WHY of a feature we can harness everybody’s input for some creative thinking. Sometimes people think they need a feature because they assume certain things can’t be changed, or they don’t realize there are other ways to approach a problem they are trying to solve. Perhaps an existing feature can be adapted to meet their needs.

The question of HOW is almost as important as WHAT and WHY. Those three together form a kind of virtuous trio.

HOW is a question that cannot be answered by any one single role on a scrum team. Everyone has a contribution to this question. As the saying goes, there’s more than one way to skin a cat. And with software that definitely applies. Figuring out the possibilities and weighing up the pros and cons and trade-offs involved will help lead to the best possible features implemented in the best possible ways.

Beware product owners that dream up the HOW as well as the WHAT and the WHY. Unless they’re from a development background it’s likely that not all of their HOWs are feasible or optimal.

Often the WHEN question is the one most businesses, customers and stakeholders obsess over. To some extent I think this is almost impossible to escape, although it is possible to put more emphasis on WHAT by stabilizing the WHEN with a fixed duration release cycle.

Once the team understands WHAT, WHY and HOW they can estimate the effort involved. If the team has a stable velocity this then allows the product owner to be quite predictive in answering WHEN and they can move features up and down the stack ranked backlog to accommodate the needs of the business as best as possible.

All righty then
Having reviewed all these question-words there are two key insights for me.
  • Certain roles on a scrum team are better positioned than others to answer certain questions (POs have a natural affinity with WHAT and WHY; developers with HOW)
  • Nobody on a scrum team has the exclusive preserve of any particular question: by working collaboratively and with everyone empowered to ask and answer any of these questions the talents of everyone can be harnessed to make better software.

Wednesday, April 13, 2011

What I got out of Mile High Agile 2011

This is a slightly longer than usual, rambling somewhat whimsical post. Sorry about that. There is some good stuff toward the end though. Well I think so anyway.

Last Thursday I attended the inaugural Mile High Agile conference put on by Agile Denver. The day commenced at an unnaturally early hour with me hurtling down the mountain to Golden and then doing battle with I-70 and I-25. Perhaps due to the early travel time the traffic was lighter than the nightmare I had envisaged and well worth it compared to my regular commute (from bedroom to basement via kitchen) for what I got out of the day.

What follows are my thoughts on what I got out of the conference, not all of them directly related to agile.

Earlier in the year when I first heard about Mile High Agile I volunteered to help with a couple of items – setting up the website along with another volunteer and the corresponding registration and payment system. It’d been a while since I’d done any kind of web content creation but we elected to make things really simple by just using WordPress with a suitable theme. Although this obviously meant there were quite a number of restrictions (especially since we weren’t hosting the WordPress blog ourselves) it did mean we could get going easily and quickly. Given the chance to do it again I’d almost certainly stick with WordPress considering the simplicity of our needs, but hosting it ourselves would be well worthwhile. That would likely let us get around the problems we faced by using plug-ins which you cannot do when hosting at

For the registration and payment side of things we used EventBrite. This was a service I hadn’t used before (at least not in the role of a conference organizer) and I have to say it’s a pretty impressive offering. While our needs were simple (a handful of ticket types, a few dozen discount codes, simple reporting and so on) EventBrite just seemed to work without effort. Everything we ever wanted to do (bar one thing) seemed to have already been anticipated and worked well. In addition, I had occasion to use their support services twice which are very good and incredibly quick to respond.

In the couple months leading up to the conference last week I really enjoyed working with the folks that brought this together. My contribution was pretty small compared to others, but it was fun to be part of it and work with people really intent (passionate is so overused, no?) on making this happen. It was a real joy to see folks pitching in no matter their role offering useful ideas and commentary as things unfolded. I wish I could work with more people like that more often.

At the beginning it was unclear how many sponsors we would secure or how many tickets we could hope to sell. Due to a truly outstanding effort on the part of several people we exceeded all expectations. Just check the number of sponsor logos up on the site and note that we sold nearly 500 tickets. Not bad for such an incredibly tight timeframe and the first ever Mile High Agile conference! If you build it they will come. So long as you get the word out and market it hard too.

There were a few things that struck after the day of the conference which were nothing to do with agile but interesting insights to me. I’ve been working from home for quite some time. Although I thought I had quite a rich interaction with people on my team via phone, email and IM etc. it was nice to suddenly be in the fray of lots of tech people and talking with them. I was part of the gang that stood behind the registration desk which was insanely busy for an hour or so as the best part of 500 people arrived to check in. It reminded me of a part-time job I had way back in time as a teenager, working in a home computer store on Saturdays which were always insanely busy. I loved it. Definitely makes me hanker for more local, in-person interaction.

Another thing that was weird was that driving into Denver didn’t seem too bad. I’ve always found it less than desirable in the past, but after a series of trips into the city over the last year perhaps I’ve finally got a decent sense of how its all connected up in my head and feel more at ease with it. For some reason I’m feeling the urge to visit Denver more and more.

The final odd little insight was how nice it was to be surrounded by people who were enthusiastic about various facets of agile software development. Although you might have different views and experiences from others on details, there was this common thread of “getting it” (“it” being agile) and wanting to “get it more.” Perhaps meeting people whose viewpoint reinforces many of your own beliefs is nothing but an ego stroke, but it made me think how cool it would be to work with more people like that.

Turning to the sessions I was able to attend three, all of which were in the technical track. I really enjoyed them. I wish there was more – it’d be great if next year were a multi-day conference :-) It also made me think it would have been nice to present. I’m not entirely certain what on, but I feel like I’ve learned a lot over the last couple of years and it’d be fun to share some of that beyond just writing about it on my blog. Maybe next year.

The first session I attended was Agile the Pivotal Way given by Mike Gehard of Pivotal Labs. I confess I hadn’t really realized that Pivotal Labs did anything other than make Pivotal Tracker. Turns out that really their business is building software for people, often startups, and they seem to really approach work in a way that makes a lot of sense to me.

Mike mentioned that they pair program everything. This reminded me how much I miss pair programming. I’ve had two serious periods of pairing in the past and I’m pretty sure it’s the best approach for a lot of software development work. The first time we didn’t call it pair programming because it was just my 12 year old self and my friend hacking away on a Commodore Vic 20 writing games in BASIC, PEEKing and POKEing the screen to make games that rivaled Pac Man. Almost. But it was great. The other time was much more recent. It’s how I learned Java courtesy of a colleague pairing extensively with me. It’s also how the first release of one third of our product suite got built incredibly quickly, by just me and that other guy. If I’m going to be programming in the future I hope it’s pair programming.

Mike also mentioned how their “teams” were small, and unless their clients insisted there were no independent QA or tester roles and no PMs. They (the pairs of developers) did this stuff themselves. Thinking back again, the best software I’ve ever written was when I was completely immersed with clients and talking to them directly and I had to make sure it worked as it should. No middle man (or woman) interpreting customer needs and nobody else to leave finding bugs to, and since I don’t like my things to fail I sure as heck tested the heck out of my work.

All in all, I wish I knew a lot more about Ruby and Rails because they sound like a totally cool place to work. I’m not sure if Mike’s talk was meant to be a stealth recruitment exercise, but it could certainly work as one.

The second presentation I attended was from Chris Powers of Obtiva. He was talking about test driving front end code, and by front end code he specifically meant Javascript. It’s a few years since I’ve dabbled with JS and probably don’t have any dabbling in the near future, but it was still interesting and credit is definitely deserved for live demo and coding activities. The tool Chris showed was Jasmine, and while I have nothing else to compare it to it seemed pretty neat, and I definitely liked the BDD-esque feel and the ability to express both feature and unit tests. If I were to be doing any JS in the future I think I’d be checking it out.

The third and final session I attended was given by Paul Rayner and was entitled Strategic Design using DDD. There was some though provoking stuff in this. First of all there was the Purpose Alignment Model by Niel Nickolaisen. It’s a simple idea whereby you can map out work onto a graph with four quadrants like so:

Of particular interest here is the notion that those things which fall into the top right quadrant are the ones you want to put your best effort into – you want to get the best people working on this and you want to really pay attention to the design of this stuff. By contrast, those items that fall into the lower left quadrant do not merit that kind of effort.

If I understood Paul correctly, he was advocating the use of the above to think through just how much effort you put into the design of various components of a system. That seems like a good idea. But what also struck about this from an agile and scrum perspective was how such a simple thing could be used to facilitate feature prioritization in product development. Now I’ve seen before the idea of having the stories (or themes or features or what have you) up on post its on a white board, and allowing people to move them around placing those the see as highest priority at one end and lowest priority at the other. But this would overlay a slightly more rigorous evaluation of things. If, when using the open whiteboard technique, someone places an item over on the high priority side I am not immediately sure why. If the whiteboard was divided into four quadrants like the above I would immediately see if they thought it was mission critical, a market differentiator or both. I think that could be powerful.

The second thing I got out of this session (actually a little afterwards, after Paul had blogged on the topic) was that the popular idea of “emergent design” is great if you can do it well. But how many teams really have the design and refactoring skills to pull this off? How many can spot good and bad directions to emerge to. Having a framework to first identify what components of a system merit more well-crafted design than others along with a set of good design skills to apply would indeed help I think.

The third thing Paul talked about which stuck in my mind was his "billboard test." The idea here is that if you take something you're working hard on and imagine it up on a billboard is it really the message you want conveyed? Consider his example: "Our logging framework kicks butt!" Frankly, unless your company actually sells logging frameworks realizing that you're putting this much effort into logging ought to give you pause for thought. Like say for example "Our test automation framework kicks butt." Or whatever. (Inside joke)

And that’s it. The trip home was quicker than I thought it would be too. Was very ready for the highway to have turned into parking lot but things zipped along nicely.