Simple^4 Xiaoming Wang

AAladdin.com is an agile organization transition framework that was created by me in order to help medium and large size company to transfer from current organization structure to an agile organization.

For details please check AAladdin.com (in English) and AAladdin.com/cn (In simple Chinese)

London marathon was held on 26th April 2009 and there were more than 35,000 people participated. Runners dressed up with all kinds of funny costumes, funny as hell. I saw at least 4 spider men, 3 super men, 2 bat men, sunflowers and etc. Of course there were professional athletes, especially women’s game. The winner of 2008, 2007 London marathon, Olympics medalists were all present. Zhou Chunxiu(from China), Olympic bronze medal Olympic 2008, campaign of London marathon 2007 was one of the strongest potential winner who ended up out of top 10. She was in the first group in the first 25km and in very good shape when she passed my front door on Westferry road. Unfortunately she fell behind right after the 25 km point.

There might be a few reasons that she lagged around that point(24 km) where I was. She was not able to pick up the energy drink that was prepared for her and put on a table under a big sign something like “Drink pick up-1″. I guess that she might have moreenergy and get much better result if she was able to pick up that small bottle of drink. I also observed that almost all Japanese athletes had no trouble to grab their drinks. If you look at these two bottle of drinks and read my analysis, you might know why the design of the drink bottle actually matter.

Check out the pictures below (demonstrated by my super model – Dapang ) and find out why the Japanese design is much easier to drink.

So, you see the design of a simple bottle does matter and maybe matter a lot. Think of the design in auto-motor or IT industry, a small awful design might just ruin your potential big success which was established with millions of dollar and lots of hard work.

Gordon Ramsay, a famous British food writer, business man and TV star. He stars in the Channel 4 series Ramsay’s Kitchen Nightmares which tells stories how he help some dreadful restaurants to come back to the business and win back customers. I watched the episode this Thursday, which was very impressive because I found that there were so much in common of what Gordon did in his show and what we did in our agile software development projects.

The show started, he walked into this rural Lancashire pub where he had found the landlord laying down the law in the kitchen and doing 120-hour weeks, despite undergoing a quadruple heart bypass, and had debts of £250,000.

It reminds me a failing project that was over spent and had people doing quite a lot over time but still did not seem to make the deadline.

Gordon identified some key problems and found out the root causes very quickly.

Does it ring any bell to you? Yes, we had very similar problems in software development projects. Let’s look at a series of ways that Gordon tried to solve above problems.

• Changed the menu that is simpler and customer centered
• Kicked the boss out of kitchen and let other chiefs make decisions as a team
• Got rid of those fancy plates which did not suit for the pub food theme and was not used that often
• Strengthen what they were good at (Original puddings) as a brand and selling point
• Encourage communication inside the team and with customers
• Gathered the whole team to do stand up meeting and asked them to look back what they did right or wrong
• Motivate the team, show praise and appreciation to the team, build good relationship between the boss and the team members

Gordon Ramsay played a very good project manager role in this game and he demonstrated many good software development practices by using agile and lean principles.

Running a business or managing a project might be very different between different industries and domains. However insight how to solve problems, there are methodologies and principles that could be used in common. Maybe it is because running a restaurant and developing a software are both professional service. I still remember that I benefited a lot from the experience of working in a restaurant when I started my IT career as a technical support engineer.

I recently watched a BBC show called “Dream homes”, that basically talked about how to help people who had problems to decorate their awful house into a dream land within a limit budget. Normally, from the beginning, the house-owners and the show organizers came out a plan, say “budget 80 grand”. When the procurement and  engineering work started, with some changes happening, the budget always went up dramatically to double or even higher. Then they had to give up something in their original plan in order to cut down the cost. Along with the whole program, there were many changes, such as change of the engineering design, “shopping-list”, construction implementation. Sometimes, money were saved and sometimes lost by these changes. This show made me think of our software development projects that included lots of changes every release, every week even everyday. These changes might be initialized by business owners, end users, project managers, or development team. People in this show did not feel like being good at the change management that touched me off thinking about what good practices that we can use in project change management and how to use them.

Insight a traditional project change management approach, a change typically goes through at least 6-7 steps of a process from it is born to its end.

1. Change initiation
2. Change classification/Define
3. Risk/Impact assessment
4. Plan
5. Change approval and notification
6. Execution/Implementation/Test/Monitoring
7. Change acceptance/record/closure

This process made sense to me theoretically, and I did went through several times of the whole process when I was an IT manager in a large organization. It certainly “worked”. However, I observed several phenomena that were either waste or dragged the whole thing to the opposite direction of the goal of the change. E.g.

• People focused on a very detailed plan and it turned out none of the many times of execution actually went step by step following the plan.
• Documentation maintenance was paid very much attention even than the actually the change itself, however two years later, no one actually went back to see any of those documents. I can tell the main reason behind the concreted documents was that people did not want to get into trouble if there were anything wrong concerned the change.

A process/plan driven management approach might caused the above problems. The underline reasons are that human-beings keen to protect themselves and achieve personal achievement firstly if you do not bind their performance with your organization’s value and achievement. However if people could be trained by value/goal driven thinking align with reactive/adaptive project management approach, those problems would be solved.

In a typical IT change project, however it is big or small, going through with the structure of the process is not a bad idea, meanwhile, put too much assumption or make the plan very much details could kill creativity and flexibility during the implementation of the change itself.

