Sipping the Agile Kool-Aid

Speed up development. Improve the quality of software. Reduce the chances of a project failing. All of these are mighty big promises. From the upper echelons of management team resound the mantra "agile... agile... agile". Seems to me that someone has been sipping the agile kool-aid.

Silver bullets in this day and age are a dime-a-dozen. Get rich quick... Lose weight fast... Quick muscle gain... All supposedly simple solutions, that pay out large dividends. Too good to be true? The magic eight-ball would suggest "all signs point to yes". What gets to me, is the disconnect between the idea and the reality. Personally, I believe there are great benefits to be had from agile development. In particular, self-evaluation and continued improvement. Learn from past mistakes and attempt to correct them in the future. I digress.

Human and change are always difficult subjects. Humans often resist change. People like to keep doing, just what it is that they are already doing. Another part of human nature is to improve the way things are done. To use knowledge from the past to make things easier. Agile kool-aid sippers need to realise that mandating change does not bring it into effect. Follow through is required. You cannot merely sip; you must drink the kool-aid and let it quench your thirst.

Having standups, retrospectives, and iterations, does not mean you are instantly agile. Whilst certainly there are some marginal benefits from a management perspective, the real benefits should arise from the developers, and their continued evolution. To get to this point though, requires a mindset and operational change. Cowboys are a thing of the past. Put them out to pasture. Bring the team closer, and up-skill where possible. Focus the team, and balance size. The overheads of running larger teams can impact heavily on a team. Always be wary of the number of developers. I mean no disparagement to non-developer team members, however, for a development project, the majority need to be developers. Do not distribute a team lightly. Team distribution points are always contentious, however they are critical. A team needs traction, and will easily become demoralised whilst doing burnouts, praying for some traction.

Drink the kool-aid and enjoy it for it is and what it can do for you. Do not rest on your laurels and sip, whilst watching teams and projects disintegrate.

Regarding Interviews and the Recruitment Process

Everyone looks for new employment opportunities at some point in their lives. Those who work in the technology sector are no different. After recently undergoing a number of interviews and interview related tasks, I thought that I'd take the time to share my experiences: the good; the bad; and complete time wasters. For a bit of background, I'm a Software Engineer living in Sydney. Some of the companies I've recently interviewed with include Atlassian, Google, Ning, and ThoughtWorks. I'd like to say up front, that despite any negative spin that I put on the interview process, I still enjoyed them all (to some degree at least). Quite clearly, I was not successful with all of them, else I would not have interviewed at the other companies.

When it comes to interview tasks:

• Ask questions that you seriously expect the applicant to know. If you do not expect me to know, or don't know why the question is there, then why are you asking it?
• Non-technical people should not ask technical questions. This is a complete waste of my time and yours. I expect the person asking the questions to understand the questions they are asking. Going off a template is no excuse.
• As the hiring process often involves a number of different interview steps, calling me in for a face-to-face interview, knowing nothing about me apart from my resume is a waste of everyone's time. Telephone interviews serve a purpose.
• Providing feedback is critical. Expecting me to offer hours of my time, then offering no feedback will do nothing but annoy me.
• Timely follow-ups. Yes, there may be multiple interview steps. Yes, people are busy. That is no excuse for taking three or four weeks to provide feedback. In the meantime, you run the risk of losing me to another company.
• Coding tasks are great. They can give great insight into the applicant. This approach opens opportunities for paired programming as a follow up interview.
• Throwing problems at an applicant to solve on their own on whiteboard is a waste of time. Yes, you may gain insight into their problem solving skills, however this is not an indication of real world problem solving.
• If you want to see examples of my code, ask me to code a solution to a problem. Code written for another company is copyrighted, so I cannot show you it. Likewise, as coding is a group exercise, where multiple people work on a single piece of code over time, is does not indicate a particular coder's experience or skill.
• Do not ask me to come into your office to take a pen and paper test, unless I'm also doing a face-to-face interview. Find a way to get the test to me.
• Do not ask me textbook questions. If you want a walking talking textbook, hire a recent graduate. There's a good chance that I once knew the textbook answer, but too much time has passed. Instead, ask a lead in question that provides more context or offers a real world example.
• At some stage in the interview process, someone needs to site down and give me an information dump in regards to just what the job is about. Sure, I'll ask questions along the way, however, as I do not know necessarily about the company and job beforehand, please do not assume that at some point I would have asked the correct question.

What can I say about particular companies:

Google

• The questions were interesting, and required careful thought and consideration in order to provide an efficient solution. Explaining code over the phone is not straightforward however.
• For me, the difficulty in answering Google's questions, was not in not knowing what to do. I believe that the key point in answering the question is to quickly recognise the category of the question. If you do this, the answer will be much easier.
• In each Google interview task, I was given one question that was significantly more complex than all the others. This question was the clear crux of the interview. These questions were all really quite interesting and challenging to solve. At the same time, they were also a lot of fun.
• I don't care that you are Google. You shouldn't take three to four weeks to get back to me.

Atlassian

• Spending nearly half an hour discussing the obscure fallacies of Java's HashMap implementation seems a little unusual. Sure, you may use a lot of HashMaps, but this seems a bit overboard.
• I've taken the time to write sample code for you. I've taken the time to answer questions (in short essay form). The least you can do is provide feedback more than, "nothing in particular".

ThoughtWorks

• Lots of interview tasks (I went through nine in total).
• Tasks were a lot of fun ('The Logic' in particular rocked!).
• The results to my tests were lost??? I'm glad that the results were positive, but even so...
• Waiting three weeks for feedback is not good.
• Cancelling an interview when I was already onsite. Whilst this may be unavoidable in some circumstances, it was nevertheless not appreciated.