Location, location, location!

They say there are three important characteristics of real estate: location, location and location. The same is true, I think, for the characteristics of a scrum team. Where they are located has a profound effect upon their success and productivity. Agile advocates recommend collocation of a software development team and proximity to the customer.

This isn’t some whimsical notion, or a cunning anti-outsourcing ploy. It advocates this because it works. We have been trying to build software in a somewhat predictable and satisfactory way for a handful of decades now. We’re finally learning enough to understand what works. And what works can be summed up in a few sentences (hint: read the agile manifesto). With respect to scrum teams and their location, it comes down to:

• they need to all be together
• yes that includes their scrum master
• yes that includes their product owner

The idea that agile software teams can be twice as productive as old school waterfall teams, maybe even 5 or 10 times as productive is, unsurprisingly, highly appealing to those who manage development teams for a living.

But here’s where things get weird.

Before IT executives were paying attention to agile, they were paying attention to off-shoring and outsourcing. These appeared to offer a way to substantially reduce labor costs associated with software development and other IT activities. Software engineers in Eastern Europe cost less than Western Europe or the USA. And those in India cost less than their colleagues in Eastern Europe. You can go further still, to China, where engineers cost even less. It’s probably only a matter of time before someone sets up a militarized compound campus in a failed African state and you can get engineers for who knows how little.

Irrespective of location these are all potentially good engineers, and this pursuit of cheap labor is not, in and of itself, the weird part. In a globalized world of free trade it’s inevitable.

What’s weird is when people blindly ignore one of the most important principles of agile software development (locate your team altogether in one place with your customer) and try and distribute software development teams across the globe. That’s trying to have your cake and eat it too.

There are some folks that try and suggest, perhaps with their consulting fee in mind more than anything else, that this is just a reality of today’s globalized marketplace.

I understand to some extent how they are OK with that, but to me it’s just a sitting-on-the-fence response that avoids calling out the stupidity that is taking place. The cognitive dissonance produced by the equally dogged pursuit of agile adoption *and* offshoring is at times almost painful.

Scrum teams have the potential to reach 10x productivity of conventional teams. You’re not going to do that though without dedicated people acting in a motivated fashion. You’re not going to get that with a distributed scrum team.

Let’s say your business has its center of gravity in a high labor cost country like the US. And you have a software product that you need to develop for that business. You have quite a few choices how you go about this: scrum or non-scrum, team based in the same location as your business's center of gravity, offshore, outsourced or some combination thereof..

Let’s assume we’ve decided we do want to use scrum, so we can eliminate the non-scrum approaches. Now, if we’re to be responsible about this, we should be considering a couple of things:

• how can we develop this product economically; that is getting the most product out for the money invested
• how can we develop this product effectively; that is making the best product we can, getting the customer what they want

Now those salaries in low-cost labor countries that are maybe ~1/5th the amount of their high-cost labor country counterparts do look pretty tempting: “Dude, they could be 5 times slower and it still would cost the same.” Kind of. Ignoring infrastructure, opportunity costs, dissatisfaction from lateness, reduced quality due to misunderstood communication etc.

Hmm. Maybe we can mitigate the risks of them being so far from the customer by distributing a team: "Let’s have some talented senior people in the high-cost labor country, and augment that team with lower cost labor. Yeah. That’ll be the best of both worlds." Except of course you’ve now pissed off your talented people by asking them to play babysitter. And having to accommodate early morning calls. Or late night calls. Oh, and with that immense time zone difference? There’s no chance for them to really chat and help each other out. The high bandwidth face to face communication of agile isn’t helping here at all. I suppose you could fly people around all the time. Soon going to start eating into the big pile of cash you’ve “saved” though.