Software development project could be a bit different in change management. It is not easy to achieve the same understanding of cost-efficiency of each change, so it normally came to the situation, business stakeholders and development team went for slightly different direction during the implementation of a change. It might be worse, if there was change during the process of making a change. So, certainly it would be very inefficient to go through a whole process every time.

So what would be a good idea? When there was a change that was initialized, team can regard it as a task and put it into development task list, we can think it as a functional task, or defect or whatever it is easy for the team to understand. Then re-prioritize the task list and rank this new task (change). When team estimate the workload of this task, its impact on the existing system need to be considered. Sometimes, it might be just less costly if a change could be combined into some existing tasks that they have similar priority.

People who manage change plan should consider which option could put more business value into the software application and what the goal was to finally achieve. When people driven by value or goal, with a simple plan in hand, they could be very flexible during the implementation, so that the process and documentation just played a helper role rather commander.

Tips:

• Sometimes, business stakeholders and development team could not easily have the same understanding the cost of a change. In this case, splitting the change into several tasks could make it easier to understand.
• Use any chance such as meetings, daily catch up, project Wiki to communicate with the team about the changes that would be made and notify every sponsor and stakeholder.
• IT need provide enough information for business to understand the cost and impact of a change and co-work to make a correct decision.
• Make a change plan more goal-driven and not too detailed so that team can be more creative during the implementation.
• Communicate more if it is possible, maybe development team can demonstrate a completed task that was not the complete change to business, so that team can check if they were going to a correct direction.
• Risk and impact assessment is necessary however it does not need to be very formal or be written as documents.
• The closure of a change should be able to be demonstrated in the real application.

Back to the beginning, if the house-owners could manage their changes in this way and well prioritize their task list and considering any change as one of task, their job might not be that painful, they might just get a fairly dream home.

Dot-com bubbles

Challenge of IT industry

Real economy need IT innovation

So what shall IT do to be prepared for the coming spring?

A story 

Recently, there was a thread in e-mail talking about why BA (Business Analyst) is needed in a software development project. The reason is that some of our client have concern why they need pay such a relative high rate for a BA. The argument is what the value of BA is? There are three crucial expertise that BA has.

• Requirement Management
• User Interface Design
• Domain Knowledge and Experience

I am not going to talk about why domain experts and UI designers are important in a project. BA also take the responsibility of managing requirement in an agile project. In some projects, we called the role Requirement Manager.

So how does BA manage requirement? We group the activities into these four processes.:

• Requirement Gathering
• Requirement Analyze
• Requirement documented
• Project planning

I will talk them through with some examples.

Requirement Gathering

There are so many ways and tactics to gather requirement. Such as end user interview, expert interview, questionnaire, observation, experiment, brainstorming, and etc. In many case, a project choose a unefficient process to gather requirement although they might use many good methods and tools. A typical diagram of project requirement hierarchy is

As we can see, the cost of communication is big, also the bad impact of this hierarchy is that lots of requirement were lost or misunderstood by the team during the transportation. It is even worse, the team might understand the requirement in different way, finally what we developed might not be what end user really wanted. The team member could get different information and decision from PM, BAs or QAs. It is a nightmare for a team in a tough schedule. What we can do in order to solve the problem is to bring the three layers in the middle into one. And organize them as one requirement management team.

With this way, business analyst, domain experts and project manager can work together to help the customers and end users understand their problems well with their expertise.

Requirement analyze

There are some basic tricks for requirement analysis. Such as 5W1H (What, Who, Where, When, Why, How). My colleague Chris Stevenson taught me another trick (5Why, alway ask 5 why when user want a function) which is quite useful to dig out the real value of the story and find out the root cause of the problem. Let’s see a real case of how to figure out a right design to solve a problem.

Once, I got a requirement from a BA, said that customer wanted to show build number, type and deployment date on the main window of the application (Client-Server application). It will be a simple implementation but I still push back because I don’t see the business value of the “requirement”. Then the BA provide a couple of scenarios in order to help us to understand the problem better.

Scenario: A trader came to office and found out that the application did not work. He called the support people who asked him a couple of questions. The trader provided the build number, then the support people still could not figure out the problem. In the end, the trader complaint that the application did not work. Actually the root cause was that the user was using a wrong version of application. The support complaint that he could not get enough information from the user to help him solve out the problem.

We can tell one option of solving the problem is to have rich information on client side to help support and end user communicate. However, the solution does not solve the ultimate problem. Indeed, what the support people and user need to know was that “user is using a wrong version of application”. The simplest solution is to show a message on the main window of application “Wrong version of application”. If the user passes the information to support people, he can re-deploy the right version of application to this user. Then problem solved. Did the support or end user care about the build number, type or deployment date? NO. They did not.

It is not too easy to identify the problem however BA need find the root cause and give the solution to solve the ultimate problem.

Requirement documented

In most of the agile project, stories are used to document requirement. However, it is not enough according to my experience. Personas, scenarios, business diagrams, and data mapping diagrams are also good documentation for the team to have the same understanding of the requirement.

Project planning

When we have enough prioritized requirement for a couple iterations or releases, we can start planning the project. The project plan will be justified in terms of the changes of the requirements. Certainly the project plan contains a set of prioritized stories.

Requirement Management is not easy. BA need also have psychology knowledge to get and analyze requirement more effectively.