All I know about dog is ...

Noobs vs Experts

2010-02-10T21:37:00.004+11:00

Inspired by the conversation with my colleague Jason.

Evil Marketer

2009-12-02T11:53:00.009+11:00

My friend Ryan needed me to confirm he was answering correctly to avoid any future spam while subscribing to a reputable papar magazine online. Snap!

You may need to click on the image to read the text at the bottom

Book Summary: Waltzing with Bears Part II

2008-09-19T11:55:00.000+10:00

Risk Diagram

x-axis: dates
y-axis: relative probability

Nano-Percent Date (N)

the first date that has a nonzero probability (nano-percent likely)
on software industry average, window size is somewhere between 150-200% of N

Mechanics of Risk Management

yesterdays' problem is today's risk - initially add the project retrospective results of previous projects
Risk management is not the same as worrying about your project
Some risks expire during the course of a project. By the end of the project, all the remaining risks expire.

What to do about a Risk

avoid: don't do the project
contain: set aside sufficient time and money to pay for it, should it materialise (risk reserve)
mitigate: take steps before-hand in order to reduce containment costs
evade: do nothing and the risk doesn't materialise

Risk Exposure

expectation of containment cost
risk exposure = cost x probability
risk exposure can be expressed in terms of time of expected delay

Showstoppers

can only be managed by project assumptions
should any one of the project assumptions prove false, have to escalate the issue upwards
showstoppers are beyond the responsibility and authority of the project

Risk Management Prescription

compile a census of risks using a risk-discovery process
make sure all core risks are present
do homework on each risk

name and id
transition indicator
estimate impact (cost & schedule) & probability
calculate risk exposure (budget & schedule)
determine contingency actions & mitigation actions
add mitigation actions to project plan

designate showstoppers as project assumptions
determine nano-percent date (first-pass schedule estimate)
construct a risk diagram using N date
express all commitments using risk diagrams showing the uncertainty
monitor all risks for materialisation & expiration and execute contingency plan if required
keep the risk-discovery process going

Commitments and Goals

schedule = goal = N => stupid
schedule > goal > N => sensible

Public Risk Management

keeps all eyes on the core risks
enables all to engage in the ongoing risk-discovery process

Simplicity

2008-08-11T14:50:00.001+10:00

Excellence through Simplicity

- Lao Tzu

Book Summary: The Elegant Solution

2008-07-16T16:13:00.008+10:00

The Elegant Solution by Matthew E. May

Part I: Principles
The Art of Ingenuity - Business meets art and science in an emerging view of work.
The Pursuit of Perfection - Conventional wisdom forcing a choice between small steps and big leaps misses the point.
The Rhythm of Fit - What distinguishes great innovation is its ability to serve the changing needs of society.

Part II: Practices
Let Learning Lead - Learning and innovation go hand in hand, but learning comes first
Problem: Learning disabilities hinder 360 innovation.
Cause: Learning is misunderstood and undervalued.
Solution: Make learning the job

IDEA: Investigate -> Design -> Execute -> Adjust

Learn to See - Elegant solutions often come from customers - get out more and live in their world
Problem: Solutions don't work as imagined
Cause: The facts aren't clearly understood
Solution: Learn to see

a) Observe -- watch the customer
b) Infiltrate -- become the customer
c) Collaborate -- involve the customer

Design for Today - Focus on clear and present needs, or your great ideas remain just that
Problem: Solutions land far before the need
Cause: Preoccupation with invention
Solution: Design for today

innovation -> providing tomorrow's solution for today's problem

Think in Pictures - Make your intentions visual - You'll surprise yourself with the image
Problem: The endgame isn't clear
Cause: Underdeveloped storytelling skill
Solution: Tell the story with pictures.

Capture the Intangible - The most compelling solutions are often perceptual and emotional
Problem: Solutions lack that certain something
Cause: Transaction tunnel vision
Solution: Capture the intangible

Leverage the Limits - Restraining Forces Rule - Resource constraints can spur ingenuity
Problem: The entrepreneurial spirit is M.I.A.
Cause: Addiction to abundant resources
Solution: Rest the bar

Master the Tension - Breakthrough thinking demands something to break through
Problem: Solutions lack inspiration
Cause: We satisfice
Solution: Work through creative tension

Run the Numbers - Think for yourself - Temper instinct with insight, focus on facts, and do the math
Problem: Proposed solutions lack basis in fact
Cause: Aversion to numbers
Solution: Counter intuition with insight

Make Kaizen Mandatory - Pursuing perfection requires great discipline - Create a standard, follow it, and find a better way
Problem: Innovation is hit or miss
Cause: Creativity is misdirected and mismanaged
Solution: Embed the kaizen ethic

Kaizen basis is standardisation
Creating a standard requires: A. Clarity B. Consensus
a) Establish a Best Practice
b) Document the Standard
c) Train to the Method