Double hmm. So on the other hand, what if we focused solely on staffing a team with people where the actual business is that needs the software. Yes, a team in the high-cost labor country. But concentrate on getting their productivity up to that 5x level? Well then you might say, in many ways, they cost no more than the low-cost labor staff. But it’s better even than that. They have a full sense of ownership, they’re engaged. The customer is happy, they are able to work with the team to get just what they want. No more telephone game and lost details thanks to ambiguous email messages. Not only this, but they get it 5x faster. Oh, and we don’t need that expensive infrastructure to support developing software in two places. Holy crap. How can this *not* be the right way to develop software? Anything else is missing a chance for competitive advantage, is being financially irresponsible; is, frankly, stupid.

Adopting Agile: Where should the emphasis be?

Many benefits are touted for those who chose to adopt an agile approach to software development. Some are more typically cited by coaches and tool vendors as a kind of sales tactic:

• your teams will become more productive
• you’ll ship business value sooner
• customers will be happier
• you won’t build features that aren’t needed

Others, perhaps less vigorously or frequently stated include:

• development proceeds at a sustainable pace, not burning out your staff
• quality typically improves, particularly if one adopts a lot of the supporting technical practices advocated by XP
• for most people, it’s a more fun, interactive and collaborative way of working leading to higher job satisfaction
• the time needed for feature development becomes more predictable

There are more than these but for the purposes of this blog post these will suffice. The question I want to ask (and answer) is, when adopting agile, where should the emphasis be? What benefits should we champion and pursue?

From the perspective of managers and company executives, those items in the first list really resonate. This is understandable; they correspond with responsibilities that those people have. But how exciting are they for those people actually on the teams that have to do the real work of creating working software?

Well, I would argue probably not very exciting at all. I think it’s a misconception, but the “your teams will become more productive” and “you’ll ship sooner” benefits are often interpreted by teams first encountering agile as “you want me to work even harder!?”

This reaction can be compounded with the introduction of daily stand-up meetings. “Oh, so now you want to micromanage it and check in on my progress every day?”

Both of these interpretations are (thankfully) incorrect. This is not the motivation for agile done properly and not what should be going on. It’s easy to see though how this misconception could arise when so much emphasis and commentary exists about those two benefits and how often they get trotted out.

This is why I would argue that the sensible approach is to focus on the benefits in the second list above. Emphasizing changes that bring these benefits are much more appealing to those people actually doing the work. They’re a much more humane and rewarding set of ideas. In my opinion, and experience from the last year, agile done right will really focus on the teams. On empowering them to control much more of the work and how it gets done.

I know that I, as a team member, would feel much better knowing that sustainable, predictable development was valued. I’d feel much better that the increased transparency of Scrum would serve to highlight impediments to my work, that would get the attention they deserve and promptly remedied. I’d love knowing that the organization valued quality and craftsmanship in software development. I’d enjoy not having to estimate every last detail in fractions of hours. I’d almost weep with joy at not having to comb through hundred page specifications of poorly written and ambiguous requirements documents.

Best of all though, focusing on these things, and aiming to unlock that second list of benefits will, I firmly believe, lead to those benefits in the first list. It’s inevitable.

Wot no team room?

You don’t have to do much reading on agile before you come across advice about how to arrange the environment for a team. And it’s pretty different to what most of us have available in a corporate office environment.

Much as a dedicated “war room*” for each team with no cube walls in the way, copious amounts of whiteboard space and additional private areas to retreat to would be nice, we ain’t got it. From what I know, not much of the corporate world usually does.

So what can you do? Well we recently decided to try and make the best of our lot. Previously, our teams were scattered to the wind over an area housing a mix of people from the organization. This had actually been purposefully done -- the idea being that it would get folks from different groups talking in an impromptu and synergistic fashion. Turns out that wasn’t quite the case. I won’t say no good came from it, but as we adopted agile, the physical separation of our teams was noticeable.

What we decided to do was try out a reorganization, where each of our teams were placed in contiguous blocks. We couldn’t get rid of the cubes, but we could make better use of them. We divided up the space into three groups of cubes, assigning one group to each team. Then we let each team negotiate amongst themselves exactly who would sit where in their group.

