Hamstaa!

When we started having more people blogging, the first thing I did was create a blogging policy. I looked at a number of published policies from big and small companies to come up with the guidelines for Ephox. Basically it's all common sense, but a Blog Policy is a great way to ensure everyone is aware of the potential issues of blogging.

Adrian's recent post on EditLive! Dynamic being outed raised the question of how many points in our Blogging Policy were affected.

Point number 2, "Keep Secrets" seems to be the first one. The super secret project "EditLive! Dynamic" is discussed, albeit in no detail. (Bit hard when there isn't any)

Point number 3, "If in doubt, Ask" I know never happened as I'm still waiting for the "ask" part of the policy.

Finally, point number 7, "Think about the consequences" is the only one I'm sure he did follow as I'm sure Adrian was definitely aware of the consequences of his "tongue in cheek" post. He is "Chief Blogging Officer" after all

Ephox adopted eXtreme Programming (XP) at the beginning of 2006 when Doug joined the team. As part of our commitment to continuous improvement we have XP Adoption Reviews every few months. The aim of these is to review the XP practices with a view to rating our success with adoption of them. From this we choose 3 to focus on for the next few months.

In our first review, we identified Test Driven Development (TDD), Daily Stand-ups and Iteration Demos as the practices we would get the most value by focussing on.

To inject some fun into our practice focus, we introduced the "Talking Car"¹ for Stand-ups. For TDD one member of each team volunteered to be the TDD representative for the week, during the weekly retrospective. Their job was to remind the team during the stand-up that we were focussed on TDD. Finally, we made it the responsibility of the "client" to hold Iteration Demos to the business.

In our most recent XP review we have identified Root Cause Analysis, Planning Game and Weekly Iterations as the practices to focus on. We will continue to work on improving the previously identified practices, but we felt that as a team, we would gain the most value through the new practices.

The question is, how do we remind the team of our commitment to improving these practices?

Atlassian recently posted about their Agile Process and one thing they mentioned caught my attention. Chris explained that they "have practice champions for many of the more challenging practices".

I'm really interested in how we could use Practice Champions to help focus on and improve the 3 practices we have chosen. I'm hoping these champions can bring some fun and energy to the adoption process and galvanize the team behind improving some fundamental XP practices. 

1 - I'll explain the "talking car" in a future post.↩

Last week I went to the QUT Dean's Industry Working Breakfast and again it was commented that the challenge for ICT in Australia is attracting students to study IT at uni.

Interestingly, the ABC news last week also featured an article, "Research shows IT worker shortage looms" that also raised the looming shortage of ICT professionals.

As someone responsible for recruitment for the Engineering team at Ephox this concerns me when I look to how I grow the team locally. As an Australian this also concerns me if Australia is to continue to compete on the world stage in ICT, something I believe we are well suited for.

The major problem as identified by QUT's Dean appears to be attracting new students into IT related degrees.

Dr Dobson says since 2002, the overall number of enrolments in the discipline has fallen by about 20 per cent1

So what can we do about it?

I know that universities in Brisbane are actively engaging with high-school students trying to encourage them to enroll, however they need our help. When they go out to talk to students and explain the benefits of IT as a profession, the main reaction they get is "well of course you'd say that, you want us to come to your Uni". I think this is partly due to Uni's being seen more as businesses (students represent revenue) than educators and that the vision of an IT professional is sometimes seen as just the guy that fixes PCs. We can help by engaging with High Schools and showing  that there is still an active career path in ICT with a diverse range of opportunities.

It was recently suggested to me that the ICT industry needs to "market" our profession more, both to students and government. I think that if we don't, then we will find it harder to attract new staff, the costs associated with staff will increase and staff retention will become a larger issue.

1 - Taken from the ABC Article, Research shows IT worker shortage looms ↩

In the video from Sun that was posted on Atlassian's blog recently the following comment, that to me is the real power of wikis, was made.

"Publishing now belongs to the community"

I completely agree. The problem I see however is that the content authored, while mostly aimed for publishing on the web, is authored or stored as "Wiki Text". Like Doug, I'm amazed that wiki markup is not seen as "arcane" in the same way as the original layout languages. 

Prior to starting at Ephox, I introduced a simple wiki (JSPWiki) to the company I was working with. While there was some initial enthusiasm, it really didn't take off.

When I came to Ephox I again introduced the wiki to the team as I was still convinced that it was a great way to communicate and collaborate. We immediately replaced the simple text area and Wiki-markup1 with our editor and HTML. The explosion of content has been amazing. Everyone from Sales to the Office admin have authored content.

By allowing any person to create new content and edit existing content the wiki definitely puts the power of content publishing in the hands of the community. By adding the ability for the authors to create the content in a simple, user friendly and most importantly "arcane language" free way, I believe you truly give the power to publish rich content to the authors. 

1 - JSPWiki supports storage in HTML instead of Wiki-Markup.↩

At Ephox we've always had a culture of fun and doing things as a team, it's one of the things that make this a great place to work. 

We forage1 and mostly eat as a team, go to the pub Fridays for lunch, have beers at the end of the week and play alot. Along with the usual plethora of desktop toys, we have numerous "squishy toys" that are thrown around to get attention, we've played multi-user games like Unreal Tournament and brought in a Wii from time to time.

With some changes earlier in the year, kicking off development of a new product and lots of support from growing sales, we've been under a bit of stress lately and so some of these things have lapsed.

Last week Rob brought in two remote control helicopters he'd received for Fathers Day. These are about 17cm (7") long battery powered, infra-red controlled and a heap of fun to fly (though hard to control) What surprised me was how they really ignited the team. Everyone had a go and encouraged and laughed with who-ever was trying to fly. This, along with other indicators like returning to the pub has been a great sign that the stress levels are dropping. The work load hasn't diminished I might add, but the fun levels have increased.

 Many people would be concerned at how much playing around a team like us do, however what I've observed (both here an in other places I've worked) is these sorts of teams work really hard. The play is a way to blow off some steam. It's this pressure release that helps alleviate stress as well as gel the team.

