Hamstaa!

On the 1st of February my mother lost her battle with cancer. For nearly 2 years my family has lived with the knowledge this day would come, but it is still hard when it does.

The support I have received in the last 2 years from all the people at Ephox has been amazing. This was especially noticeable in the week leading up to and after her passing. No questions were asked when I pulled out of my recent trip to the US half-way through to rush home to spend the last week I could with mum. I knew that, like when mum was first diagnosed, I didn't have to worry about anything while away. The guys in the Brisbane office got on with doing what they do best and the executive team deferred non-critical things until I got back. I also received emails of support and condolences from everyone from the engineers I work with through to the CEO and head of the Board.

It's this kind of support that can make all the difference in situations like this. So to everyone in Ephox I'd like to say thank you. Your understanding during all of this has been greatly appreciated by my family and I.

No, the Ephox Talking Car isn't some new form of Kitt from Knight Rider … showing my age there. The Talking Car is a token we are using during our stand-ups to not only indicate who's turn it is to speak, but to remind the speaker of what the 3 main points to discuss are.

As I mentioned in my recent post on "XP Practice Champions", in our first XP Adoption review we identified stand-ups as a practice to focus on and improve. The introduction of the "Talking Car" was one of the ways we focussed on improving stand-ups. So how is it used? In our case, the car is tossed to someone randomly, that person then talks about the following What they did yesterday What they plan to do today Any issues before tossing it to someone else in the group.

As part of our continuous improvement, we recently reviewed our stand-up and decided it needed to be more story focussed. So the new list of topics are

1. Done Stories
2. Not Done Stories
3. Today's Stories

With this list, we can address why a story wasn't completed, what we can do to complete it, advise the client of the delays and continue to communicate to the entire team what is being worked on. 

By focussing on successful story completion and communication of progress to the client  hopefully this will also help with our improvements to Weekly Iterations.

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.↩

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.

Yesterday I had the opportunity to hear Alan Noble, Engineering Director for Google Australia/New Zealand present on how they are tackling Google's expansion. While there were many interesting facts (for example, Google receives 12 resumes every second) and insights (like Google's approach to products, "Build it and see if people use it"), the one that I found interesting is regarding Branding.

We all know the value of and hence focus on building our companies brand. In today's environment, it needs to be dynamic, exciting and have "sizzle", as they say. When it comes to recruitment however, we tend to have a bland, boring, "check list" approach. Alan highlighted the obvious issues with this when trying to recruit highly talented professionals, especially "Generation-Y". On the one hand you represent a dynamic exciting work place, on the other your recruitment message says the opposite.

As Engineering Managers, I see it as part of our job to build "brand awareness" of our engineering team. This can include involvement with universities and the local technical community but it's also important to consider what message we are giving when we advertise for positions. 

At Ephox we have a team of outstanding developers working on the edge of technology. They work hard as a team and have a heap of fun doing it. It's this kind of message I want to get across when building awareness of our technical team, but it is also important to get this across when we advertise for new team members.

Like many tech companies, we support our employees blogging, so it was great to see that Suneth has joined the growing number of people at Ephox that blog.

Suneth is the constant in our support team. He is forever looking for ways to improve the experience our clients have when they come to support. His formula for support in his first post, "Life in Ephox" illustrates this dedication.

I look forward to seeing where Suneth takes his blog. I'm sure there will be some interesting insights into providing outstanding support. He is definitely an "important fish in the small pond!"

One thing I've strived to maintain as engineering has grown, is the involvement of engineers in support. Why? Andy hit the nail on the head with his recent post on "All of our developers start in support". In it he said, 

You can’t get a good feel for what customers want when you’re sitting behind your IDE listening to product managers.  Only on the front lines can you hope to understand what people want to do with your product and how you can make it better.

Too often in product companies, engineering and support are two separate groups. The biggest problem with this is that the people developing the software have no real feel for what the end-users are experiencing.

Engineering can come up with great solutions that, when released into the wild, are not entirely practical for clients to use. By being part of the support team, even if only for a few months, engineers gain greater understanding of the pain clients may be going through. They can then develop great ideas on how to introduce small enhancements that really help our clients.

As such, it's now policy that when you join the engineering team you spend some time in support and regularly cycle back into support for short periods. It keeps you focussed on solving clients problems.