Coding Exercises for Software Engineering Interviews

I've read about it. Talked about it. All with a positive "it should be done" spin to it. But despite that, I've never actually done it. It being to actually have interview candidates for software engineering jobs write code. Now I'm going to do it.

What really pushed me to action was being involved in a recent round of interviews for a Scrum Master. For this, we provided the candidates with a number of scenarios prior to the interview. These might be something like a product backlog of stories, information about some teams, velocity etc. and they then had to come in and present to the interview panel what they made of it. Certain challenges were inherent in the scenarios such as story sizes larger than velocity, stories that didn't fit neatly etc.

I was part of the panel interviewing some half dozen candidates, and I found this approach very insightful. Besides the interest of just seeing who could put together a small slide stack and talk coherently about it, it gave a much firmer foundation for asking questions about. Out were the theoretical "in such and such situation how would you..?" -- in was "I noticed that in sprint 1 you didn't get in all the top priority stories, can tell us about that decision?"

So, fired up from the Scrum Master interviews, I decided that I would come up with something to use for subsequent software engineering recruitment we would do.

I started off looking at an example from a colleague who had interviewed with Thoughtworks in the past. There were a choice of three problems a candidate could choose. They were very much your run-of-the-mill "coding challenge" though. I decided to think a bit deeper about what I was trying to accomplish.

My initial thoughts were focused on setting an exercise that would hopefully steer people to:

• Demonstrate competency with key Java APIs and features such as:
• Collections
• Generics
• IO
• XML
  Parsing
• Annotations?
  

• Show us that they knew a design pattern or two
• Wrote code that had suitable comments, Javadocs
• Used a consistent code style
• Utilized unit tests
• Employed a build tool beyond their IDE

I circulated these ideas amongst my esteemed colleagues, including Jim and Rajiv to get some feedback. Rajiv offered an interesting idea which I think we might use in conjunction with a coding exercise: how about presenting people with some fragments of code and asking them to spot errors and code smells in them (e.g. not closing connections in a finally block etc.) I like this idea but was still really keen to actually see somebody's work, some actual code they'd written. As I'm sure someone else has said somewhere else, "you wouldn't hire a chef without having him cook you a meal." He might be able to talk about the culinary arts in the most poetic and comprehensive way. But if he can't cook, he ain't worth squat.

In addition to Rajiv's idea, he and Jim both helped shape my thoughts on what kind of things we wanted the exercise to focus on. Key to this was something that would have the candidate demonstrate problem solving. It had to be non-trivial, non-textbook with a variety of approaches possible. Though also we couldn't ask they work on something too demanding and time consuming...

Ultimately, here is the exercise I came up with. I'll be using it soon because I have just opened up a position for a Principal Engineer in Billerica, MA. I'm very excited to see how this works out. If you have any feedback or constructive criticism please leave comments below. Thanks.

Code Exercise: A-Maze-ingly Retro Route Puzzle

This code exercise is (very loosely) based on some of the ideas in old school text adventure games. I enjoyed these so much as a kid I even learned how to write them on my old Commodore Vic 20. Thus began my descent into programming geekery. Ah, happy days.

Moving on... in this exercise you are supplied with two files. The first is an XML document (with inline DTD) that describes an adventure game map. It will look something like this:

<map>
    <room id="1" name="Hallway" north="2" />
    <room id="2" name="Dining Room" south="1" west="3" east="4"/>
    <room id="3" name="Kitchen" east="2">
        <object name="Knife"/>
    </room>
    <room id="4" name="Sun Room" west="2">
        <object name="Potted Plant"/>
    </room>
</map>

As you can see, a room may or may not permit travel in one of the four cardinal directions and may or may not contain "objects". The second file is a plain text file where the first line indicates the ID of the room the player starts in, and each subsequent line lists the name of an object they must collect. This file will look something like this:

2
Potted Plant
Knife

The objective is to write a program that will:

• Parse the XML and create a model of the map
• Read the plain text file, noting which room to start in and which items must be collected
• Output a valid route one could take to collect all the items specified in the text file
  