Now any large move like this is going to receive a mixed reception from those involved. Not all cubes are created equal. Some are of the premier variety; they are by windows, larger in size or have less “traffic” passing by them. Now understandably anyone losing that is not going to feel like their situation is improving. There’s often precious little comfort or individual benefit available in the uniformity of a cube farm and I for one can more than empathize with the desire to hang on to what you’ve got.

However, there were enough people in favor and the benefits espoused in a myriad blog posts and books seemed compelling enough to give it a try.

A little while later and I polled folks for their thoughts on things. The response was overwhelmingly positive, and while there were a few people who felt it was not an improvement most people were extremely happy with it. The following are just a few representative quotes that say it better than I could ever hope to:

“At first I thought that there was no real point - we weren't so far away, we could just walk a few steps, but I found out differently. We do interact more and include each other in conversations by heads popping up over cube walls or by overhearing ... so I was skeptical but am now a believer.”

“Honest opinion: It is the best I came across in 10 years of my life with Perceptive.”

“I actually love it”

“...communication has improved significantly now that we are all sitting together. I can't think of any downsides. “

It seems to me that our teams have taken things to a new level, which is clearly reflected in their positive feedback to this change. One recurring theme from people was how this had helped establish a much stronger sense of team, and of “being in it together.” Psychologists say a large part of job satisfaction comes from getting along well with the people you work with. I’d like to think that this change has had a positive impact in this way for our teams. By bringing teams together not only have they a better environment to do their job, but there’s more camaraderie too, which I makes things just a little bit more pleasant and fun for everyone.




*War room vs. team room. War room = aggression, danger, stay out. Team room = inclusive, fun, friendly. You decide... I forget who I originally saw tweet that, and I may not have it verbatim, but I liked the gist of it. In my opinion the world of business is too full of BS terms inspired by conflict: “war room”, “aggressive” time lines etc.

My Dad's on Twitter. You should be too.

Yesterday I received an email entitled "rkharcher is now following you on Twitter." That's my Dad. He's a pretty tech savvy guy but I was still pleasantly surprised seeing as how I had only mentioned the prospect of him joining half-jokingly the other week.

I've been wittering on about Twitter to various people who'll tolerate it for the last year or so. For those who've not experienced it, it's hard to grasp the potential utility of it. The media tends to portray it solely as a source of information about celebrity self-indulgence. *Why* on earth would you want to pointlessly inform dozen (or hundreds or even more) people of your mundane everyday actions or thoughts? Even more bizarre perhaps, *why* would you want to be informed of the same nonsense from others?

Well, here's the thing. Twitter is more a platform that you can use as you wish rather than an enforced stream of pointless drivel. It can be used in some very worthwhile ways. I'm going to share what I've learned about it in the last year. Maybe you'll be convinced to try it, maybe you won't. My honest opinion is you are unlikely to "get it" from just reading what I have to say here. You need to give it a go for a couple of weeks if I pique your interest. For me, it's become as essential as email and IM. I think the reason I most like Twitter though is because of the accessibility it gives me to people. For example, to see what someone like Mike Cohn (@mikewcohn) is writing about I can go visit his blog. But by following him on Twitter, I can see what he's reading too.

Career & Industry Information
This was what really got me hooked. Initially I signed up for Twitter because curiosity had got the better of me. But this happened to coincide with our adoption of agile software development. It didn't take long for me to find a very healthy and vibrant community of people involved in agile in one way or another. This ranged from the everyday person like myself, to industry thought leaders like Kent Beck (@KentBeck), Mike Cohn (@mikewcohn), Lisa Crispin (@lisacrispin), Jim Highsmith (@jimhighsmith), Ron Jeffries (@RonJeffries) and many more (apologies to those omitted, nothing personal).

Beyond the agile and Scrum world, I also starting finding and adding interesting folks doing software development in general.

Twitter became my top source of information and inspiration as I ramped up my knowledge of agile. The great thing here -- in contrast to simple googling "agile" or "scrum" -- was that I had this curated list of recommended links to articles, books etc. all flowing in for my perusal. The number of great discoveries made this way was huge.

