How to completely fail at BDD

Are you interested in introducing BDD to your team? Don’t try and do it like this under these circumstances. Learn from my failure.

Having experienced ambiguous requirements specifications and inadequate testing of the applications I’ve worked on during my career as a software developer, when I saw BDD I thought I saw the future. In particular the Gherkin based implementations (Cucumber, Specflow) with their Given/When/Then descriptions of scenarios for product features that could lead to executable specifications blew me away as full of potential.

I was incredibly eager to try this stuff out on a real project.

I played around a bit in my spare time with Cucumber. I learned how features were specified in plain text feature files and tests related to them were implemented in step definitions. You match the scenarios you describe in your feature files to step definitions that exercise your application code using regular expressions. I’d never really used regex that much so was initially a bit concerned that this would be a problem. It turned out though that with a small grab bag of regex tricks you could do most things you needed.

One of my first real problems I ran into was that I was looking to try BDD on an upcoming C# project. That put me in a minority group. I don’t entirely pretend to understand why, but much of the C# ecosystem seems pretty closed off, lacking in the use and acceptance of rich open source projects that I was used to in my prior life working on projects on the Java stack. (As an aside, I even notice differences when I interview C# programmers compared to Java programmers. The way they think. The things they have and haven’t read. They typically haven’t done unit testing, typically haven’t used any open source software. In general, their view of the software development world is quite shuttered. I know this is a gross generalization, but it’s noticeable. It’s a shame, because C# seems like a pretty cool language…)

I quickly found Cuke4Nuke which allows you to implement your step definitions in C# rather than Ruby (the norm for Cucumber) and Cuke4VS which would give you syntax highlighting etc. when editing feature files in Visual Studio. Here I encountered my second couple of problems: Cuke4Nuke wasn’t ready for .NET 4 and Cuke4VS even to this day doesn’t work on VS2010. Of course our project was using .NET4 and VS2010. Fixing Cuke4Nuke wasn’t too hard, I fumbled my way through that OK. Fixing Cuke4VS though was beyond me. Well, beyond the amount of effort I wanted to put in anyway. I’ve not done much with C# and nothing with Visual Studio addins like this. I sorta got it working, but nothing I could push back as a quality patch to the Cuke4VS project.

Then I discovered Specflow.

Specflow has some distinct goodness:

• It’s Gherkin compatible, which means you describe your requirements in terms of features and corresponding given/when/then scenarios. While I lack the experience that would come from doing substantial real work in this, it intuitively feels “better” to me than the table based approach taken by Fit, Concordion etc.
• It’s good to go with VS2010 and .NET4.
• No Ruby required. With Cucumber, even though you can write your step definitions in C# courtesy of Cuke4Nuke, you still need a Ruby installation to parse your .feature files and call out over the wire to your C# steps. I’m not the first to observe that the .NET/C# community is kind of reluctant to install “weird shit” like Ruby that “doesn’t come from Microsoft”.

Sadly, at this point in time it also has some challenges:

• Documentation. The main problem is the documentation, or lack thereof. Pull down the “Specflow guide” PDF and you’ll find a clear work in progress, incomplete and missing sections, editing notes etc.
• Examples. Github hosts a SpecFlow-Examples project, but it needs some TLC. There are some reasonable examples in there, but quite where is not immediately obvious. All the action is inside ASP.NET-MVC/BookShop, not the features folder. Github is also potentially another barrier to entry for people. I don’t know how many C# developers are familiar with Github, but none on my team are.
• VS silliness. Not Specflow’s fault, but I had hoped to use Visual C# Express for the QA people on my team to create .feature files. Sadly Microsoft has seen fit to not support Add-ins so it doesn’t work. Another barrier to adoption, at least for my team.
• Stability. I never actually experienced this myself, but two of the engineers on my team said they had stability problems that they attributed directly to Specflow. It “mangled the project file.” Things “wouldn’t compile and it was complaining about Specflow stuff”. I never really got great details on this, so it’s hard to tell how much if any was directly down to Specflow. How much was me with rose-tinted glasses seeing no problem attributable to Specflow and perhaps others less interested in a new technique seeing every problem attributable to Specflow.