1 - Go out and find something for lunch.↩

I was reading an article by Jean Tabaka on the 11 Ways Agile Adoptions Fail and her number 5 reason "Product Owner is Consistently Unavailable" hit a cord. In it she states

An unavailable product owner perpetuates the wait time and creates waste

Having experienced this in the past, I can't agree more. 

At Ephox our Product Manager plays the role of client in our iterations. As part of his role he spends a certain amount of time travelling. In the past we tried to continue development while he was away. What we found was that, even though he was available via email and phone, his lack of availability within the office while a feature was development caused delays and in some cases wasted work.

The way we've dealt with this, especially with an increase in Product Managers recently, was to have agreement that, as the client, if you were not available your development release would stop at the end of the iteration. The team would then work on stories in the next iteration for the other product manager or spend time on process improvements within the Engineering team.

A few posts ago I talked about competency versus capability and recently I've seen a few posts supporting my assertion that the "tick in the box" approach to hiring isn't going to guarantee you get capable people.

Dan Creswell posted a great article in response to the job ad for a Senior Research Engineer at Amazon. 

So often I see companies create job specs for engineers where the key requirement is to hire someone who can hit the deck coding like mad using whatever tools have been selected. To that end they load the specs up with endless tech hubris and at interview ask the details of this or that bit of syntax or API call.

Frank Wiles continued the theme in his post on "A Guide to Hiring Programmers" where he identified  

You don't need to hire an expert in language X, you can and should look for expert programmers that are willing to learn language X. An expert can easily cross over from being a novice in any language in a matter of a few weeks.

If you are hiring solely on technical skills then, as Dan Creswell asks, "what about the next project within the company where the tech is different?". This is where capability wins over competence for me.