Keep it Lean - Complexity kills - scale it back, make it simple, and let it flow
Problem: Too many, too much - of everything
Cause: Assumption that more is better
Solution: Start thinking lean

Lean: doing more of what matters by eliminating what doesn't
How do we know we are lean? When the customer says "It's just what I needed. Getting it was effortless."
Lean: Customers pull compelling value from you effortlessly.

Leaders make meaning

Marketing and Innovation

2008-07-09T16:50:00.004+10:00

Business has only two basic functions-marketing and innovation.

- Peter Drucker

Learning Organisation and WOW Expansion Pack

2008-07-09T14:13:00.008+10:00

My colleagues and I were on return flight from Toyota factory tour. Starting with topics of organisations and skill-acquisition-based career path rather than role-based path, which tends to limit one's growth opportunities in my opinion, the discussion moved on to Toyota and their career promotion structure. How it is extremely long and challenging process to become a chief engineer and the enormous skill acquisitions on the way.

I like the idea of skills-acquisition-based career path and having long list of skills that would take ages to master as similar to chief engineer concept in Toyota. It is similar to playing MMORPG such as WOW. The best part of WOW is leveling up from level 0 to max level 60 (for initial launch). You get the sense of progress all the time. Once you hit max level, it feels great for a while but soon becomes less exciting because the rate of learning slows.

Luckily Blizzard publishes expansion pack every 1-2 years and increases max levels by 10 or so. Certainly all maxed out players get new things (skills) to learn. Cool. Joy of learning!

I think a learning organisation should do the similar by constantly generating expansion pack for members to learn. Identify new list of skills required to achieve organisational objectives and to articulate what they are and to generate content (training programs) for them to acquire new skills so their increase levels (effectiveness, growth, capability). Leaders in an organisation would be just like content developers for MMORPG. After all, everything is trainable, I believe.

Technical Risk Management

2008-05-13T16:26:00.004+10:00

While reading Waltzing with Bears, I realised that I had never done any rigorous risk management over technical risks. There are many common risks I can think of even without trying. For example;

selecting wrong middleware or servers
sup-optimal architecture/design assumptions
a module or component fails to deliver due to complexity or dependency

PMs/IMs generally own the risk register and the register usually excludes technical risks due to their lack of technical knowledge. I believe the technical risks should be managed with the same level of focus. I'm not sure it would be better to include the technical risks in general project risk register or to manage in a separate list managed by technical team. One thing is sure that I can improve my technical risk management better.

Set-Based Concurrent Engineering (SBCE) anyone?

Waltzing with Bears Part I

2008-05-13T15:45:00.008+10:00

Gems from Waltzing with Bears by Tom DeMarco & Timothy Lister.

If a project has no risks, don't do it.

Risk management is project management for adults.

The word maturity has nothing to do with technical proficiency. It is, rather, a quality of grown-up-ness, ......

A risk is a problem that has yet to occur, and a problem is a risk that has already materialized.

Risk management is the process of thinking out corrective actions before a problem occurs, ...... The opposite of risk management is crisis management, ......

Risk Transition: the point at which the risk materialises.

Transition Indicator: the visible event at the time of risk transition.

Component activities for risk management

Risk Discovery: initial risk brainstorm & subsequent triage
Exposure Analysis: quantification of each risk (probability & impact)
Contingency Planning: what you do if it materialises
Mitigation: steps that must be taken before transition in order to keep your options open and to make correction possible afterward.
Ongoing Transition Monitoring: tracking of risks

The worst organisations penalise unappealing forecasts, but not unappealing results.

Without risk management, projects have no way to distinguish between stretch goals and reasonable expectations.

Before any risk management. Speak the words "failure", "rejection", and "cancellation". If the words do not come out easily, you have cultural problem!

When you choose to ignore a risk, you're depending on luck.

Reasons to ignore a risk:

The probability of materialization is small enough to ignore.
Should the risk materialise, it makes the effort under management irrelevant.
The risk has minimal consequences and requires no mitigation.
It's somebody else's risk.

When a project comes wrapped as a challenge, it forces you into a posture of counting on a certain amount of luck.

Limiting the extent of your losses in software project work is more important, on average, than doing anything about your wins.

Project for Success

2008-05-01T16:02:00.011+10:00

Questioning the Role of Requirements Engineering in the Causes of Safety-Critical Software Failures by C. W. Johnson and C. M. Holloway questions the usual blame placed on inadequate requirements engineering for software project failures (safety-critical software). The paper is here.

The paper then presents the following list as root causes of the project failure identified incorrectly under inadequate requirements engineering.

lack of stakeholder involvement
incorrect environmental assumptions
communications failures within development teams
inadequate conflict management
lack of contextual detail

I find #4 interesting in particular. We suffered a bit from #4 in current project. The project required input from different departments (marketing, operation, client service and etc) which had different interests. It was a difficult process to draw a decision to everyone's satisfaction. The lesson was to work out conflict resolution process early among stakeholders.