Given the above example the following is (one of the potentially) correct outputs:

ID  Room          Object collected
----------------------------------
1   Hallway       None
2   Dining Room   None
3   Kitchen       Knife
2   Dining Room   None
4   Sun Room      Potted Plant

There are going to be questions people have as they seek to clarify the above requirements, e.g. "Does my output have to be exactly like the example? Do I have to find the optimal route or simple a valid route?" I'm unlikely to provide any further clarification, but rather ask people to make and state their assumptions as part of their work.

Agile Adoption: Part III

This is my third installment writing about our agile adoption. In the first posting I discussed how we got started and how things started to pan out for us after a few months at it. In the second I moved on to look at a few of the practices we began trying after figuring out the basics. In this posting I'm going to share how we started to go beyond the notion of adopting a general notion of agile and selected Scrum along with some of the things that led to.

Ever since I started learning about agile I've become a voracious reader again. Blog posts, articles, books. I tore through many in the first months and continue to do so still. At some point I'll blog on what I found to be the most helpful material. For now though, what I want to talk about is how all this reading quickly deepened my understanding of the various ideas sitting under the general agile umbrella. In particular I was struck by the dominance of Scrum as a framework for agile project management. Although there was mention of XP and Lean (aka Kanban to some) and to a lesser extent I would stumble across RUP or Crystal...it was Scrum that seemed to have got center stage. And the more I've learned about it the more it seems clear why. It's a pretty light framework with minimal mandatory dogmatic things prescribed for you to follow. It makes a helluva lot of sense and it's not "hard" to internalize and figure out how to use it. At least not conceptually. Of course I think it takes a lot of effort to consistently employ it. If you're not convinced that Scrum is simple, try reading one of the short simple explanations of Scrum or even the official Scrum Guide. Really not that hard eh? Of course there is more to it than that. Applying this framework and these principles to an actual project leads to lots of decisions. Many times you need to "try" stuff and see what occurs. Scrum is great for that with feedback loops very obviously built into it.

All this reading about scrum started to change the language we were using. In the past we always talked about iterations, now they were sprints. People were getting comfortable with points and velocity -- much less talk of hours and days. We framed things in terms of stories now. Our former project managers were scrum masters. Our status meetings were daily stand ups. We didn't have a lessons learned or post mortem meeting, we had retrospectives. We didn't have iteration kick-off meetings, we had sprint planning meetings.

This change in language happened first just inside the immediate team, but eventually we were talking to our customers about velocity, story points and so on. I can't quite articulate why, but I found this to be immensely cool. I think maybe it was because we had started to get away from the "dammit I want all my stuff done by February" type conversations and on to much more productive and healthy "here's where the team is, here's what they look like they can do by February, maybe we should alter priorities of what's in the backlog so X, Y and Z get done."

This sea change in language was deeper than just terminology though. It spread in part through a kind of osmosis, but also through people's interest being piqued, through training (a number of people attended CSM courses) and through people sharing articles, doing their own research and so on. Again for me this was just the coolest thing to see, an organic growth in learning and interest from people.

Up until around this point we still had a rather large shadow hanging over what we were doing: stories weren't shared between software engineers and QA staff on the team. A set of stories would be developed during a sprint and, at the end, a build given over to the QA folks for them to test during the subsequent sprint. Any defects found resulted in a bug fix and new build. We were in effect doing mini-waterfalls, or "scrummerfalls".

We knew we wanted to get out of that pattern, and as we embarked on a new product release cycle we went all in on doing shared stories. Specifically now, a story was shared by the software and QA engineers, and it needed to emerge from the sprint completely done: developed and tested; bug free and potentially shippable. But there was more to "done" than this. We work in a business subject to FDA regulations. We can (and do) get audited by our clients and the FDA. They expect to see that we follow a rigorous software development process, that we have SOPs and follow them. That we follow what they believe to be best practices such as traceability from requirements to testing, that we unit test, peer review code and so on. To help with this notion of "done" -- meaning a feature was (potentially) ready to ship -- we decided to come up with a checklist that would serve as our "definition of done." This basically contained items like code the story, develop tests for the story, peer review of code, unit tests, execute manual tests, fix any defects, update any related documentation etc. 