Breaking News, and News in General
The second substantial use of Twitter for me is news. A lot of people will tell you it's good for breaking news, and that's true. But I've also found it to be good for news in general. With all the major international, nation and local newsources now on Twitter it provides a superb feed of highly scan-able headlines. One of the truly great things here is that the enforced brevity of Twitter (140 characters per tweet, maximum) kills the clutter associated with email or RSS based news updates. There's no clutter, no verbosity, no fonts...just clean simple headlines and you can quickly click through to stories of interest. Shakespeare had it right when he said "Brevity is the soul of (t)wit."

Responsiveness. Or Not.
One characteristic of Twitter which I only really appreciated fairly recently is how it occupies and halfway house between IM and email. With IM there's an interactive expectation. It's not much good unless the person you are IMing is at their computer too. Although email can mimic this to some extent it's a more verbose medium. Twitter sits somewhere in between. There's no expectation of an immediate, interactive response, although that can happen and it works great. The short messages can keep a conversation flowing. But equally tweets can go un-responded to for some time. It can mask timezones very well.

Controlling the Flood
One potential problem with Twitter is information overload. Luckily there are several mechanisms for handling this.

The first thing is to stop looking at Twitter like email. Based upon the people you are following, messages from them will show up in your "tweet stream". Unlike email, they don't sit there waiting to be read. If you don't look at it for a day, things just pass you by. This is nice because you can go switch off when you want and not worry about "missing" anything. You can be pretty sure that anything truly earth shattering will show up from more than one source over time anyway.

The second thing is to take advantage of "asymmetrical following." This is perhaps vastly more useful to celebrities than the likes of you and I, but it's still a key difference between Twitter and Facebook or Linked In. Just because someone chooses to "follow" you, doesn't mean you have to follow them. You only get to see the tweets of people you have elected to follow, and you can un-follow people anytime you like.

Lastly, a fairly recent new feature called lists can help sort the important stuff from the noise. The way this works is you can create any number of lists of your own, and add people you follow to one (or more) lists. Then you can just check in on certain lists. For example, I have lists for "agile" and "colleagues" and "news" etc.

The Social Aspect
The final aspect of Twitter I want to mention is the social element. It's somehow different (I think) than Facebook et al. There's an exploratory, discovery of new and interesting people to it. I've reconnected with people I haven't talked to in years despite having their email addresses or even IM accounts. Somehow Twitter has enabled conversations that they did not. I think a lot of that may be to do with the characteristics I described under "Responsiveness. Or Not." above. And Twitter is somehow humanizing for a technology. Catching a glimpse of friends and colleagues in a quite candid way does that. My colleagues now know what a total dork I am (if there was any room for doubt previously...)

Curiosity Piqued?
If you're interested in giving it a try, here are my pro-tips for getting started.

• Put a Twitter app on your smartphone. The iPhone is the best represented here. I've no experience with other smart phones but they all have something you can try. No smartphone? You can use Twitter over SMS. Looks like a pretty grim (and potentially expensive) proposition to me, but the option is there.
• Get a Twitter application for your desktop. On Windows? Try Tweetdeck or, my current personal favorite, Seesmic for Windows. Got a Mac? Good choice ;-) I Like Echofon but there are many others. The Mac has the best clients.
• Follow @Twitter_Tips. As the name suggests, they tweet out tips, often links to articles that are particularly helpful for those new to Twitter.
• If (when) you start getting emails indicating somebody new is following you take a look at their follower/following/tweet stats. THere is a growing spam problem on twitter. Bogus accounts will follow you (and hundreds of others too) hoping that naive people will follow them back. Once you're following someone you see what they tweet and they can even send you direct, private messages. Spammers of course will fill your tweetstream with spam... The key hallmark of a spam account is they have very few followers, have tweeted hardly anything and are following hundreds or thousands of people.
• Consider following me (@9200feet) ;-)
  

Feeding Body and Mind

