QCon Beijing 2009 and Agile Hong Kong event

QCon Beijing 2009 finished. I also did the presentation at Agile Hong Kong event. Both of them are really nice gatherings.

QCon Beijing 2009 is a huge success. They managed to attract many people from China to attend the event. I was luckily invited to be one of their speaker. It's very nervous for me as this is the first time I present in Mandarin in such a big and open event.

Can I do better in the presentation? Of course!

  • I believe I would better present in English. Among the suggestions I received, the best one is "Speaking English and add some Mandarin in certain point of the presentation". This gave surprise elements for those who thought I don't really speak Mandarin.
  • Better Mandarin on the technical terms. I believe my Mandarin conversations is rather fluent. But when it comes to technical terms, I usually need to speak in English, or I shall stick to this? :)
  • Content of presentation, understand the audience is the hard part. With such a big event, people have varing degree of understanding of Agile. To my surprise, some feedback said the topic is too simple. I believe I could add more advanced topics in the presentation, while I thought there would be others complaining that is too difficult.
  • Practical sessions - this is the best feedback I recieved! I can see two potential practical ideas:
    • Looking at the source code and see how actually it works
    • Do a demo and run thru the process
Any recommendation for QCon Beijing? Certainly, I believe meals can be better arranged. Also it is too bad that the package only include two days in the hotel while theis is a three day event!

Back in Agile Hong Kong, the presentation was a lot smoother :) at least this is the second time I presented the topic and I was presenting in English. This is a rather small and close group. There is more interaction. Again, I was asked to go thru the more technical details on Robot and FIT. I believe it would be better if I prepared better on this, except I got sick just before the day.

For those who missed my presentation, here you go :)

Share with:

Coaching at Hangzhou

Spent two weeks coaching in Hangzhou. It was an enjoyable trip. The enjoyable element of coaching was that I can see developers improving their way to work, while I also learned from them by observing and discussing.

What did I learn from this coaching?
  • Keep refactoring
  • Insist having tests in place before coding
  • Keep myself in good condition
  • Keep learning
Anything I can do better? Certainly there are ...
  • Better revision and preparation on the contents of coaching
  • Speak more
  • Better understanding of the project/products they are working on
Look forward to having the next coaching task :)

Share with:

Here comes QCon Beijing 2009!

QCon finally arrives Beijing and Tokyo! QCon Beijing will be held on 7-Apr-2009 to 9-Apr-2009. For those who are not familiar with QCon. QCon Enterprise Software Development Conference is organised by InfoQ and designed with the technical depth and enterprise focus of interest to technical team leads, architects, and project managers.The conference will be organised in 6 tracks:

  • Enterprise Java Development
  • Agile - On the way
  • Cloud Computing - The next generation architecture
  • Case Study - Case study of website architecture
  • Architecture - Designing good architecture
  • Rich Internet Applications - RIA 
