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.

"Checking in" on the Coding Exercise

Earlier this year I wrote about how I was setting out to use a code exercise as part of the interview process for a software engineering position. Six weeks or so later, I haven't yet snagged my ideal candidate, but I sure as heck am sold on using this approach. I think I can safely say I'm never going to recruit without using an exercise like this in the future.

Here are my seven "lessons learned" from this approach to evaluating candidates. I had previously learned all of these lessons anyway, but it never hurts to have a refresher course...


1. Some people can "talk the talk," but not "walk the walk"

I'm looking to hire a "Principal Engineer" -- that may have some scope for interpretation when it comes to a precise meaning, but I'm fairly sure that by anybody's reasonable definition it includes the ability to write decent code. Quite frankly, to me, it clearly implies a software engineer at the top of their game. That's not to suggest that I didn't receive candidates that *sounded* like they were awesome...

But there was the thing...there is a surprisingly large number of people out there looking for a job at this level who aren't very good engineers. Some of these I kind of guessed might not be so hot from the initial phone screen. They fell into my "underwhelming" category, aka "didn't blow me away but I've no real concrete reason not to let them have a crack at the code exercise." But the other contingent here were those that phone screened like pros, that left me thinking "that's the one!" after I got off the phone with them. Sadly, quite a number of these turned in surprisingly mediocre work. (At this point may I offer my apologies to any former candidate reading this if I hurt your feelings. Sorry about that.) One person offered a solution that reminded me of when I first used to write code...around age 11. 'Nuff said.

Lesson learned: don't get carried away just because someone's a smooth talker and sounds impressive on the phone.


2. Some people can't read

I thought the exercise was pretty clearly worded. It wasn't too long or complex or ambiguous. I know some elements were not super-specific, but that was purposeful -- requirements often aren't clear in the business world anyway. The key aspects though were there. Or so I thought.

Moreover, I'm not too sure how you decide to undertake an exercise like this when looking for a job and don't pay really close attention to what you're being asked for. Maybe not doing so exposes that you're not a detail oriented person. That's certainly how my interview panel and I interpreted things when somebody sent us a "solution" that was completely different to what was required. As a reminder, the exercise requires an algorithmic exploration of a "maze" kind of environment. What we received was an interactive text adventure game. Which was cute and all, and it was clear that quite some effort had been put into it...to the extent that my initial reaction was that I wanted to cut the guy some slack. I was interested in having him come in for a face-to-face interview and finding out what happened. However, as my colleagues on the interview panel pointed out, submitting such a significantly wrong solution really did not bode well. If someone can't pay enough attention to get things right for a job interview, what hope is there gonna be when they have their feet under the desk?

Lesson learned: if it's wrong, it's wrong. Just because someone appears to have put a lot of effort into something doesn't mean they get away with producing completely the wrong deliverable.


3. Some people get stuck off in the weeds

This third point, moreso than any of the others, is likely to give prospective candidates some good advice. Lucky you huh?

I've seen this trait in engineers before, so it's perhaps not surprising to see it rear it's head amongst the candidates. I still don't quite understand it myself... Given that you don't want to spend forever on something like this that *might* help you land a new job, why oh why would you spend your time on things that are of low or no importance? At it's core the exercise requires you to parse an XML document, read in a text file and figure out some kind of algorithm to make your way through a maze looking for objects. Why then would you spend time on patently unimportant aspects or worry about odd or implausible corner cases? Some people think they're being "thorough" and there are times when that is appropriate. But one has to keep things in perspective...

Lesson learned: watch out for this behavior in candidates...because in someone on your actual team this can lead to a lot of waste from "over-engineering" to running around blind alleys (or mazes ;-).


4. Some people have surprisingly little pride in their work

Maybe some of what I interpret as lack of pride is more down to chaotic work practices, I'm not sure. Nonetheless, would you submit to a potential future employer code that was a mess as an example of your work? I'm talking about large swathes of code commented out, duplicate files, irrelevant files, stuff you've tried and abandoned etc. I wouldn't for sure...not exactly going to create a good first impression. Now I know I say to people "I'm not looking for a perfect solution" -- but I still would expect a certain degree of professionalism in what I do receive...

Lesson learned: another characteristic to watch out for in candidates. If this is what they show at an interview then goodness only knows what kind of stuff is going to come up when they're comfortably settled in their job.


5. Some people are incredibly slow

Perhaps this one shouldn't shock me. It's been known for decades that the best programmers are often an order of magnitude more productive than the worst.

Lesson learned: make sure you check how long someone spends on an exercise if you attempt something like this. Either that or provide clear instructions that they should only spend X amount of time (and even then check...) It's very telling.


6. Some people will give you whatever answer they think you want to hear

A gentlemen who shall remain nameless did a 180 on test-driven design during his interview because he thought we wanted to hear that this was the "One True Way" to approach software development. At this level of the game I'm expecting you to have well established and thoughtfully considered views on how to develop software along with an open mind that recognizes there is always room for learning something new. What I don't expect is you to roll over at the first challenge and alter your world view.

Lesson learned: yet another dubious behavior to guard against, at least in a senior position.


7. some people are awesome

I know it's been some rather grim and to some extent heavily laced with sarcasm and cheap shots at other peoples expense up to this point. But there is some good stuff too. There are some awesome people out there. I know this, I've interviewed them. Sadly they've not necessarily been the right fit or they've ended up going to other employers. However, they are out there. To at least see them during the recruitment process is a welcome reminder of their existence and of the fact that you've got to sort the wheat from the chaff if you ever want to bake some kick-ass bread.


And finally...
A few other interesting things that emerged. Out of many candidates so far only one has declined to undertake the coding exercise. Almost everyone has said they had a great deal of fun doing it, and a couple of said they're impressed that we take finding good candidates so seriously. A shocking number of people talk about TDD in their phone screen but then don't offer a solution with any unit tests ("well I didn't actually have time for that...")

Oh, and it's interesting how many people opt for the "stumbling drunk" algorithm whereby one wanders randomly around the maze looking for objects...