As an aside...I was quite humbled to learn recently that we (that is me and my peers) did a piss poor job of getting this definition of done idea out to the team. I realize now that we dropped it on them already figured out, affording them no opportunity to discuss and agree what should be on there. Very bad and lesson learned for me there: people are going to feel like it's a mandate from their managers rather than a tool to help them. And really it should be a tool to help them -- something that makes clear all the good work they need to be allowed to do to develop software professionally; a guard against manager types and customers pressuring people to cut corners and build up "debt" for the future that we'll have to then rush to address or skip altogether.

This move to shared stories that need to be really done and potentially shippable at the end of the sprint had several more knock on effects:

• the order in which we implemented and tested stories was now important -- previously we just cared which sprint they were done in, now people needed to know what order they would get done in during a sprint
• we were clearly going to be releasing multiple builds during a sprint as stories were implemented and ready for testing
• we needed, more than ever, to keep our build "clean" -- ready to tag and build a version that could be put into the testing environment
• keeping our build clean meant an even greater need for unit tests and continuous integration (i.e. build on check in)
• much greater shared understanding and transparency between software engineers and QA engineers was necessary too
• the whole team shared estimation with planning poker

In addition to the above, a number of other things started to happen. We explored FitNesse (don't let the dodgy logo and generally retro look put you off) as a means to adding acceptance tests. That helped a lot with figuring out how far our unit tests should go. In the past there was some pretty heavyweight stuff there which was really integration or acceptance tests masquerading as unit tests. Thinking in terms of acceptance criteria or tests I believe is also going to help people do a better job of focusing on requirements.

With two product teams now running Scrum and a third already exhibiting many agile behaviors we decided to try holding a "Scrum of Scrums" meeting. We had tried in our pre-agile past many times to do *something* to get cross-team communication going. That had always typically failed in one way or another. Part of that, I think, was due to us having 2/3rds of the product development done by something less that a full-time, well defined team. This led to situation where when you got people together you needed too many and nobody was terrible interested in anybody elses situation. Now with stable teams we can have one or two members represent each team *and* there are only three streams of product development rather than a dozen. It still took us quite a while to figure out how to do the Scrum of Scrums, there's not a lot of concrete info out there, although talking with other folks provided some ideas. Right now we still have some ways to go, and may even change our focus in the future, but I believe for now we've found a good approach which I will write about at some later point.

After all of this change, what were we getting out if it? Well I'm pleased to say some pretty good stuff. Two key things were product releases on the promised date. In fact we were done a little earlier, which never hurts. But in addition to that, whilst we clearly could see some people struggling with the quantity and rapidity of changes introduced, most were thriving. There was a renewed spark in people's eyes -- they were starting to own things more, to realize they could influence things more. And that is clearly leading to a better working environment for everyone.

I'm confident that as we continue we will have more and more success. We will keep delivering what's needed on time with high quality. We won't have frenzied periods at the end of product release cycles burning people out on death marches. We will have predictability; we'll know team's capacities and we'll be able to plan well based on that. We'll use more automation. We'll see stronger relationships amongst team members. Our customers will be happier, more involved and satisfied with what they get. They'll trust us to deliver what they need.

In a bit I'm going to write more more part in this series of posts on our agile adoption. It's going to be the forward looking piece, talking about what I think we need to focus on next. Top of that list for me right now is figuring out how to capture requirements in a way that satisfies our regulatory obligations and is compatible with our Scrum approach to product development. Additionally I believe we should be focusing on more XP technical practices, test automation and really getting the Product Owner role accepted by the business.

Meetings

The other day I retweeted what I thought was an interesting article from the Harvard Business Review about meetings. The idea was that to avoid those days of back-to-back meetings by scheduling 50, rather than 60 minute long meetings. In this way the day is punctuated with 10 minute interludes that allow one to catch up a little bit.

I thought it was a great idea, but in response someone asked "how does that apply to meetings to discuss 'issues' where an email with the answers would do?" This is a good question, and I can't help but notice that there's a lot of gratuitous meetings. I wanted to comment on my thoughts and ideas about organizing meetings optimally for an agile team. Absent the full opportunity to try out some of these ideas it is more theory that proven methodology. Nonetheless it's based on my own observations and a fair bit of discussion and background reading...so it's not completely off the wall.

Personally, and I've read others feel the same (can't remember who though!), just inviting me to a meeting is a huge mental burden. Compared to emailing me, IM-ing me or even stopping by my desk I find it considerably more invasive. Any one of those other low key approaches and I can probably be done in minutes without really feeling to imposed upon. If needs be I can ignore/deflect the interruption too.