Most of the speakers have been confirmed:
  • Rod Johnson —— Creater of Spring
  • Martin Fowler —— Loud Mouth on Object Design
  • Randy Shoup —— Distinguished Architect in the eBay Marketplace Architecture group
  • Jeff Bar—— Lead Web Services Evangelist at Amazon.com
  • Dylan Shiemann —— Dojo toolkit co-founder and committer
  • Henrik Kniberg —— Author of <Scrum and XP from the Trenches>
  • Floyd Marinescu ——Co-founder & Chief Editor of InfoQ.com
  • 毛新生—— IBM中国开发中心Web 2.0首席架构师
  • 李伟 —— 西门子中国研究院软件与工程中心首席系统架构咨询顾问
  • 周爱民 —— 《大道至简》和JS语言精粹等图书作者,盛大前高级架构师
  • 高焕堂 —— 台湾软件架构设计大师,“台湾OO技术教父级代表人物”
  • 洪强宁 —— 豆瓣网 (Douban) 技术总监
  • 程立 —— 支付宝 (Alipay) 首席架构师
  • 周代兵 —— 华为软件公司 (Huawei) 软件工程部总监
  • 于晶纯 —— Freewheel创始人/CTO,DoubleClick前工程部副总裁
  • 邵荣 —— 群硕软件 (Augmentum) 的资深技术总监
  • 林昊 —— OSGi China User Group负责人,淘宝网 (Taobao)平台架构师
  • Steven Mak (that's me!) —— Agile Coach at Odd-e,Editor of the Agile community at InfoQ China
(As the original content comes with Chinese version only, I don't have the English information available for some of the speakers. Company names in English are added for some of them above)

The venue is located in Tsinghua Science Park. Early bird ticket price (before 15-Mar) will be RMB2100, saving 700RMB. You can register at the QCon Beijing website.

Share with:

Risk Management for Agile Projects Again

I wrote about Risk Management with Scrum not long ago. I re-visit this topic again as a translation assignment for InfoQ. There are some new interesting points as well as old but important points.

The more interesting input is from James Shore. He suggested the use "Risk Multiplier" as a way to make solid commitments.

There are a number of issues behind this approach:

  • The meaning of "solid commitment", how would these solid commitments be used and interpreted by the users? It is meaningless if this were taken as argument points in case if the team could not make it. Afterall, this is merely probability. What would be the difference between we would try to finish 140 story points or we would try to finish 78 points?
  • How do these multipliers came from? James Shore has this line on this: "I'm guessing somewhat at how accurately they apply to XP. The most accurate approach is to calculate your own risk multipliers from past project history, but most companies don't track that data". So, in my opinion, don't take these as magic numbers.
  • Following the points above, if we have to collect that data for the purpose of giving such commitments, is it for the best of the benefits with the customers? What could justify the customer or product owner to invest money and time for the team to do these statistics? More importantly, how do customers and product owners know they get positive return for what they invested to the team on these activities?
  • Possible decrease in velocity, imagine the team begin with suggesting possible of 140 story points for 10 iterations, and "commit" 78 points. Since the remaining points are only "extended goals" or even impossible, the team could be happy for finishing 78 points, and get slower for the remaining stories.
With these issues above, I wonder how practical the "Risk Multiplier" would be useful. Iterative development, by nature, enables the development team and product owner to "inspect and adapt" to what happens at that moment. Making commitments far too early easily gives product owners neglect on "Inspect and adapt" nature and rather expect what is "committed" 10 iterations ago. This, in turn, defeated the risk management nature of iterative development.

As I read about Agile over these years, I found there are more and more attempts to add new things to Agile. However, the best of the ideas is always the original steps of Agile, the Agile Manifesto and the Principles.

Share with:

First Scrum China Gathering

This is the first Scrum gathering in China. It provides a very good opportunity for practitioners to gather and discuss on different issues with Scrum implementation.

As with what I have mentioned at InfoQ. Most of the issues are rather elementary. Here's some questions I heard in the gathering:

  • How to encourage the team to speak up?
  • What happens if the Product Owner said everything is important?
  • How to manage a team of part time workers?
  • Leadership for Agile
  • How to implement Scrum?
  • How to make an Agile contract?
I knew that there are people criticised on questions and topics raised by certain participants for being not in depth enough, or some didn't even make much sense.

However, I always enjoy Ken Schwaber's saying of "Scrum works with Idiots too". Let's recall that quote:

"Scrum works with idiots.  You can take a group of idiots, that maybe didn’t even go to school, don’t understand computer science, don’t understand software engineering techniques, hate each other, don’t understand the business domains, have lousy engineering tools and uniformly, they will produce “crap” every increment.  This is good!"

Certainly I don't want to imply those who asked questions which didn't make much sense are idiots. But it's good since this revealed the current situation of the profession. And I believe, with such collaboration events, people can easily exchange ideas and get better insights from the more experienced people in the event. So I believe the event should be good for them too.

Although it seems the participants did not have much idea about Scrum, I think it is the same for everything gaining adoption in any place. There would always be a stage where some people are still picking up and having difficulties understanding the concepts behind.

So, don't worry, and hope to see you in Scrum China Gathering in 2009!

Share with: