Hamstaa!

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.

Before Easter, on a visit from the States, Andrew (the CEO) restructured the engineering team by moving two of the senior engineers into product management roles. The aim of this restructure for the business is to bring a dedicated focus into building successful products to the product development part of the company. Andrew has discussed some of his reasoning behind the change in "Organizing for Innovation (Part 1) - Why?" 

While talking about the proposed change and how it would affect my team as well as myself, my wife Helen reminded me of a book I'd read many years ago. Who Moved My Cheese by Dr Johnson talks about how change affects people. Presented in the form of a parable, it features "Sniff & Scurry" and "Hem & Haw" whose cheese one day disappears. As Haw goes through the process of finding "new cheese", he provides insights into how to handle change in a series of "writings on the wall". The following one

Enjoy Change! - Savor the adventures and enjoy the taste of new cheese!

got me thinking about what opportunities the restructure would bring.

Opportunities for the team

On of the problems we've struggled with in engineering as we adopted XP was the availability of a "client" who was also trying to plan new products. This change has effectively removed this bottleneck and allowed us to focus on ensuring we delivering value to our clients with each release.

In addition, as our acknowledged guru Adrian has now moved out of direct development, like a tree falling in the forest, it has cleared the area to allow the other engineers to shine. One of these, Andy, has already seen the opportunities for him as he discusses in his article "Big Changes at Ephox".

Opportunities for Me

When I started at Ephox, I had basic management skills and so focussed on building up those skills to meet the new challenge of engineering management. In the meantime, I let my technical skills get blunt. In recent months I had reached a state of balance with my management skills so I had been looking to resharpen my technical skills. This change has provided me the focus on what skills I need to work on as I dive into the development vacuum caused by less resources.

In addition, it has provided the additional management challenges of building up the engineering resources again, managing the requests for the limited resources from 6 different people and maintaining the mental well being of my team as they meet the challenge of less senior colleagues.

Change happens, it's how we react to change that determines how it affects us. With the exception of change for change sake, change brings opportunities. The challenge is to recognise this, identify the opportunities, and "savour the adventure" they present.

Like most engineers I thought management was the "dark side" but was something that, as your career progressed, couldn't be avoided. After 13 years of development and technical consulting, I was offered the opportunity to see what it was like in management, while still requiring me to maintain my technical skills at an architectural level.

I've been the Engineering Manager at Ephox now for 2 and a half years and have found that I really enjoy what I do. I've learnt alot and grown my team both in numbers and professionally. Most importantly we produce some amazing code while having alot of fun.

Why am I blogging? Blogging for me serves a number of purposes.

• At a corporate level, it provides me with a forum to show prospective engineers what it's like to work with us and have me as a manager.
• At a professional level it gives me the opportunity to help other new managers and dispel the engineering myth of management being "the dark side" by providing an insight into what is involved in Engineering management.
• At a personal level it's a place to keep notes and comments on things "management" and to grow the brand that is "Brett Henderson, Engineering Manager".

So welcome to my blog. If you're an engineer who like me thought management was an evil necessity, or are new to management come on a journey with me. If you're an experienced manager I'd welcome your comments and advice.