But you send me a meeting invite and it's an entirely different proposition. As the allotted time approaches it tends to creep into my mind...especially when that "15 minutes to go" Outlook remind chimes in. I wind down in anticipation, wander off to the meeting room (or dial in to the call) -- we do the smalltalk as we wait for everyone to assemble, then we're done...then I go make some tea or something. Finally I sit back down at my desk and try and get back into whatever I was doing before. The cost of the meeting in terms of flow is high. This is especially true for some: see Paul Graham's "Maker's Schedule, Manager's Schedule" for a good explanation of why this is.

All this preamble brings me to my first premise of meetings: I'm only interested in really necessary ones. It's far, far too easy for people to adopt a default mode for addressing things by calling meetings. Only recently I and two of my colleagues were invited to a meeting to discuss a bug by the people that found it. Of course the bug didn't really need a meeting. All salient information about the bug could be communicated via the bug report and clarification handled through informal discussion. The meeting was all about impressing upon us the severity of the bug and just how much we needed to pull our finger out and fix it pronto. I'd rather be told that straight so we're all clear about people's expectations.

I digress; moving on...so if we're only to have "really necessary" meetings -- which for me right now is those recommended by Scrum and probably some requirements workshop/story writing/estimation type things -- then how do we deal with all that other necessary communication that must happen on a product development team? How do we get clarity on various issues, or thrash out design decisions, etc.? My answer would be to just go grab the colleague(s) you need and get to it.

That notion may strike fear into some people: "Eeek no, leave me alone, if you must talk to me book some time, I don't want to be interrupted like that without warning."

But there are ways to handle this. In the Paul Graham article above he suggests one approach. I think it's spot on for all the meetings people like myself and my management peers want to have with people on product development teams, namely try and put them at the very beginning or very end of the day. That way people are left with a big hunk of uninterrupted time to do their thing.

But for the intra-team communication that must happen, I think this would be too rigid. Something I believe is more suited here is the Pomodoro Technique. At it's very simplest you can understand this to work as follows:

• set a timer for 25 minutes and focus on whatever your next work task is without stopping until the end
• at the end of the 25 minutes take a ~5 minute break
• repeat
• at the end of four of these "pomodoros" take a longer break
  

It's more subtle than this, but the key additional points that I see are:

• don't permit interruptions when the timer is ticking: ignore email, IM, phone and people walking up to you (gesture pointedly at the ticking timer...)
• deal with any important interruptions during the breaks, e.g. go see what Bob wanted when he wandered over looking for you
• If Bob is also using the Pomodoro Technique he may either have decided to wait until you are free or started up another pomodoro (25 minute work session) of his own. Obviously if he's done the latter whatever he wanted wasn't that important...or maybe he IMed/emailed his question. If he's waited then maybe he's looking to work on something with you: it could even be done as a shared pomodoro.

I think this approach would be a very effective way of handling interrupts without ever forcing people to wait an unreasonable amount of time for access to another team member. I say "I think" because I've not had chance to put this fully into practice in a team with everyone agreeing to work this way. I've use pomodoro's myself as a simple way to just focus on getting stuff done. Procrastination is harder when using them. And it stops me from "allowing" myself to be interrupted. Based on that evidence alone I feel pretty good about how well it could work for a team. Organized this way I they would still be able to have frequent interactions as needed. But they wouldn't be filling up their calendar with "meetings" just to talk to one another.