Software development is an ever changing field. Some might even say volatile. Languages, tools, methodologies, paradigms, philosophies, manifestos. Structured programming. Functional programming. OO programming. Agile principles. Extreme Programming. TDD. Continuous integration. Acceptance testing. Automated testing. SOA. Pascal. ADA. Lisp. C. C++. Java. Python. PHP. C#. Ruby. Grails. Haskell. Scala. Cloud based computing and more...

How can one keep on top of this?

Well one very effective way the engineers have applied over the last few months is a regular "lunch & learn" session. The idea of something like this has tended to go in and out of vogue for years in Perceptive. There's always been plenty of topics that would be interesting: "Talk people through the latest work you've done," or "Show us what you've learned about the new technology your last project employed."

The big barrier of course is the substantial investment of time required to deliver a coherent and valuable session. And then to do that regularly, even monthly, even if the task rotates...well it just seemed really hard.

A few months back though, we hit on the solution. Google (amongst other sources) post a huge number of fascinating presentations and talks on a multitude of topics. And they're delivered typically but top thought leaders in the software development field. And they're free too...they're just a click or two away on Youtube.com or similar.

So we started running lunch & learn sessions. We'd start with watching a video that someone had picked out as interesting. Pizza would arrive. And when the presentation was done we'd sit and chat about it. We found it to be a really easy way to get exposed to new ideas and technologies. It required very little preparation effort which has allowed us to keep this up regularly, and in fact there's so much value coming out of this we're increasing our frequency from once to twice a month.

What's the point of points?

One of the earliest changes we tried out that got the agile snowball rolling was estimating using points rather than hours or days (or weeks...)

Estimating in points though is a weird thing. It doesn't seem to make a lot of sense at first. It's really quite hard to explain and has a rather abstract quality about it. Look at some of the things you hear or read when you go looking for an explanation:

"Points are a measure of effort more than duration"

"Points are relative, not absolute"

"Points aren't a measure of time, don't think of them in hours"

"Whatever you do, don't set up a conversion rate like 8 hours = 1 point"

And this "estimating in points" idea is meant to help?

When I started to read about points and their advertised benefits I sort of thought I got it. I wasn't certain, but I found myself ready to try them out and take a leap of faith.

Initially I was skeptical. After all, it's pretty easy to pick away at some of this stuff and claim that it's just another pointless (pun intended) change as one sees so often in software development. (Software development is, after all, partly a fashion industry.)

Take the claim that points are relative. Well so can hours be. For instance, if "feature X" took 100 hours and is estimated by me as approximately twice as hard as "feature Y" then, relatively speaking "feature Y" is gonna come out at 50 hours. So big deal.

However, here's the thing. Points alone are not that special. They do address some of the issues of estimation such as it tending to be fractal, i.e. at some point the more detail you break down your work into the more complexity you unveil and less less accurate your estimates turn out. But by themselves they are not going to solve any major problems.

Points + team based estimation + tracking team velocity on the other hand is very powerful.

Together these concepts work like the legs on a three-legged stool: it'll fall over if any one of them is missing, but together it's rock solid.

So how do these three things work in concert? Easy...

• Points really do provide a nice simple unit that discourages over-analyzing things and are very easy to to perform math on (twice as hard, half as hard etc.) They're very quick so there's no need for tedious marathon estimation sessions.
• Team based estimation encourages full understanding and participation by the whole team. It also limits the likelihood of the most experienced people providing unreasonably low estimates that other team members have to abide by. It also equalizes the understanding of effort between software and QA engineers.
• Finally velocity, that is the measure of total points of work completed per iteration, provides a team with an easily understandable measure of their capacity, i.e. how much work they can get through in an iteration. This is incredibly useful because it allows a team to guard against being asked to complete an unreasonable amount of work in a certain period of time. Moreover, with a list of features estimated in points one can now easily predict how many sprints are likely needed to get them all done. Much easier than estimating in hours...

Those three points (pun intended, again) are pretty good for me already. But there's more. We now have a much more customer friendly language to speak in. It makes for easier negotiations. It turns the conversation away from "can you just get it all done by June" to more of a dialog where they understand capacity and can make comprises over features to hit their preferred deadline.

And that, for me, is the point of points.