It is a great checklist for early phase of a software project and a great starting point for discussion with project sponsors & project leaders.

See Alistair Cockburn's blog about the paper.

Belief

2008-04-21T11:39:00.004+10:00

We do not believe in ourselves until someone reveals that deep inside us something is valuable, worth listening to, worthy of our trust, sacred to our touch.

Once we believe in ourselves, we can risk curiosity, wonder, spontaneous delight, or any experience that reveals the human spirit.

- E. E. Cummings

Chief Engineer

2008-04-18T23:37:00.007+10:00

The top product development program at Toyota is the chief engineer (CE). CE is the project leader, project manager and technical leader all rolled into one. CE designs the system and is ultimately responsible for delivering value to the customer and the program's commercial success. CE therefore is usually sponsored by someone in vice-president level.

In Toyota product development, managers with no technical skills are moved to manage other things. Knowledgeable engineers without interest in people and money are sent to R&D.

During the program, CE becomes the primary voice of the customer. Because of this, a person with the background and experience to establish an emotional connection with the target customer is selected as CE for a program.

Therefore selecting chief engineer for a program is the critical first step of Toyota product development process.

Once selected, CE focuses on value discovery process and value definition. CE then communicates customer-defined value & vehicle-level performance objectives and aligns the vehicle-level performance goals of the entire program team.

Another interesting thing is the document called shijisho produced by CE. This is a concept paper that outlines the CE's vision for the new vehicle. The literal translation of shijisho is "direct order document" almost like a military order.

Elements of Toyota's Lean Product Development

2008-04-18T22:59:00.009+10:00

This is from Lean Product and Process Development by Allen C. Ward.

All Toyota developers spend about half of their first year assembling and selling cars. The final customers & the customers for the product development process.

Identifies the critical skills associated with each job.
1. Understands the basic engineering principles
2. Works fast enough to keep up with the team
3. Takes responsibility for the work
4. Can teach the skills

Keeping people in position long enough to become expert and to get good feedback on their decisions.

Require engineers to "get their hands dirty".

Developers must be evaluated on their contributions to project success.

Follow Process Mapping with Walk Through

2008-04-18T22:33:00.006+10:00

I have never walked through a process mapping or a process flow during the discovery phase of a project. This simple technique was mentioned in a local lean group meet-up.

Just pick up a process map and physically follow the process where the operational people are. Opportunity to talk to people on the ground, learn more about what they do and review the current process mapping. It can lead to rich learning experience. Rich context around the words and drawings.

Definitely something to try next time.

Standards

2008-03-26T22:23:00.007+11:00

I'm reading Toyota Production System by Taiichi Ohno. In "The True Intention of the Ford System" chapter, he quotes Ford's book regarding standards.

One has to go rather slowly on fixing standards, for it is considerably easier to fix a wrong standard than a right one. There is the standardizing which marks inertia, and the standardizing which marks progress. Therein lies the danger in loosely talking about standardization.

And the rest of the passage talks about that standards effort should not be directed from above or it does not lead to progress.

Schema Validation in XFire

2007-06-19T21:24:00.002+10:00

I'm working on a small web services project at the moment. I'm using Spring 2.0.5, XFire 1.2.6 on Java 1.5. One of the technical requirements was to have schema validation turned on for requests. Quick google search returned the two blog entries by Alexander Ananiev (first and second).

Second solution is much simpler because it uses JAXB to do the validation. It looked simple so decided to use it. Unfortunately when I applied the second solution, I got this cryptic error message.


org.xml.sax.SAXParseException: cvc-elt.1: Cannot find the declaration of element ’tns:application’.

First solution didn't work either. I spent whole afternoon on trying to fix the issue but gave up because had other higher priority stories.

A week later, I got a mail from a developer who was having trouble talking to my application. The request was received by the server and a response message was returned but his client application could not process the response message.

The problem was that first element in soap body had wrong namespace associated. First element of the soap body tag had namespace of wsdl while the rest of the message had namespace of the xsd schema. After trying some fruitless configuration changes, I started thinking that this may be a defect in XFire.

Quick google search returned the following entry in XFire JIRA.

Apparently it's behaviour introduced in recent versions of XFire. The solution mentioned in the Jira entry suggests to use JAXWSProfile when generating server stubs. The detail of how to use the WS profile is here.

Another change I had to make was to use org.codehaus.xfire.jaxws.JAXWSServiceFactory instead of org.codehaus.xfire.jaxb2.JaxbServiceFactory.

This problem occured on server and client side so I couldn't detect it.

Sorting out namespace issue also fixed the schema validation issue I had earlier. It turned out that the namespace problem was causing the schema validation above because the first element had wrong namespace.

Well... Web services experience wasn't not quite what I expected. Lots of hidden gotchas....

I will post on general web services experiences and lessons learned later.