Of course one key enabler for this approach is probably co-location, maybe even ideally a shared team room/workspace where everybody sits. But even without that I believe it would be a good approach.

There's also a psychological benefit I believe to not having a calendar full of nasty white blocks of meetings. You wouldn't feel so much as though you had been subjected to a day of meetings, unable to "get anything done". Rather, you'd feel like you had been working all day long, some of that time collaboratively with your colleagues as you and they found it helpful.

Therefore, my second premise of meetings is: handling issues via informal discussion doesn't mean you need to be unpredictably interrupted all day long.

Of course there are meetings that have to happen. Sprint planning meetings, retrospectives, requirements workshops etc. And for these I believe it's key to adhere to a few principles to enjoy success.

First of all, any real meeting needs an agenda, preferably with each item on it timeboxed. I've been known to reject invitations or at least tersely question the sender in the absence of agendas. Now obviously you can't go around doing that to everyone...but for a group of peers running a Scrum product development team everyone is free to call out colleagues requesting meetings that are all too vague.

Additionally it's important that any meeting is well facilitated: who's keeping notes? Who's ensuring we stay with the agenda? Who helps encourage the less talkative members of the team to voice their opinions? Some of these things can be shared amongst a good team, but having an identified facilitator makes for a good experience I believe.

Given how invasive meetings are they should be of a reasonable duration. I particularly liked that idea from the HBR of stopping 10 minutes early to avoid filling up entire hours. Multi-hour meetings (like spring planning) should have built in break times and they should be kept to.

Lastly, good meetings need respect from and for all participants. In particular I see the following as key:

• give people and their ideas and contributions a fair hearing
• invite people who haven't yet made contribution to volunteer their opinion
  
• be there and start on time -- lateness is a lack of respect unless there is a good reason
  
• quality phone communications (rooms with poor hardware or acoustics plain suck for those on the other end of the phone)
  
• make the effort to be clear for those not physically present (i.e. those on the phone)
• use a webex if appropriate -- it helps those not in the room follow along
  

Thus my third and final premise of meetings is: if we're going to have a meeting, let's bloody do it well.

Yeah, I'm biased about the not physically present stuff...I do so many meetings over the phone :-)

Agile adoption: Part II

In my initial post discussing the adoption of agile practices in my engineering group, I gave some background on where we were a few months back and how we started to switch from waterfall to agile.

In this post I'm going to get into some details about the practices we have tried and how they have helped us (or not). Before I get into the meat of that though, one of my colleagues, Ram, commented on that first post. He had a very interesting point which gave me pause for thought. Amongst other things Ram said, "did the points estimating really helped us??i personally could not see the benefits out of it."

Chewing this over for a few days has led me to realize there's a couple of important things anyone reading this needs to know. Firstly, what I write here are my observations, and I'm not a member of any of our scrums teams such as (for example) Ram is. For those that don't work with or otherwise know me, these postings are the observation of a manager of a team of engineers. My concerns and observations will, necessarily, be different from those actually on a scrum team doing the hard work. Secondly, I may need to make clearer why I see some things as beneficial -- perhaps they would be obvious to peers, other managers etc. but I would like to share these views also with people on actual scrum teams. I think having a more holistic view of the whys, wherefores and benefits for more than just the team would be useful and (hopefully!) interesting. I know that two of the guys on our scrum teams have their own blogs and hopefully they will post their thoughts on our agile adoption over time. You can find Ram's here, and Rajiv's here. Rajiv already has posted some preliminary thoughts.

Now on to the real substance of this post. I'm going to cover what I remember as the next four items of consequence in our agile exploration: task visibility, proper iteration kick-off meetings, iteration retrospectives and lastly Twitter. Yes really, Twitter.