In general, you’re going to need a lot of patience, a genuine desire in a majority of the team to do something quite radically different to “normal” and you’ll need to draw a lot of information from the Cucumber community and then be comfortable using the mailing list for additional support. I’m actually OK with this, but it can be a real barrier to entry for a lot of people.

There were also some serious non-technical challenges; people skills and organization/political in nature.

Process and regulatory barriers.
My team makes software that is subject to 21 CFR part 11 regulations. That’s stuff that tries to help make sure any pharmaceutical drugs you take are safe. That kind of industry cascades regulations through to any software related to clinical studies to make sure the software is of high quality. Our operation can be (and frequently is) audited by our clients to make sure we comply and can (though rarely is) audited by the FDA. Having devised a “winning formula” that gets us successfully through audits people are naturally reluctant to make changes in anything that would get seen by an auditor. Having your “requirements” in .feature files alongside source code then is a serious brown trouser moment for some people.

• “They could end up seeing our source code!” Yes, believe it or not, a process designed to make sure the software involved in clinical trials doesn’t actually often have people look at the source code. They prefer Word documents, signed in duplicate (or more).
• “We need to show them a traditional requirements specification with numbered requirements that we can trace through to test cases.” Because that’s the only possible way to do this. Of course.
• “We have to review and sign off the test scripts before they’re executed, and prove that we have done so.” I can see how this made sense 20 years ago when test scripts where a documented set of steps a manual tester followed. But what does this even mean when your “test script” is a plain text .feature file and a corresponding set of step definitions in C#?

I actually have to commend the internal quality expert I spoke to for being very receptive to new ideas and trusting my assertion that I could probably generate a traditional style requirements specification and traceability matrix that mapped features to test cases from .features files. She was less resistant than some people on the team.

Skills Deficits
The people on the team responsible for testing the product and generating the nice bundle of validation paperwork those who audit us like to see primarily have a background in testing software manually. I’d looked over their manual test scripts before (long Word documents with lots of boilerplate and then long rambling detailed steps with expected outcomes and places to mark discrepancies) and got the impression they could be better. They seemed to meander quite a lot, with a lack of clarity over exactly what precisely one was testing. I do now know how anyone could review them and spot test cases that were missing. I’d even taken a manual test script for a fairly trivial feature that ran to thirteen pages and felt pretty smug about being able to reduce it down to one short .feature file.

Some people on the team had asked me whether I thought those folks could use Specflow. Could they write good .feature files and the corresponding step definition classes? It was a fair question, and I was pretty sure some might struggle. That said, we already had a test automation tool called Test Partner that involved folks writing things in VBA, so if they could do that, could this be much harder? And I didn’t see this as a reason to indicate that Specflow and BDD was wrong. If BDD is a good idea it’s a good idea. Sure, maybe we needed to train folks or modify the composition of our team, but that was all.

But oh did I underestimate just how much they would struggle. At this point in time I wasn’t sure if Visual Studio Express would work with Specflow. So I suggested they just try. There then followed quite the flurry of emails. People who ostensibly test things for a living were unable to reliably determine whether they could use Visual Studio Express or a full featured version.

And that was just the installation.

Then we got into writing a few .feature files. The first one wasn’t…very good. This was a little disappointing as I’d circulated a number of links to articles on the web about writing “good” features but, OK, it was a first attempt. A couple of the software engineers very graciously (much more gracious than I’m being right now, but I’m currently enjoying my second Left Hand Brewing Company’s Fade to Black) pointed out some things they might do to improve them. Sadly subsequent attempts at writing .feature files were no better. It was as though the advice offered was ignored or not understood.

We didn’t even get near them implementing a step definition. I really have to wonder what they’ll be putting together in Test Partner in those VBA scripts it uses. Thank goodness we have unit tests.

