Hamstaa!

So you’ve got talented people and as we all know, you need to invest in maintaining those skills. While there are a lot of ways you can do this, some of which are quite expensive, sometimes the little things have the biggest impact.

At Ephox we have a good collection of technical books and I’m always looking for new ones to add. It was suggested that we should get a copy of “Head First Design Patterns”. As the Head First series are designed to be written in, I purchased a copy for each member of the team. 

I was sure it was a good decision when the day after they arrived one of the team stopped me to tell me how good it was. This was quickly followed up by one of my senior engineers raving about how easy and compelling it was to read. Finally, one of the team rang me on the weekend prior to their week of leave to confirm they could write in the book, as they were really getting into it.

So, if you want a low cost form of training, don’t just buy books for your team library, but actually give them their own copies.

Andy recently pointed me at an interesting article, “The Paper Version of the Web” that shows some great examples of UI designs sketched on paper. In the article Sean collects together some of the publicly available UI sketches for well known websites like Flickr and Twitter.

At Ephox, we have quite a lot of UI design required and as such we’ve tried a few different things from quick Java mock-ups to Photoshopped images. To me however the best solution is the paper sketch. Why, well other than it being pretty cheap to develop and modify, anyone can do it, including the “client”. Finally, there’s also no chance you will be tempted to use the “prototype/mockup” as the basis for the final version.

At Ephox we introduced the concept of Creative Coding Afternoons (or CCA) back in 2006 based loosely on the Atlassian and Jotspot Hackathons. Occuring Friday afternoon every 2 weeks, the original idea was to develop plugins for our editor based on the public APIs. Essentially do things that our clients could do. The best of these were posted on our LiveWorks! site as freely downloadable components.

Our CCAs are evolving into more advanced research that resemble 20% time, with projects spanning many CCAs. So when Atlassian announced it was going to emulate the Google’s 20% time model I was keen to see how it worked out for them.

It was with interested then that I read the recent followup on the progress over the last 10 weeks. In the post Charles reflected on their progress to date with a series of questions put to the developers.

The one I was most interested in was “How much time have you had to work on it?”. Charles summarised the responses by saying

almost all the responses were in the 2-3 day mark, and none higher.

This is closer to 4-6% for the 10 weeks they’ve been going than 20%. Why is this low?

In theory, saying to developers you can devote 20% of your time to do research/personal projects should result in 20% time being spent. The problem, as I see it, is that most project are on tight deadlines, and developers are committed to completing those project related tasks. A fact that seems to be borne out by the following response 

 …the biggest problem for developers finding time to work on their projects was fitting it around their scheduled work

So what’s the real problem? Well your projects are planned but no time is set aside in the schedule for 20% time activities. When your developers start working on 20% time, the schedule starts to slip, eating into “buffer” time. If the features then require that buffer time, how does the project manager deal with it? Easy, cancel 20% time.

How do we deal with this? The answer I think lies in a response to the question “if you could improve 20% time in any way, how would you?” 

“Mandate that particpants (sic) have to spend 2 days a fortnight on it, otherwise it's difficult to keep the pace up to 20%”

So, when planning a project, not only do we need to put aside time for feature overruns, but also time to accommodate 20% time. Again, all good in theory but at the end of the day, as a product company, we need to deliver product. The trick is to balance the successful delivery of new releases with the obvious benefits that can come from 20% time. 

I’ll be very interested in how Atlassian handles this over the remainder of their trial.

With Ephox’s recent sales growth we are expanding the R&D team and are currently looking for two outstanding Java developers to join the team in our Brisbane office.

We develop in both Swing and J2EE using agile techniques and have a set of values based on the XP values. We have a fun workplace and are looking for the right people to join us.

This is a great opportunity for someone who wants a fulfilling and rewarding position that takes their careers to the next level.

If you are interested, the job has been released on Seek.com, so check it out and apply.

It's been exactly a year since I started blogging and so I thought it would be good to reflect on my experience so far.

When I set out, I wanted a means to communicate my experience as a manager to anyone considering the move. I've continued to keep the primary focus of my articles to management and leadership, however there has been the odd time when I could have blogged about other areas. This is something I think I'll do in the future.

I haven't received alot of feedback on my articles but that's not surprising considering how little readership I have and how many posts I've made. I did however receive some great feedback at a business event from Karl, the presenter of a session on the leadership course I undertook last year. He complimented me on my post Capability versus Competence and said he regularly points people at it when explaining the differences.

The one problem I do find is that I start an entry, get caught up in something else and don't get back to it for ages. In some cases, it is then too late to be relevant. 

The main thing I think I need to take away from all of this experience so far is that "the publish button isn't as scary as it looks" and I just need to publish those articles that end up in draft.

So my "new years" resolution is to publish more often.

As part of our interview process for new engineers at Ephox the final stage is the Coffee Interview.

The Coffee Interview involves everyone in the the team, except the manager, going out with the potential hire and having a coffee. While discussions can be technical, it's not a technical interview but rather a chance for everyone involved to get to know each other. At the end of the coffee I get consensus from the team as to whether we should hire the person or not.

What we are trying to do in this interview is determine if the team can work with the person, and the person can work with the team. It's a case of ensuring the hire is a good "fit".

By involving everyone the person will work with, we are essentially building an emotional contract between the team and the new hire. These people are the ones who can exert the most influence over the success of the new hire and as such, the Coffee Interview provides a way to invest them in the success of the person.