Task Visibility
Truth be told, having a decently detailed understanding at any given moment of what people were working and whether it was going according to plan was historically difficult for me. In part I attributed this to not playing the role of project manager for any of our ongoing endeavors...so of course I didn't know. But finding out when I needed to know was always a tedious process. It felt like it took more time than it should and never left me with much confidence that I had the full story anyway.

Our agile adoption almost immediately started to help with this. We employed two key tools: a simple task board and Basecamp, an online project collaboration and task management tool. The task board was set up in a small room we were able to use on a daily basis for our stand up meetings and was shared amongst the entire team. It took us a while to tease out "good" tasks and longer still to realize that the RA should have tasks on there too. At this stage we weren't really story based, and so the granularity of what was on the board was fairly variable. Nonetheless, being able to see at a glance how many tasks there were for an iteration, how many remained in committed vs. in progress vs. done was very powerful.

This physical task board was augmented by Basecamp. This was mostly popular with the software engineers on the team, and we wrestled for a bit over what should "drive" the stand ups ...the physical task board or Basecamp. Our situation was complicated by the fact that we had team members in both Eastern Europe and India. This led some of us to feel that Basecamp was the way to go, but, ultimately the physical board won out. I think upon reflection this was a good thing -- the simplicity and visibility of the board was key. The software engineers continued to use Basecamp to a greater or lesser extent for most of the remainder of this release cycle.

Proper Iteration Kick-offs
Even before our first tentative steps in the agile direction, we had typically divided our product development work into two week "iterations." This didn't actually afford us that much of a benefit besides perhaps enforcing a certain regular cycle when the PM would check in with the developers and obtain some vague indication of what they might do in the next couple of weeks.

Now the kick-off meetings had much more purpose: what are we putting into the "committed" column of our task board? If we estimate that stuff in points is it <= our velocity? From my perspective this seemed to give us a much more regulated rhythm to our work. Things seemed more predictable -- the team met their commitments. They thought harder and talked more about what they were committing to. Their was greater consensus across the team even though work on different facets of the project was still silo-ed in some ways.

Having seen how this panned out I would maintain that there's really no point doing work in iterations unless you are also measuring velocity in some way. There's just no point -- if you're not measuring velocity all you're doing is arbitrarily punctuating work with some meaningless and frequent end point for no benefit. When you do iterations with velocity however, you start to gather data about the capacity of the team. From this the team can become better at predicting what they can accomplish. There's a straightforward but worthwhile sense of accomplishment knowing you can approximate what can get done in a couple of weeks. 

Retrospectives
For me retrospectives, and what they imply if done well, are the key to agile success. If (for some odd reason) I could introduce a fledgling agile team to just one new idea it would be retrospectives. I've never been a big fan of meetings, but with a retrospective you can get so much:

• sense of team cohesion ("We're all in this together...something sucks? What would you like to do about it?")
  
• shared ownership of process (so many people are used to being "told" what the process is...and now there is a chance for them to shape it)
  
• an opportunity to challenge existing dogmas ("our SOPs won't let us do that")
• a forum for people to shine with insights and ideas that often don't get an audience
• a plan of improvement and a place to measure that improvement