Incumbent Test Framework
As indicated above, we have available (actually we’re pretty much obliged to use) a product called Test Partner. Of course it’s only for QA people, especially given the per-seat cost. It’s all kinds of horrible so far as I can tell after looking at it. It doesn’t even make it easy to place your test scripts under source code control, preferring instead to keep them inside a database (but of course…) and though you can export them (base 64 encoded, naturally) it’s hardly ideal.

In addition to the original Test Partner investment, several people have spent a not inconsiderable amount of time and money building an additional layer (or framework) on top with functionality for such things as logging and managing collections (*cough* reinventing the wheel *cough*).

Of course the political reality attached to this state of affairs is that any other pretender to the crown has got its work cut out.

Cultural suitability
My love affair with computers started back in the early 80s around age 10. A friend had an Apple IIe computer and we played Bouncing Kamungas and other mad games, we entered epically long listings that sometimes worked. The school had a Commodore PET. I learned to program simple games in BASIC. I got a Vic 20 and wrote more games, even sold some to people at school. Then later I got an Amstrad CPC 6128 complete with it's wacky 3" disk drive and after that an Amiga. I worked in an independent computer store and wrote code for their business customers at age 16. I went to college and learned more. I got a “proper” job. It’s waxed and waned ever since. There’s still nothing quite like the fun of programming I think. But the reality of a corporate job can take the shine off that – it’s not the same as sitting there with your best buddy late at night debugging a game you’ve spent all day writing. So throughout my professional career my enthusiasm has varied along with different projects, languages, technologies, jobs and bosses.

Nevertheless, several years back I took a leadership position, got interested in agile and discovered a new found passion for reading about and playing with new technologies and approaches to building software. I joined twitter, found a community of thought leaders and everyday practitioners, started reading books and blog posts on all of this, got excited, started a transition at work. Mostly successful. But not successful enough I guess. I’m still one of the very few people that does that kind of thing. And when you’re perhaps the only one on a team that reads and writes blogs, uses twitter, reads books, wants to try doing things differently it can be tough. You're seeing so much that other people aren't.

The fact is I’ve been having to sell BDD to almost everyone. Maybe one person really “gets” the potential. A few more are fairly excited about it. But it's so far outside their comfort zone.

When I first managed to get some consensus that we should try this I hadn’t done enough with Specflow myself, almost all my experimentation up to this point was with Cucumber. I wasn’t worried though, the guy that was going to try it was an excellent engineer. I was more than a little surprised then when almost every hour a new “issue” was presented on why this couldn’t possibly work. I hadn’t seen that coming.

Culturally, my current team just isn’t ready or interested in something like this. And I have to accept that I can’t necessarily change that. Maybe I should have done a lot more work with Specflow myself first and had good examples to show people. I'm not sure.

Blah, blah whine! WTF am I gonna do about it?
I don’t know yet. Not for sure. I’m thinking maybe I can contribute to the Specflow project and help out with the documentation. This isn’t entirely appealing though if we won’t even be using it. So maybe I’ll use it on the sly, even if we’re not “officially” using it for our project maybe I can keep trying it out. And use that experience to develop something like the documentation that people on my team felt needed to be there.

If you have any suggestions, let me know...

OK, self-indulgent rant over.

Shouting is not an agile value

The Agile Manifesto is well known:

We are uncovering better ways of developing

software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on

the right, we value the items on the left more.

Related, but perhaps less well known is the idea of Agile Values. Their origin lines in Extreme Programming, with there being five recognized values as of the second edition of Kent Beck’s Extreme Programming Explained.

In brief the five values are:

• Communication – amongst all on the team
• Simplicity – of design, emphasizing ideas such as implementing the simplest thing that will work and the acronym YAGNI (you ain’t gonna need it)
• Feedback – feedback from automated tests, from the customer and from the team
• Courage – to keep things simple, to implement only what is needed today, to refactor and throw away code that’s no longer needed
• Respect – for other team members, for the customer

