Hamstaa!

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 ↩

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.

At the final, for 2007, QUT Dean's Industry Working Breakfast last week I found myself discussing the disturbing trend in the decline in IT enrolments with Bobby Barnett, a secondary school IT teacher at John  Paul College. 

We talked about the fact that kids today¹ are so comfortable with technology. They use it voraciously and for so many purposes, so why is it that we haven't seen an increase in IT enrolments. It seems that while they are more than happy to use technology, they aren't fired up with the idea of creating it. 

As Bobby put it,

They want to drive the car, but aren't interested in building it.

I find it odd that there is a perception that, while using the technology is fun, designing and building it isn't it. 

I love motorcycles, so to me, the passion with which they are designed is evident in the form and function of the bikes. You can't tell me that the designers of the latest Ducati 1098 or the MV Agusta F4 don't have the same passion for riding as they do for design. 

Similarly, the developers of the iPhone or Facebook I'm sure were equally passionate about the design and development as they are in the utilisation of the final product.

The real challenge appears to me to be, how do we show potential IT students the challenges and opportunities in the development of  technology? How do we fire up their desire to develop new technology and applications to the same level as their passion in consuming them?

1 - I suddenly feel old. ↩

Suneth attended QCon last week and in his post "The Great Convergence" he summarises Kent Becks comments on "the great convergence of Business Trends and Developing Trends in the IT world". 

I totally agree with the view that today's developers require far more social and people skills than evidenced in the traditional view people have of the developer. I also think that the Agile practices help focus a development team on the needs of the client and hence force engagement with the business users, resulting in the need for and development of these skills.

Where Suneth and I depart in our views however is in his assumption that technical skills don't matter for a developer. His assertion that

Anyone with a healthy brain can learn any programming language and write good code with some guidance and practice. But it is not easy to train someone to behave a certain way or teach some values like being positive or working as a team. 

I think misses the fundamental training in Software design that engineers gain during their degree. There is a big difference between "Programming Skills" and "Language Knowledge". To borrow from Dylan's comment to Suneth's post 

There is [the] art of developing quality software - a strong degree of craftsmanship involved, which separates code-monkeys from true engineers.

I also think that Suneth sells himself short in his comment that

… technical skills of a programmer should not be the main requirement while hiring. For example, prior joining Ephox, I was a .NET developer.

I'd disagree with Suneth suggesting he didn't have the technical skills of a programmer, we wouldn't have hired him if he didn't. What Suneth lacked was commercial experience in our language of choice, Java, but his technical skills in developing quality software were evident and why we hired him.

As a manager, when I'm looking for new recuits I'm evaluating the whole package, social and technical and weighting them equally. In the interview process, the face to face covers the social, and the programming exercise covers the technical. In one way we differ from the traditional though in that our programming exercise doesn't require the canidate to program in Java. It's their analysis, design and development skills and philosophies we are interested.

I was having lunch with Adrian recently and we were talking about how people work with email. One thing he said made me stop and think about the different ways people treat email and the potential problems that can occur if they aren't aware of the differences.

What he said was, "e-mail is a conversation, not a considered media".

Now some people treat e-mail as a "considered media", I must admit I'm one of them. When I put together either a response to an e-mail or create a new email, I spend time crafting it and reviewing it before I send it. In a few cases, the people I send them too are "email conversationalists" and so I regularly get short responses that don't always address my entire e-mail. 

This reminded me of the Myers-Briggs "E" versus "I" categorisation and the confusion that can occur when they interact unknowingly.

'E' types tend to think by talking, whereas 'I' people tend to think then speak. As such, when an 'E' is talking to an 'I', the 'E' is looking for the type of feedback they would give that they understand. As the 'I' internalises this feedback, it is possible for the 'E' to continue way past the point the 'I' understood, causing frustration on both behalfs.

Understanding this makes for significantly more useful conversations between the two types.

So what happens when a person who treats email as a considered media gets a quick response from someone who doesn't. Well it's possible they read more into the response than was intended and hence draw the wrong conclusions. Alternatively, they get frustrated that not all of their questions were answered.

Equally, the other party can get frustrated with the "long" email and so skims, possibly missing important information or questions.

Next time you receive an email, consider the approach the person sending it may have taken and engage in the conversation appropriately.

In the final session of the ACS "Growing Team Leaders" course I started back in May was held last week, we attended a breakfast with some guest presenters giving insight into leadership. We heard from

• Peter Grant, CIO of Queensland Health
• Anne-Marie Birkill, CEO of ILAB
• John Puttick, Chairman of GBST Holdings

As seen in so many other parts of this series, the common theme was the value of people and of course how to inspire them to greatness.

Peter talked about his, now departed, mentor and friend, the university lecturer who fired him with passion for IT. Not only did his mentor introduce him the world of IT, but also taught him the value of being skilled in all areas, not just those you find interesting.

Anne-Marie talked about taking a leadership role in the (ICT) community by giving something back to it. It was interesting to hear, not only from a successful woman¹ and how she got there, but from someone who is in a field not directly involved in IT.

Finally John, talked about his early years and the power of IT in business. John as part of Software Queensland is partly responsible for the creation of the ACS course.

While each presenter had some great things to say, for me, it was Peters comments that spoke to me the most. Peter struck me as a person who understands fully the value of people and providing them with the tools necessary to do great things.

After the breakfast, we convened once more for a final wrap up. This finished with everyone committing to doing something towards growing their leadership skills. For me, I've chosen to embrace the opportunity of representing Ephox at Software Queensland and to work with our local Universities in growing the numbers of students studying ICT.

Discussions with the people at my table indicated that they had all taken something valuable away from the course. It's been an interesting and insightful series, with some very useful gems of knowledge. I'm very glad to have been a part of it.

1 - We need far more women in IT.↩

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