Having ways to judge the capability of potential hires in the interview process is crucial to successfully hiring people who can grow and evolve with your business. Ideally you don't want to have to hire a complete set of new developers if you change technology. The current ones know your business and will appreciate the opportunity to develop new skills, thus adding to company loyalty and retention. 

At Ephox, as part of our recruitment process, we have people undertake a coding exercise. This is a very simple program that the candidate can do at their leisure to allow them to fit it into their current commitments. Most importantly we allow them to develop it in their preferred language and tools. Once it's submitted back to us and reviewed by senior engineers, we invited the candidate back for a frank discussion on their thinking during the development process.

What are we trying to achieve? We are looking for how they approach problems and how they interact in a technical discussion. Basically all the things that indicate their capability for the role versus their proficiency with a particular technology stack.

We've already seen this approach work with our last hire. Suneth had only basic Java skills prior to joining us but when we evaluated his ability we could see the potential and an eagerness to learn more. In the 12 months since Suneth joined us his skills in Java have increased immensely.

How do others evaluate the capabilities of their candidates during the interview process?

You will often hear the terms "People Independence" or "Institutional Memory" used as a management reason for the creation of the huge volumes of paperwork often created in a BDUF (Big Design Up Front) project. The idea of course is that the presence of the documentation allows the organisation to use developers interchangeably.

For developers, documentation is extremely useful for the those who come after, even if it's you in 12 months time. This documentation however is only useful if it's up-to-date. Unfortunately in most cases it's written, read and never looked at again.

When I was consulting, and prior to my introduction to Agile practices, I often worked with organisations that didn't particularly want to spend time on documentation. This wasn't because they believed it wasn't useful, it was more a cost saving method. Still wanting to provide future developers some form of documentation I became an advocate for heavy commenting of code. Hence, the code became the documentation. 

With my introduction to Agile practices a few years ago the idea of "documentation in the code" has moved on to incorporate and focus on atomic tests. The application of the concept of waste from Lean Software Development on formal documentation also supports the use of atomic tests as documentation (unless the documentation provides some other value than the fulfillment of the process).

So does code (test cases) as a replacement for formal documentation meet the requirements of managers who are looking for "People Independence"? It does if they are looking for a way to fulfill the need to pass on knowledge to future developers. In addition the added benefits of atomic test on quality and confidence for future developers to make changes and maintain current functionality is immeasurable.

Continuing the "Growing Team Leaders" course, last week Greg Stockwell of Public Speaking Australia presented "Public Speaking and Presentation Skills".

Unlike the previous sessions, this session was presented as a series of exercises where Greg introduced a few simple techniques for dealing with the obvious nerves of speaking. Interestingly when you hear people say they don't get nervous when speaking, this can sometimes mean they are overconfident. This overconfidence comes across to the audience as disingenuous.

Greg also presented a few simple rules when speaking publicly. For example

• never tell the audience you're nervous, they'll focus on looking for the signs of nerves instead of the substance of your presentation
• if showing a video, tell them how long it is so they know what to expect
• if possible, see the venue before you speak so you have a sense of the layout and reduce the unexpected
• finally, be yourself, don't try to be something you aren't.

I think the point I really liked, that Greg made, regarding public speaking is

It's not life or death, it's only public speaking.

How do you view and hence refer to the people who buy your software or services? As Customers or Clients?

While it sounds like a simple case of semantics, it is a significant change in how you look upon them and how you treat them.

To explain the difference, consider the following analogy.

We refer to the doctor, lawyer and accountant we use as "My Doctor", "My Lawyer" and "My Accountant" but we never refer to the shopping centre we go to as "My Shopping centre" . It's referred to as "The Shopping Centre".

A customer is someone who you don't build a relationship with. You don't necessarily gain repeat business with. They are someone who can easily switch to a different product (shopping centre)

With the subtle shift to considering them as Clients, you are focussed more on working with them, finding solutions to their problems and gaining their appreciation and repeat business.