The fuller definitions can be read on Wikipedia (or of course in Kent's book).

One blindingly obvious thing you’ll notice is that shouting is not an agile value. Never was, never will be.

Well duh!

So why do I mention this? Oh well, you know. It’s not like there aren’t some managers who use that as a “technique” for trying to get what they want. It doesn’t necessarily have anything to do with agile, although regrettably I’ve seen it (and once done it myself) in response to somebody just not getting our new technical practices that came along with the agile adoption.

In my case it was due to extreme frustration with somebody who seemed almost perversely reluctant to commit code to the source control system. He was passing around changes to other colleagues by emailing them Java source code. This wasn’t the first difference of opinion about developing software I’d had with the gentleman in question. He harbored some curious ideas and was not enjoying our change over to Scrum.

I confess I rather lost the plot as we were there in the office late at night desperately trying to make sure the team made their sprint commitment. I blurted out rather loudly “What the $#@! are you doing?” I did quickly apologize and later after we’d got the job done we went to dinner and made up. I’m not proud of that moment and it’s not a “technique” I ever intend to use again.

Nonetheless, there are folks out there of a more strident nature inclined to use it far more frequently. I don’t know if their threshold for frustration is lower than mine or if they just need an anger management class or what the deal is. Suffice to say though, as an approach to trying to coach staff into doing what you want it’s not a winner. Indeed it’s a completely toxic behavior. Even if Mr or Ms. Shoutypants has great ideas people are very unlikely to ever “hear” them because they’ve written him off as an aggressive belligerent asshole.

Patience. Now there’s an Agile Value. In fact it’s a key one I believe. Stimulating, inspiring, managing and maintaining the change to agile practices takes effort. It takes leadership. And it takes patience. And so I propose that we add to communication, simplicity, feedback, courage and respect the value of patience.

Measuring the hypotenuse

Consider the following right-angled triangle:



What is x? Not a trick question.

Well it’s 5. Obviously.

But how did you know that? Well maybe for this very simple example you happen to just remember that 3:4:5 are the proportions of a right-angled triangle. But given a non-trivial example with less straightforward lengths to the two known sides you would doubtlessly have employed Pythagoras’ Theorem. Certainly that’s what most people would expect to see if they presented you with such a problem.

There is of course another way. Assuming the diagram is to scale you could measure x.

But that’s not what people would expect; especially if they’d ask you to use math to solve the problem.

In previous blog posts I’ve described a programming problem I set interview candidates at my organization.

The coding exercise I set people is pretty simple. It draws its inspiration from the old text adventure games the likes of Infocom and Level 9 used to produce. If you’re not familiar with this genre the basic gist of them was that there was an unexplored territory that you could wander around with things to find and puzzle to solve. Players interacted with the game using simple text based instructions such as “go north, get axe and kill troll”.

The exercise requires the candidates to do nothing quite so complicated as that though. They simply get an XML file describing a simple collection of rooms connected in various ways and containing various objects plus a text file describing their starting location and objects they need to go find. Their task is to write a program to read the two files and then use some approach to wander through the maze and try and collect the items.

Just as you would expect something to use Pythagoras’ Theorem to find x in the problem above I would expect people to use some kind of algorithm to solve this programming exercise. I don’t care if the algorithm is as dumb as a stumbling drunk, randomly staggering from room to room until every item is found or if you’re using something like Djikstra’s shortest path, just so long as there’s some kind of intelligent solution for us to discuss.

Up until now nobody had disappointed with that expectation either. Just recently though I got a very novel submission. What the candidate had done, rather than algorithmically solve the problem was to simply issue a series of printed lines that simulated what the output might look like if they had done the exercise for real. In other words their “solution” basically was:

Console.Write("At Sculery: lamp\n At Dining Rome: plate\n At Pond: Fishing Rod\n At Library: book\n At Cave-Entrance: Pickaxe\n At pine Forest: Pine cone");

I hunted around for a bit in case there was more. Alas there was not. When I was trying to explain to the recruiter involved why there was no point proceeding further with the candidate I came up with the hypotenuse measuring analogy which he got completely.

Although I’ve never seen anyone else “solve” the programming exercise in quite this way, regrettably I have seen others who approach problems similarly, trying to find any and all obtuse approaches to avoid actually coding what’s really needed. A common variation on the theme is mangling unit tests in perverse ways to avoid actually testing what you should be.

Since this isn’t an isolated phenomenon I decided I’m coining a new term to describe it. Henceforth (for me at least) programming “solutions” that completely miss the point will be known as a “measuring the hypotenuse” approach.

Top ten tips for distributed scrum team teleconferences

Distributed software teams using scrum can spend a fair bit of time on the telephone. Even if you only talk for just sprint planning, daily stand-ups, reviews and retrospectives that could easily be 6+ hours in a two week sprint.

When the team is spread around geographically you inevitably have a mix of people: some feeling tired because it’s early, some feeling tired because it’s late and always some annoying peppy ones because it’s the middle of their morning and they’ve had 7 coffees so far.

Add in cultural differences and that English (or whatever your primary language for communicating is) might not be someone’s native tongue and you are sometimes going to have challenges.

Here then, after acting as scrum master for several months on a distributed team with people in six different locations, three different time zones and two different countries, are my top ten tips to help get past those inevitable awkward silences:

1. Use a lot of questions.
Sometimes it’s not clear where to go next. If you can think of lots of different ways to frame questions, that can help. A question that wasn’t clear posed one way may be more accessible put in different terms.

2. Ask specific people for their view.
Asking, “Hey Bob, what are your thoughts on this?” will usually trigger one of two things: either Bob is going to tell you he doesn’t really understand what’s going on, or he shares the thoughts he was sitting on. Sometimes you might do this several times in a row. So after Bob you could be following up with, “And what about you Sally?”

3. Ask the quiet people.
This is a variation on #2. When conversation is flowing well sometimes the quieter members of a team can be left without a chance to contribute. When conversation isn’t flowing at all it’s often tempting to prod the more vocal members of the team. Instead of starting with the “easy” targets seek out other team members to encourage their contribution.

4. Volunteer your own opinion.
Just because the Scrum Master is meant to be a facilitator doesn’t mean he or she can’t have a useful opinion. Myself I can often hardly keep my mouth shut. I don’t think it’s a bad thing to throw out what you see, what you think should be done and solicit feedback on that.

5. Volunteer a ridiculous opinion.
This may be a bit Machiavellian for some, but I confess I use it myself: “So how about we use to solve ?” If it’s daft enough, somebody will usually be unable to resist telling you why that won’t work…which is the perfect segue into “Well what could we do instead?”

6. Use some humor.
You don’t need to be a stand up comedian and you don’t need to aim for tears streaming down people’s faces and belly laughs. But a little comedy can help lighten the mood and reenergize a meeting. Self-deprecating humor is a good way to go. Especially easy when you’ve got a ton of things like me to laugh at about yourself.

7. Take a break.
Long meetings need breaks. When you’re all sat in a conference room together nobody thinks twice about nipping out to fetch a cup of water. Everyone else can obviously see who’s gone and carry on accordingly or wait for their return if it’s crucial. But when you’re “blind” at the end of a phone I find more structure helps. I either build in a 10-15 minute break midway through a longer meeting or, if I sense things are flagging, ask if people would like to stop for a bit.

8. Switch topics.
There is, as they say, no point flogging a dead horse. If you’re making no headway as team with something perhaps there’s some other useful topic you can pursue together. Something more interesting or less ambiguous than what you were struggling with.

9. Do a mini-retrospective.
You don’t have to save retrospectives for the end of a sprint. You can retrospect on a single meeting or even midway through: “Is this working OK? Should we go about this differently?”

10. Note when people are “done.”
Now I don’t mean “done-done” in the definition of done sense. I mean worn out and you’re not going to get anywhere. Sometimes it’s just time to stop. There’s always another day.

Do you have any more tips for keeping teleconference meetings for distributed teams going? If so please share in the comments.

Mind your language!

I find it hard to pick out a favorite quote from Guy Ritchie’s cult movie “Lock, Stock and Two Smoking Barrels.” It’s just chock full of great lines.

Ignoring the obvious masterpiece from Rory, one exchange that I’ve always remembered with a smile is between Harry’s enforcer, Big Chris and his son (who is of course known as little Chris). They’re visiting someone who owes Harry money, and Big Chris’s son rifles through the indebted man’s belongings. Upon finding a serious pile of cash he exclaims: “Fuckin’ hell John, do you always walk around with this in your pocket?”

Big Chris, despite the dubious London underworld he and his son inhabit appears to have aspirations for his son to remain reasonably polite. He replies, “Hey! You use language like that again son, you’ll wish you hadn’t!” Unless you’ve seen it, it’s hard to appreciate the energy with which that warning is delivered.

Despite immersing myself in agile and Scrum and the language that comes along with that, and despite doing my best to socialize it over the last couple of years in my engineering group I think there are limits. Just as Big Chris doesn’t necessarily want his son to use the lingua franca of the underworld everywhere, I think you need to consider how far outside a development team you use agile and scrum vocabulary.

One of the three legs of Scrum is transparency. But being too transparent isn’t necessarily a good thing (think body scanners in airports, for example).

Maybe, if your entire organization has decided to operate using scrum, in everything from sales and marketing to operations, HR and accounting as well as engineering then you can happily talk about daily scrums, sprints, points and stories and velocity. But if they haven’t, then I think you have to balance carefully the education of those groups with whom you interact and the language you use.

For me, there are three key pieces of terminology that I am, with hindsight, wondering about the wisdom of sharing widely.


Story
Yep, I don’t think we should be talking about stories. Now don’t get me wrong. That doesn’t mean I don’t think we should be using them. On the contrary, I’ve said it before and I’ll say it again, one of the most profound books for me as I was learning about agile was Mike Cohn’s "User Stories Applied."

The concept is great. As a unit of work it’s perfect. For organizing requirements it’s helped tremendously.

However, as a term to use with unsuspecting business stakeholders, customers and so forth I’m not so keen. Frankly it sounds rather ridiculous. I’ll stick with feature, thanks very much.


Sprint
Few people with practical experience of dividing your development up into fixed duration timeboxes is a bad thing. But do we have to call it a sprint?

One of the things I like about Scrum is the fact that done right nobody’s having to dash like a lunatic to cram in all the last minute jobs to ship your product. Instead what we have when we do it right is a predictable, sustainable, humane way to utilize teams.

Sadly sprint conjures up anything but that vision.

These days I prefer to describe that we work in short two-week cycles, and if I need a short snappy name for them then iteration works just fine.


Points and Velocity
I’ve pulled these two terms together as they really go hand it hand. At least, if you’re estimating stories in points but not measuring your velocity you might want to reevaluate what you’re trying to achieve.

And these two are a little different for me than story and sprint. Whereas those are just unnecessarily goofy in everyday conversations with the wider business, and alternatives can serve us better, points and velocity need very careful handling, whatever you call them.

Here’s the problem – points and velocity are a tool for the team to be able to evaluate their performance, to plan and make reasonably firm commitments. Stakeholders outside the team should be concerned more with what gets done and in what order. The Product Owner and team together can use points to respond intelligently to new requests, to switch things around, and figure out what fits where and what needs to get dropped.

But start telling your stakeholders too much about average velocity, the points involved in a particular story and you inevitably risk them starting to focus on points rather than the “what should we do” and “what order should we do it in” issues. Perhaps in a really mature agile environment were a deep understanding of what points and velocity are for this wouldn’t be an issue. But early on in an agile adoption I think care is needed.

Too much data on story sizes in points, team velocities and so forth risks the following questions:

“Can’t you do more points per sprint? Why didn’t you make your commitment? Why has your average velocity dipped? Why does the tracking team have a higher velocity?”

Those kinds of discussion are not the most value one can extract from a stakeholder. I don’t want to see agile teams micromanaged by a group of well meaning people who know nothing about agile software development. But we are baiting them into doing exactly that if we report too much detailed data about points and velocity. Before you know it they’ll be looking at your definition of done suggesting we don’t need to do unit testing and who knows what else…

I say keep the dialog with stakeholders confined to steering the product, negotiating the relative priority and let the team use points and velocity data to communicate what can be done for any given release.

Put another way, what do you really want customers and stakeholders to concentrate on? The minutiae of your process? Or innovative product ideas and how they should be prioritized in the backlog?

Fully distributed Scrum

(Or, "How we pitched the idea of letting everyone on our team work from home and got the thumbs up")

---

Back at the beginning of November I wrote about my recent experience as the scrum master on a highly distributed team.

For those that didn’t read (or don’t remember) that post, a key thing to know is that the team is comprised of several people who work from home. I ended that post (partly tongue in cheek I admit) saying how it would be interesting to take those team members that were still office based and have them work from home too. Well, starting early 2011 we’re going to give it a try!

The original suggestion was first seriously discussed in a team retrospective. On the premise that it’s easier to offer an apology than ask permission I sent the appropriate managers in our group an email indicating that the team had decided we were all going to work from home next sprint. That didn’t fly. Which isn’t surprising (although it was worth a try, or at least entertaining, no?) and a more considered proposal was requested.

Myself and the team duly worked on preparing a properly coherent argument, supporting data, benefits we expected, a concrete description of how we would run this little experiment and details on how we would measure the success (or otherwise).

I know there must be many other teams trying to reconcile the demands of their managers to “do agile” and also “leverage offshore resources” so I wanted to share details of the proposal that helped convince ours that trying the rather radical proposal of sending everyone in the office home might help.

What are we trying to do?
Before we go anywhere further, it’s worth properly answering this question. Lest there be any doubt, this isn’t about folks wanting to get up late, watch daytime TV and get their laundry on during teleconferences.

This is an authentic endeavor to make our team work better. You can argue till you’re blue in the face about the benefits of team co-location, or the silliness of splitting teams into onshore and offshore components when you’re trying to simultaneously implement Scrum, but the fact remains that many, many organizations are still going to insist you can’t move the furniture and you have to structure teams this way.

Therefore, if we have to live with this, we’re going to make it work as best we can.

At the heart of much agile advice is an emphasis on communication. The trouble is, with team members scattered across different timezones and locations, communication gets clumped into localized groups. People on the edges miss out. By putting everyone on an equal footing (working from home) everything becomes more equitable and information sharing is normalized allowing for a better functioning team. At least, that’s what we believe, and what we’re trying to do is prove that out.

“Craft a philosophy and live it.” – Umair Haque, bubblegeneration.com

How did we approach this?
Our presentation covered five key areas:

• Why did we want to try this idea of everybody on the team working from home?
• A list of benefits, beyond simply the team working ‘better’ that we anticipated
• A description of how we wanted to run the experiment
• How we intended to evaluate the outcomes
• The support we needed to get this going

I’ve already talked about the why, so let’s look at the others:

Anticipated benefits
Besides the hoped for improved communication, there are some other interesting and very tangible benefits we anticipate.

As I write this blog post the time in Colorado is 2.54pm. Meanwhile, in Hyderabad it’s 3.24am the next day. We have quite the time difference between some of our team members. Before Daylight Savings Time (DST) came to an end in the US this year it was just possible (if not entirely pleasant for everyone) to have a daily scrum via phone with all team members present. Now however, since Indian Standard Time doesn’t adjust, the earliest we can hold our daily scrums is just unreasonably late for our colleague there to attend every day. Although they do stay late to attend some of the sprint planning meetings and sprint reviews they’ve been missing a lot, including retrospectives.

One very worthwhile thing we can do operating as a team that works from home is create a more humane work/life balance for people. This will pay particular dividends for our colleagues in Hyderabad, allowing them to work the majority of their days at normal local business hours. They can they stop just early enough and save the remainder for meetings in the evening. Although nobody particularly wants to have to regularly work super early or super late hours, this is a much better arrangement than having to be still stuck in an office at 9pm at night.

In addition, there are another couple of benefits we see. One is immediately realizable, the other perhaps a longer term proposition. They are reduced environmental impact through less travel and reduced office space needs.

An article in Forbes magazine in 2008 indicates there were as many as 17 million software developers in the world at that time.

More than 2 million of them are in India and the US is approaching 3 million.

Most if not all of these people spend time in cars or other transport every day commuting to and from work.

Indian emissions standards for motor vehicles lag about 5 years behind Europe, and in the US of course the majority of us love our gas-guzzling SUVs.

We may not be able to keep millions of these people off the road, but by allowing those that work in our team to do their jobs from home we can have a small but positive environmental impact. Who knows, maybe this innovative idea can spread.

As for the office space thing, if you can establish a team working at home, with perhaps continued but minimal office visits as needed then do you really need such large premises? With enough teams operating this way you could save on what you lease, on what you heat and so forth.

Running the experiment
Being a Scrum team convinced of the benefits of incremental and iterative development, we naturally intend to use the same approach to this experiment. Starting early 2011 we will try a sprint with everyone working from home.

At the end of that sprint, a large part of the retrospective will obviously explore how things worked. We’ll be asking ourselves questions like:

• How well did that work?
• What work well and what would we like to change?
• Can we fix the things that didn’t work well?

If we think it was worthwhile and we can improve those aspects that didn’t go too well then we’ll repeat another sprint with any changes we need. With this approach we can pretty quickly home in on how to do this well, or equally quickly conclude that our original arrangement with two-thirds of the team staying office based was better.

Evaluating the outcomes
Many years ago I used to quite like the idea of capturing data you could analyze to objectively evaluate things. Peter Drucker is renowned for saying “What gets measured gets managed.”

I’ve since learned that if you measure the wrong things in the wrong ways then it’s more a case of “what gets measured gets gamed.” Regrettably I’m not renowned for saying that. Maybe one day.

However, we do need some way to determine how our experiment is going.

Agile thinking provides us with a few simple tools that we can employ: velocity, burn-up charts and cumulative flow spring most readily to mind. To some extent though there is the possibility that these could indeed be gamed, or unconsciously given treatment to provide the desired out come.

So besides those, we will also be looking at some other areas:

• PO and stakeholder satisfaction. From their point of view are things better, worse or pretty much the same?
• Team satisfaction. Do we feel that things are better, worse or pretty much the same?
• If the experiment pans out well enough that we conduct a whole release with people working at home then we can utilize SLIM Metrics to observe productivity benefits.

Required support
Of course my team is not an island unto itself; we needed support to undertake this. First and foremost we needed the support of our management. Luckily the director of our group is open to innovative ideas and. After our presentation to him and a series of questions that the team was able to answer was willing to permit this experiment.

In more material terms we pretty much had all that we needed. People have broadband connectivity and telephones at home. They have quality spaces to work in. We do need to configure a few machines for remote access, and a few people needed new laptops. Other than that though, we’re ready to go.

In conclusion
The whole team is excited to try this. I think we’re onto something. I’m eager to see what our actual experience is like. Will things be better or just different? Next year, after we’ve run this experiment for a bit I’ll report back on how things have turned out.

Blog name change

I changed my blog name to "Coding When High."

This probably requires a little explanation lest you draw the wrong conclusions.



Originally I named this blog "Mixed Messages" with the explanation that I was unsure I could restrict myself to any one topic. And indeed over the last couple years there were a few  posts on things other than software development  topics. However, as its turned out, the vast majority of what I write about has stemmed from my experiences managing and participating on agile and scrum teams over the last few years.

Since a clear focus has emerged for my writing here I thought a new blog name was in order. Plus I wanted to play with Tumblr, so I'll henceforth be posting my non-work related stuff over at http://jonarcher.tumblr.com/ (nothing interesting there yet...)

So how did I arrive at this name? Well, I've recently switched back from management to individual contributor on a team. Currently I'm acting as Scrum Master, but with a definite intention of writing some substantive code soon. Add in that I live at 9,200 feet above sea level, up in the Rocky Mountains west of Denver, CO...et voila, "Coding When High" sprang to mind.

So no, don't worry. I'm not doing MDD (marijuana driven development).