What I also learned was that retrospectives need a great facilitator. It's all too easy for someone to go around the room and ask what went well and what didn't and get fairly anemic responses: "I guess what went well was we got all our committed work done...can't really think of much that didn't work out so good..." Getting people to surface the less rosy side of things is hard. There are of course those who always have views on this kind of thing (I'm kinda one of those myself) but for others it's awkward. Until people find that volunteering this kind of information is not just acceptable but welcomed some skill is required in extracting it. One way of doing this is through just lots of dialog. In a one on one situation people are often more willing to offer up something that's driving them nuts. I often would then try and find a way to toss this out for discussion without specifically identifying the source.

Twitter
I may stand alone on believing Twitter was a valuable resource that contributed to our agile adoption. Certainly I do not believe I managed to convince any of my peers of my boss to sign up (or if I did they're obviously using a pseudonym and cyber-stalking me). And this despite the copious links to informative blog posts etc. I sent them. Hmm, perhaps I did sent a few too many...

Anyway, personally I found Twitter to be a fabulous new tool for finding reading information relevant to agile. I developed a twice-a-day ritual of scanning my twitter stream and flagging interesting looking links for later reading. I started out with just a few people to follow, but through the way twitter works I was soon discovering others, from internationally known thought leaders through to ordinary people like myself writing about their experiences. With the recently added "lists" feature of twitter I have create an agile list which may be of interest to anyone wanting a starting point.


OK I think that's enough for a post. In the next installment I'll talk about some of the subsequent events including how we started to talk more about a specific agile methodology (Scrum) rather than a general notion of "agile" and some of the technical practices we started to put some focus on.

Chipotle Chicken

Ingredients

• 4 chicken breasts
• 1 pint heavy cream
• 3 tbsp chipotle en adobo sauce (search google for recipe, very easy to make)
• chopped cilantro for garnish
• butter for frying

Directions

Cover chicken breasts with plastic wrapping and slap it around a bit with a rolling pin until it's uniformly flattened. Heat butter until melted and bubbling over medium heat in a large frying pan. Add the chicken and let it sizzle for a few minutes. Lift it up and have a look underneath; you're looking to see some nice color has been added. Once this is the case flip it over and do the same to the other side. At this stage the chicken shouldn't be cooked all the way through.

Now add the chipotle en adobo -- use more or less than suggested depending on your preference for heat. Pour in the heavy cream and kind of mix it all together. The cream and adobo sauce will blend together and should start bubbling away quite nicely. I usually turn the chicken over a couple of times during this stage. When the sauce has reduced to a thicker state, if all is well the chicken will be nicely cooked too. I usually cut the pieces in half at this point both to check done-ness and because that's a nice serving size. Taste the sauce and if you feel it's lacking add in some salt & pepper.

Transfer the chicken to serving plates. Check your sauce, it may be ready to go or you may want to reduce it further by letting it bubble away a little longer. When ready, spoon it over the chicken on each plate.

Serve with a simple salad of shredded lettuce, diced tomato seasoned with lime juice and black pepper. You may also want to add your preferred Mexi-style accompaniments, e.g. rice, refried beans etc.

Book Review: The No Asshole Rule

I recently read Robert I Sutton's book, The No Asshole Rule. Apparently it was borne of an article originally published in the Harvard Business Review. I cannot claim to have read that original article but the book is great; I enjoyed it immensely.

Besides the frequent smirks spawned by the amusement derived in reading a "serious" work about assholes, there's plenty of just great writing, sound advice and lots of "yeah I agree" moments.

The book is pleasantly short, with just seven exquisitely crafted chapters covering everything from the definition of an asshole in this context (not just someone who pisses you off ;-) through to eradicating them if you have the power, or dealing with them as best you can if you don't. In addition there's material on the virtues of assholes (there are some) and how to stop your own "inner jerk" getting out too often. It was nice to read that we're all assholes some of the time. The acknowledgment of this reality in the book is good, because without it I believe it would preach an unattainable level of asshole free zones. In other words it's OK to be a temporary asshole, indeed as the virtues section indicates sometimes it's necessary to jolt slackers and under-performers out of their stupor.

The section on dealing with an asshole infested workplace has some solid advice. Since most of us lack the authority (not being the CEO and all) to go on an asshole eradication spree it's probably the section most useful to most people. In particular I liked the ideas like attending meetings with assholes via telephone: if you have a meeting with an asshole in at least you can avoid having to be physically in their presence. Similarly take pleasure in answering their emails slowly, or maybe not even at all. Having a sense of control over the situation as the author suggests is indeed a very empowering feeling.

Luckily for me, there are very few assholes I have to contend with these days. Nonetheless, having finished the book there are still a few candidates whose desk I am considering leaving the book on...

Agile adoption: Four months in.

Actually I'm not sure if it's four months, it could be a little more, could be a little less. But that's close enough. In some respects I wish I had taken time to blog about this much more frequently, as I think it would have helped me distill my thoughts on how things were going. Possibly even a slim chance someone else may have found it interesting too ;-) But I didn't. I'm going to attribute that to a lack of habit, and maybe I can cultivate that habit more going forward. On the upside, having gone four months or so before posting my thoughts on adopting agile practices, I do feel that I have got a fair bit of experience that has some value to it. Perhaps earlier posts would have comprised vacuous meanderings around the topic of no interest to anyone.

Onwards...

Now I try and think back, I'm not 100% sure I can entirely recollect what the trigger for the turning point was. The best I can remember, there was some...shall we say, doubt or perhaps concern over whether a particular project we were running was going to be feature complete on time. Let me explain a little bit about where we were at this time:

• we had a slew of software engineers (by our standards anyway) working away on this rather undefined "refactoring and re-architecting" phase of a major product release
• somehow, despite some top level goals for this phase being set, there was next to know clarity on what was really going on, nor whether it was worthwhile
• our customer certainly had no clue what was going on
• the deadline for delivery had been fuzzy until recently
• we had some nasty combination of huge horrible "the system shall" type requirements documents, use cases that were more use-less cases
• nobody had a clue what the QA members of the team were doing besides "regression and exploratory testing"
• the team was working in two week iterations, although they seemed rather purposeless upon closer inspection; the only thing that they seemed to do was ensure we more or less regularly provided a new build to QA
• the quality of the builds was low, often emergency "patches" were needed to remedy showstopper defects that somehow made it out to QA
• nobody was pair programming or doing TDD; the unit tests we did have were...let's just say sub-optimal *cough* not working *cough* or commented out *cough*

Anyway, back to the plot. So in a conversation about the need to critically evaluate whether this project was going to succeed, I may have blurted out something about my distaste for estimating in hours and how we should use points. I had done a little reading on this topic and sensed the potential -- estimating the work left in points and measuring velocity would give us a much better feel for progress I believed. They say you "should be careful what you ask for, as you may just get it" and yeah, I got it. So I went away and read a bit more (should we do S/M/L t-shirt size estimates? Fibonacci sequence?) before probably delivering the most disruptive message ever to my developers the next day. "Yeah this is Jon. I thought it'd be a great idea to estimate what we had left in story points. Have you heard of them? No. Don't worry. We're just gonna give it a go..."

I actually had us doing this wrong of course. Rather than estimating as a team I "pair estimated" with individual engineers for features they were responsible for developing. At this stage this was the expedient approach and looking back I still maintain it was better than do a "how many hours/days of work have you got left?" exercise. There was no QA involvement in these estimates, but I think that trying to get their involvement would have been too hard at that stage.

We settled on using 1, 2 or 3 as valid values for estimating our stories, mostly because it seemed simplest to get people to think about whether something was "easy, medium or hard" rather than agonize over a more complex set of choices. At this point I hadn't read any good material on what made for a suitable story, so many of our stories were tasks. With hindsight, although clearly not optimal this *still* was a step in the right direction.

It took the best part of a day for me to work with each of the engineers on the team and get their points based estimates for each of the stories (or tasks...) they believed they had left. Once this was done though I felt a distinct sense of progress. It was somehow easier to think in terms of there being about 100 points of work left, and how this therefore implied we needed a velocity of 20 points an iteration (not real numbers, but you get the point...)

With the "stories" and their corresponding estimates in a spreadsheet, and a daily stand up we suddenly started to be able to understand progress like never before. It was euphorically exciting to feel this degree of comprehension and transparency available to us. This feeling was a fleeting thing at first, but as iterations passed by and the velocity stabilized I think we all felt better about predicting success.

Stand up meetings were initially hard. People were late. People rambled. People didn't see the point. The chickens (myself and other managers) interrupted gratuitously to "coach" people on doing it right. We were eager but perhaps ineffective. Stand ups took ages. But, interestingly, we went from weeks slipping by with hidden issues, to impediments surfacing daily. And we'd solve them, or people would agree to work on solving them there and then. This was our second big win after understanding velocity I think.

With a toehold on our agile adoption, we were starting to build momentum. We have done much more since then, which I will write about it follow up posts to come.