Over the last year I've been working on building better relationships with our local universities. I see this serving two purposes. Firstly, it provides an avenue for promoting Ephox and subsequently using this self-promotion as a means to attract high quality staff. Secondly, it is a way to give back to the industry and help attract more people into IT.

So as part of this outreach, I jumped at the opportunity to present as a guest lecturer at QUT recently. The subject, Core Project Management, has provision for guest lecturers so we took up the offer to present two lectures.

Damien presented last week on the topic of requirements gathering in a product company and yesterday I presented the differences in project management between a product company and a project (professional services) company.

It was the first time I'd given a lecture so it was a little daunting initially. Once I got started and found my groove, it all flowed together nicely. Unfortunately I had little feedback from the students on how useful they found what I presented. The lecturer however seemed happy with both the clarity and topic. Overall I'm happy with how it went and look forward to other opportunities to speak.

I was recently introduced to TED or Technology, Entertainment and Design. If you haven't heard of it, it's well worth checking out. Their by-line is "Inspired talks by the world's greatest thinkers and doers" and the site has videos of presentations from past conferences.

When I first became interested in hackers and computer security many years ago, the first book I read was "The Cuckoos Egg" by Clifford Stoll. Clifford is the astronomer who back in the late 80's while working at Berkeley noticed the intrusion and ultimately helped capture the hacker working for the KGB .

Clifford appeared at the 2006 TED conference and the video "18 minutes with an agile mind" is now available.

Watching it, Clifford exudes a huge amount of energy and passion for his topics and this energy is infectious. So if you have a few minutes, check it out.

I was reading an article, "Cultivate Commitment" by Julia Stirling, in The Weekend Australian recently that resonated with my belief that management and leadership is about people. The focus of the article was on employee commitment and the part management plays on the level of commitment.

Keeping employees engaged is one of the biggest challenges for managers. Happy people are productive people, and research suggests relationships are the biggest single determinant of productivity within a group.

There are three levels of employee commitment identified in the article; Engaged, Not Engaged and Actively Disengaged. The level we should be striving to cultivate as managers is the Engaged employee. Engaged employees work with passion, feel a profound connection to their company, drive innovation and move the organisation forward.

What was disappointing to read was the percentage of people that are Actively Disengaged versus Engaged. Only around 10% of employees are Engaged with over 50% at the Actively Disengaged level.

Michael Mere, an educational consultant with Swinburne Industry Solutions says

"The poor levels of employee engagement show how much 20th-century management theory and practices are failing today. Emphasis on obedience, diligence and even thinking are no longer delivering competitive advantage. In the 21st century, what you need to be competitive is a workforce that is using its initiative, is committed to the organisation and is passionate about what it does."

As a manager, we have the most influence over the level of commitment our employees have. What is interesting is that relationships are a major part of this influence. There are two major reasons identified by Mere for why people become disengaged. These are:

dysfunctional relationships (particularly with their immediate supervisor/manager and within their work group), and failure, real of perceived, of the organisation to fulfil an obligation or expectation

Over the years, I've occasionally found myself in situations where promises where made that were never kept and as such I found myself becoming "Not Engaged". I left very soon after.

Because of these experiences, something I've strived very hard to do since I moved into management is to meet the promises I make with my team. I've also worked at cultivating a good working relationship with everyone I work with.

So why do managers have problems with building relationships within their teams? Mere says that the

Lack of emotional maturity in supervisors and leaders is a major contributor to disengagement

Interestingly, this emotional intelligence is not a contributing factor in the promotion of people to a management role, despite how important it is in building and maintaining an Engaged team.

One of the basic principles of XP is to provide value. To achieve this ,you do the stories first that bring the most value. Now if those stories are risky or big, then you want to fail fast and move on. However in software development, most things are possible…it's just a matter of time. So how do you fail?

At Ephox we are extremely good at making the impossible possible, just take a look at EditLive!. The things we did in the early days were not possible with the limitations of the Java APIs, so we found a way around them. As such, it is possible to continue with a feature beyond the current return on investment of the feature.

What we need to do is find a way of identifying when to stop the investment in a given feature, mark it as "failed" and move onto the next most valuable feature. To do this however, you need to know what are the conditions by which you define something as having failed.

We recently moved to a tri-estimate approach¹ where all stories include a Best case, Worst case and Most Likely estimate. These estimates not only give us an indication of the risk associated with a feature, but also a basis by which to determine "failure".

My framework for "failing" a story is as follows. Once we hit the Most Likely estimate, we re-evaluate the Worst Case estimate with the knowledge gained so far. Assuming the revised Worst case is an acceptable investment in the feature, the new value is then considered the "line in the sand". Once we hit the Worst Case estimate, we review, asking how much longer to go to completion. If the time to go is acceptable, then this is the "failure" time. Once that time has expired, the story fails.

So, for example, figures of 20 and 40hrs are given for Most Likely and Worst Case estimates respectively. At 20hrs, the team revises the Worst Case to 45hrs. It is accepted that the features value is worth 45hrs, and development continues. At 45hrs, the team says there is an additional 3 hrs to go to completion. This final amount of effort is short enough that development continues for the 3 additional hours. At the end of that time, we "fail" the story if it's not completed.

Now of course, there are exceptions to this,  but the aim is to identify when a feature is just going to keep going and stop it.  

1 - Doug discussed the idea in his article Estimations - Best, Expected and Worst ↩