Simple^4 Xiaoming Wang

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.

Vincent Xu recently invented a “Green Peace” style story card that I think might be a great innovation! The idea is quite simple, he laminated a plain story card which is made of paper with sticky back plastics so that the card can be reused. The motivation of creating the card is that he wants to write down some “To-do lists” or have simple technical discussion with other devs, so he can write or draw anything he wants to then erase the print and reuse the card.

I think the idea is brilliant and will contribute value for diverted project stakeholders. Let’s have a look the following story:

As a project manager/environmental protector, I want to reuse my story card, so that I save money and save environment.

As a project manager, I want to use limited number of story cards, so that I can take advantage of them as a tool to keep the project in a good shape.

As a developer, I want to a card to hold some information for an instant, so that I can use the card to communicate with other devs.

As a business analyst, I want to a story card which I can easily add or remove information without wasting the card, so that I save my time and save environment.

As a CEO/CFO, I want all my projects in the organization use the reusable story card, so that I can cut down the cost across the organization.

We can see, it is not only about saving the environment. Imagine, if we use limited number of cards in a project, when there is no enough cards to be used for writing stories, or bugs, it is possible that we are having too much stories in blocked, in this case, the Signal pushed the project manager to deal with it. If we have only 10 bugs cards, when we do not have a blank card for new bug, it is probably the right time to cut down the number of outstanding bugs. Have some brainstorming, you might be able to find more interesting usage of the “Green card”.

Some tips of making “Green card”:

• Get a wider Sticky back plastics, so that you might need only two rows of them to cover the whole card.
• You can use a shanpie but permanent marker to write on the cards.
• You might need a piece of tissue or eraser aside, so that you can eraser the print whenever you want.

More suggestions?

Successful projects

There are varied criteria of determining if a project is successful. They are

• Deliver on time
• Achieve the quality of the project(product/working software)
• Achieve the margin, maximum the benefit
• Customer’s satisfaction
• Resource well developed and enjoyable
• Good relationship with client
• Reputation in the industry
• and etc

It is not too difficult to define and work towards those objectives in the beginning of the project. However, two months later, how many projects were still considering the set of goals is what they were working for? Many teams only focused on several of them. If you were asked the question, why did you give up some of them? The answer would be very simple “No time!” I can not blame the excuses because the crucial judgment of a successful project is “Deliver on time”. The reason that we did not achieve all the goals in the end of the project is that we regard them individually, not looked them as one OBJECTIVE. And the even worse, team member might understand the goals differently, and work towards different directions. You might find, some objectives were partially accomplished. Partially done work is also considered as waste, even effort was hard made. Personally, I don’t reckon that a successful delivery is always the top one criteria to measure whether a project is successful. However, it is mandatory.

So how can we ensure that the whole team works towards the same goals, keep going and accomplish them in the end of project. You need GOT and GDT.

GOT stands for Goal Oriented Thinking; GDT stands for Goal Driven Team.

In general, we need the whole team think the project in a way of “Goal Oriented” and the project team should be “Goal Driven”.
It might be quite dry to understand the concept and where to start. Let me give a start point, thinking of the reasons of failure projects.

Reasons of failure projects

The reasons of failure projects vary case by case. They could be

• Customer’s expectation is beyond team’s capability
• Contract is much risky
• Requirement changes too frequently
• Lack of communication and feedback
• Team does not have the same goal
• Team does not focus on the goal
• and etc

Nevertheless, if the team does not work towards the same direction, the risk would be much more increased. Sometimes, project managers felt quite frustrated that the project failed even they had the money, right people and kinda nice customers.

Behind the reasons, either the team did not have the same goal, or did not work towards the same goal. So how to organize the team to achieve the same objectives along the road of project and make a project successfully? We need GOT and GDT.

GOT (Goal Oriented Thinking) & GDT (Goal Driven Team)

In order to make it more clear and transparent to my readers, I organize my thinking into five aspects(In pink). In each of them, there are solutions(In green) and tools(In yellow) to achieve the objectives of “GOT and GDT” through the whole life cycle of a project. Several solutions can also map to our daily business activities(In blue).

There are also relationship between Solutions, tools and activities. For details of this diagram please view here.

Goal Oriented Thinking

In the beginning of a project, not everyone in the team might know what exact goal of this project. So first thing, a project manager need to do is to figure out “Goal for small and big team” and clarify them, put them in a place that is visible to the whole team all the time. Then a PM still ensure that all effort which the team makes is for the goal of the small and big team. PM is responsible for drafting and finalizing the goals. I will talk about this in the “What a manager/Lead should do”section. Sometimes, you work in a small team which is part of a big team. PM need to let everyone in the team know the goal of each team. In most of the cases, small team has more goals than the big one. Make sure to balance them across teams. Team member could have objectives for himself. Make sure PM has the interviews before you draft the goal of a team, considering their personal objectives and balance it. After a goal or set of goals is finalized. It becomes the goal for a whole team. So It is OUR goal but for individual. One team One Dream.

Goal Driven Team

When you have a team which has the same goal. Next, make sure team member continue working to achieve it. To build a GDT, first thing, let everyone in the team understand it and ask them how they can do to help the team and himself to achieve the goal. PM can make it as several action items for teammates every other week. Then in the end of each two weeks, PM can evaluate individual performance against goal/value. It is not a good idea to have a performance review in the end of each year. Because no one would actually remember what a team member did well or not. Why not divide them into each very small trunk and evaluate them.

A pull system is a good tool in order to achieve the goal for a team. After we have action items for individual, you don’t have to push tasks to them, all you need do is get the tasks ready and ensure its visibility. Team member will self-organize to pick up tasks in order to accomplish team goals and his personal action item.

To build a GDT, PM should make sure that you get the right person on board. If anyone who always have different understanding of the team’s goal or can not work towards it. He might suit for the other projects but this one. A PM need to recommend him to another team or resource manager in this case.

An organization has her own visions, objectives and targets. Our ultimate goal is to align the team’s objectives with organization’s vision. Only a Goal Driven team can make this easier.

Transparent Team

Even, a GDT is right there, we can not take for granted that a team will never change. Team member need to know everything in the team. The team shall be transparent to all sponsors, customers, users and team member himself. It does not limit to visibility of the plan, progress and risks but the business plan. Why business plan? If a team member does not know it, he won’t know how valuable his effort is. If team member don’t know it, he would not know whether what he is doing is waste.

Another thing, every project need pay more attention to, let the team see the whole system but his individual area.There are several tools that we can use to help. Business process diagram of the whole system is always help. Each small team may highlight his own part.

Sometimes, developers focus on individual functionality/story, rather than the whole business process or the system itself. In the middle of project, some team keened to make large amount of code refactoring. There are many reasons that lead to the smell situation. One of them is that developers don’t see the design for the whole business process or system. The diagram here shows how stories map to the business process. Why not hang this diagram somewhere everyone can see it?

For project plan and progress reporting, I recommend several tools, such as “S-curve”, “Burn down and burn up Chart”, Kanban or story wall and task wall

What we did was not enough. 10 minutes technical knowledge sharing should happen everyday. One minute talk is another useful tool for the team to practice communication skills. We can do more. Get the lessons learnt visible to the whole organization and require feedbacks. Open discussion, more communication helps the team more transparent.

At the same time, the team has the reporting material for senior management team. No extra work is needed. Someone said that “Reporting is only for bosses”. Not all true! Bosses need see what is going on in each team, meanwhile every team member need know this as well. They should see the same page.

What a manager/lead should do

I have been talking about what a manager/lead should do in the previous sections. Personally, I don’t like separate managers and leaders into two groups. Nowadays, managers do not only control schedule, control cost and etc, we also set directions, develop resource, align people and Enable motivation.

First thing, a manager should do is to draft and finalize the goal for a team. So what is the goal composed of?

• Contract and deliverables
• Margin of the project
• Individual career development
• Organization vision
• Customer expectation and satisfaction
• Team’s enjoyableness of the project
• Business development’s strategies
• Reputation
• And etc

This is how a project goal composed. Think of its balance and compromise then, explain it to the whole team, answer questions and reach individual’s understanding.

PM and the whole team need to highlight the goal in any occasion, such as meetings, activities, requirement discussion and etc. Whenever you observe an activity that violates the team’s goal, anyone should stand up and let the people know that they might be going to a wrong direction. The team shall consider those behaviors as waste and eliminate them right away.

For HR team, it is a good way to measure people’s performance referring to if individual worked for the team’s goal and how much value that each team mate contribute .

Goal is not everything

How do we deal those good ideas that are not associated with our goal?

Please don’t throw them away or ignore. Offer another place for those good ideas and encourage the team to develop the ideas into true story in non-project time. I always believe that the creativity and ideas are the keys of a successful projects.

Summary

In summary, combine the goals of organization, project and individual into one GOAL, as OUR goal. Help the team to work towards the same direction in order to achieve the same goal which will make you a successful project.

Software development is a procedure of manufacture. However it is not all about manufacture, it is manufacture of creativities. When Toyota started applying Lean methodology in their car making plant, they might never imagine that some years later, IT industry would start applying lean in the software development. The successful experience mostly come from the combination of Lean and Agile.

So what lean principle is and how to apply Lean principle in Agile project management? Typically Lean processes; synchronize the flow of work, through the business balance work loads, reduce work in progress and shortens lead times. Lean has seven principles. They are:

• Eliminate Waste
• Amplify learning
• Decide as late as possible
• Deliver as fast as possible
• Empower the team
• Build integrity in
• See the whole

Eliminate waste

As we know lean basically aims to eliminate the waste, shorten lead time and empower the team, so it is all about eliminate the waster in order to response customer’s requirement more effectively and cut down the cost.

So in IT project, how do we eliminate the waste? We have to find the waste first then find a way to eliminate them. Let’s see where the waste come from in a software development project:

1. Partially done work
2. Extra processes
3. Extra features
4. Task switching
5. Waiting
6. Motion
7. Defects

Yes, in order to eliminate those waste,one strategy could be used here which is called Value stream mapping:

Find your waste and map your current process with value, any in valuable process should be eliminated from the process

1. List 10-15 most important activities and rate them 1-5, (1: least important, 5 highest value) . —- Take two lowest scoring activities and plan to cut the time of these two activities into half.
2. Discuss one of the 7 waste in the meeting and ask
   • Do you agree that this “waste” is really a waste? Why or why not?
   • Whether or not you agree that the item is a waste, estimate how much time it consumes in an average week.
   • What can or should be done to reduce that time?
3. Develop a value stream map. Start with an incoming request and map a timeline of its progress to providing customer value. Find out how much of the time is spent adding value and how much is spent waiting. Take the biggest cause of delay and develop a plan to cut it in half.

Amplify learning

In an IT project it is always critical for the team to communicate efficiently and get feedback as fast as possible so the team can learn fast and response fast. In order to achieve it, there are several things that you can do:

• Feedback
• Iteration
• Synchronization — Define and dev interface then component
• Set-based development

Talking about set-based management which is opposite to point-based management,check out how to apply set-based management in a project below:

Set-based VS point based development

1. Set-based development: three steps
2. develop multiple options
3. communicate constraints
4. solutions emerge

Decide as late as possible

When a team decide the plan for the next 6 months, they work hard for the goals, however, people found that the plan was always changing because the requirement was changing, the team was changing and almost everything was changing. So in my opinion, don’t make decision too early unless that you have to. There is a famous 100 days rule in project management which was defined as that never plan a project more than 100 days or 3 months. Why don’t we try the option thinking?

• Options thinking
• The last responsible moment

Someone might say that there is a lot risk if we try to make the decision as late as possible. Yes there is. So that we should to try to do the following in order to keep the risk lower.

• Share partially complete design information
• Organize for direct, worker-to-worker collaboration
• Develop a sense of how to absorb changes
• Develop a sense of what is critically important in the domain
• Develop a sense of when decisions must be made
• Develop a quick response capability

• Making decisions — Flexibility, Robustness, Self-organization

Deliver as fast as possible

No customer want to see the result in the end rather than see the progress very often. So as a software development team, “deliver as fast as possible” is quite important.

• Pull system — against push system, and information radiator
• Queuing theory
  • Reducing cycle time
  • Steady rate of arrival
  • Steady rate of service
  • Slack

• Cost of delay

Empower the team

From the experience of GE’s work-out, we can see there is no better way than let the worker to make the decision rather than the managers because the workers are the core of productivity.The people who add value are the center of organizational energy. Managers should play a role of collaboration, leading and support.

• Self-determination (CMMI VS Lean)
• Motivation
• Leadership (Manager VS Leader)
• Expertise

Talking about Self-determination, I have to talk about the difference of CMM and Lean. There is no good or bad while they are just different and can work in different circumstances.

CMMI Assumption

• A system is best managed by disaggregating it into identifiable work products that are transformed from an input to an output state to achieve specific goals.
• A mature organization is one in which everything is carefully planned and then controlled to meet the plan.

Lean Assumption

• A mature organization looks at the whole system; it does not focus on optimizing disaggregated parts.
• A mature organization focuses on learning effectively and empowers the people who do the work to make decisions.

Here contrast to the original concept of management or manager, as planning, scheduling, controlling and reporting, management and managers are also should be leading or leaders. As Jack Welch said in his book Winning, before you become a manager/leader, all you need do is to develop yourself, after you became a manager/leader all you need do is to develop the people in your team. As a leader you not only do Plan,Budget,Organize,Staff,Track and Control but also do Set Direction,Align People and Enable Motivation. Yes, give it a try that is always a good motivation!

Build Integrity In

You can also find some suggestions about Integrity in Jack’s book. Almost every successful organization or manager encourage people to build integrity in the organization or team.

• Perceived Integrity — Model Driven Design(Conceptual domain model, glossary, use case model, Qualifier)
• Conceptual Integrity
• Refactoring — Simplicity, Clarity, Suitability for use, No repetition, No extra features
• Testing

See the whole

Last but not least, a team not only the project manager should always see the whole of the system even not in his own project but in the whole product or system.

• System Thinking
• Measurements
• Contracts

Now people can see when you do a project, there are more that you can do to eliminate the waste, empower the team in order to response customers’ requirement faster, increase the efficiency of the project. It is not really easy to apply all these principles in one day however bear in mind and give it a try. There would not be too long to see your own project better and better!

I was recently asked by a customer of how to manage non-functional requirement in agile project. After discussing with Jeff Xiong, we figured out an idea.

Based on Jeff’s opinion, any question in agile project could be analyzed in this way:

1. Clarify your target;
2. Brainstorming;
3. Find options;
4. Analysis these options from different angles;
5. Make a guideline;
6. Create verification method/frequency;
7. Separate them into small units and track.

As we know non-functional requirement varies from one by one. Basically there are two types of them.

• Can be regard as functional requirement(such as usability, localization and etc)
• Can not be regard as functional requirement (such as performance, design requirement, integration requirement and etc)

For those can be regard as functional one, YES, treat them as functional requirement and describe them as stories.

For the others, write a non-functional requirement story for it. An story card template was list below.

There are six basic rules you should think of before you make a non-functional requirement card.

• Who wants it
• What they want to achieve
• Why it’s valuable
• Relative priority
• How you would be confident that it’s been done or how to verify
• Could it be a “function”?

After you have a clear idea of the questions that I list above, you will be ready to develop an non-functional story card.

Bear in mind, verification method/frequency is the core of this card. Guideline indicate the way of complete the story successfully.

See it is manageable and traceable.

I recently worked for a client who has been in the stage of CMM5. After long painful struggling of heavy documents and poor quality of production they decide to give Agile a try. Their plan is to start at the point of upgrading their major network management system. Off the top of theirs heads is to refactor the code, add tests (unit tests, system tests), and optimize the software development process.

Things did not start as they expected. Problems came into the project team as flood. Some of the problems are

• How to do TDD?
• How to refactor Java or C++ code?
• How to write unit tests?
• How to automatically do GUI test and system test?
• How to apply common Agile software development process under their CMM infrastructure?
• How to make the agile process keep going on and on and lower the risk of rolling back?
• etc.

They don’t know the answers of those questions and unfortunately they have a extremely complex software development process which depends on documents output very much. Basically, it constructs under a typical IPD process. The team that I am working with has almost zero knowledge or experience of Agile.

How to bring such a team which follows a complicated process for a quite long time into the agile world? There might be three things that you could do in order to make it happen.

Firstly, IDEAS!

Brainstorming, ice-break, stand up meeting, retrospective, testing everything and etc. Fill the team with all good ideas and practices of agile as feeding the Beijing duck(If you know the story, Beijing duck was forced feed each each meal). While, those good practices and ideas are not the core of Agile. During the each session of training, coaching or Q&A, the core message that we delivered is “Value driven spirit” and Lean project management methodology.

Team build is also the major task in this stage. When I came in the office at the first time, I saw a silent team. There was no group discussion, everyone works on his own and a few communication. Let’s burn them up, agile games were introduced one by one at the beginning of each training or meeting. Then, I encouraged a couple of senior people to coach those junior guys. Prize and appreciation were sent out every a couple hours in order to encourage the whole team to THINK, COMMUNICATE and TALK. It was ready to go forward to next step, when the trust was established in the end of this stage.

Secondly, Process improvement.

The client is using IPD process to manage their software development process. Have a look at the typical waterfall process below.

You can see huge amount of design description, requirement description, and software description, HLD, LLD documents were written during the whole process. At each point, those documents must be delivered due to the concept of CMM. Meanwhile the quality of the software was not well verified because of less monitoring or feedback during the whole process.

Based on their current process, we figured out a improved process which is attached below

From the diagram, we can see, the design requirement document (DR) was written in the format of release level stories which were broken down into iteration level stories. These iteration level stories forms Design Specification (DS). The advantage of this change is that we merged DS, SRS and other documents which overlapped a lot into iteration level stories. They could be developed in each iteration. We saved much effort of developing those documents instead that we focused on the quality of the software.

Another shining point of this improvement is that developers/testers do not have to wait for the delivery of these design documents before start coding or testing. On contrast, they get the first set of stories from SE(System engineer) and started coding right after those stories were created. Earlier developer started coding, Earlier the product would be delivered. See the time that we saved on the diagram

That has not been all. Step three, do at least four iterations!

People who is doing CMM always have doubts of Agile and its practices. It is supposed to happen and it is really OK. Let’s roll out based on the hard work that we had done. After three to four iterations, people who have doubts saw something new, continuous integration environment, automatic testing tool, deep code refactoring, 100% unit test coverage, TDD, system test automatically, more communication, pair switching, design discussion, and etc. All these activities turned vividly. The project team was happy and relax when they were pairing and coding. Less stress make them think more. Think how to do things in a different way; how to make this test more efficient, how to refactor this piece of code in a effective way……. Many good things happened in the project. The quality of the product was improved because the coverage of the UT, ST, regression test and smoke test. Team work more efficiently because continuous integration tool, automatic GUI testing tool and etc.

Before we launched the project, we would not believe that a CMM5 organization could convert to agile so successfully. However all this happened pace by pace following the ideas of “value driven and lean”.

For me, another successful project as a PM

Project risk management

In terms of project management theory, risk management in a project can be defined into three main activities:

• Risk assessment and analysis
• Risk reduction and monitoring
• Risk management process and methodology

It might be difficult to understand the boring theory. Let me give a real example to talk through how these activities happen in a project.

Imagine, you and your partner plan to have dinner in a fancy restaurant on the Fifth Revenue for your three years anniversary. Basically, you guys need go through the following steps in order to make your wife/husband happy.

1. Find the number of the restaurant
2. Call the number and book the table
3. travel to the restaurant
4. Order
5. Eat, drink, sweet talk, eye contact, and etc…. wait, drink more
6. Pay

In the above steps, if everything is going well, brilliant! However, as you know anything could go wrong in real life, you would not know beforehand. Such as “the number is wrong”, “No table available”, “No texi, or huge traffic prevent u getting there”, “the restaurant forgets booking your table”, “Your wife/husband is not happy with the dishes”, “They do not accept credit card or your credit card does not work” and etc. There are many of them. On contrast, they might not happen if you are lucky. You might discover more risks than I list out. So generally, a brainstorming is absolutely necessary on this stage. Just remember, the brainstorming starts earlier than your anniversary and go through the whole process.

Yes, first thing we need do is to assess and analyse these potential risks and their threats so that you can decide which one you need pay more attention and which not. Let’s make a matrix for these risks.

You can easily figure out why “Your wife/husband is not happy with the dishes” is critical for this “project”. Because it might cause a big fight and ruin your “perfect plan”. The impact*likelihood of “No table available” is small because it is not some special occasion or holidays. Generally it is not that difficult to figure out based on brainstorming, assessment and analysis.

During the analysis, you can prioritize the risks by “Impact*likelihood” to determine which risk should be pay more attention and focused on.

So, when we know these risks and their threats, impact and likelihood, how do you manage them in order to reduce the impact to the lowest level? There are four ways to manage risks. They are

• Mitigation
• Transference
• Acceptance
• Avoidance

In most of the circumstance, we acceptance those risks with small “impact*likelihood” and try to avoid or transfer some risks which can be. For the rest, you might not find a way to get rid of them, so mitigation is the only thing that you can do.

For the risks specified in the matrix above, we can add columns “Strategy”, “action” and “Owner”. The duration of the action would be nice to have.

Next thing that you need do is monitoring the risks and guarantee that all the known risks are under control.

Agile project risk management

Even in agile projects, risk could be much less against waterfall model. There are still going to be risks for a project management team do deal with. So how and when to do it? Who should responsible for the risk management in an agile project?

• During the inception phase, much brainstorming will be done, so why not identify, assess and analyse some potential risks?
• During daily stand up, why not the team give a brief update of risk matrix and new risks that you can think of?
• Any time during the day, when an idea pop up your mind, why not have a discussion with the team members? If it is a risk, record it into the matrix.
• PMT, as everyone in the team is responsible for risk management
• PM, as project manager is responsible for maintain the matrix and facilitate weekly risk update meeting.

There are more that we can do for agile project risk management.

Based on our experience, where could risk come from and how it look like could be forecast and pre-prepared. However do not pre-prepare too much. Because every project is different, it might have all different risks across different projects.

There is no short cut to do risk management, just keep an eye on and make sure everything is followed up by someone.

Interestingly, by using lean project management, it could help to identify the risk priority but it does not mean that we could ignore the risk management by focusing on the bottle neck.

The last day before China National holiday, I got the chance to learn TDD from Hu Kai who is a main contributor to CruiseControl and CruiseControlEnterprise.

Basically, we made up an example for practicing. A good example for TDD exercises is “develop a calculator”.

• First thing, we did was write a JUnit test for calculator project, based on requirement
  

  As a user, I want the calculator to have absolute value function, so that I can carry complex calculations.

  with one of the three acceptance criteria.

• Then run the test. When we saw the test failed, we know that it was time to develop some functions to make the test successfully.
• After we accomplish the the code part, then re-run the test. This time test passed
• It is not done yet. Add one more test case, run test. Failed, then improve the code.
• When we added the last two test cases, test would not fail so it meant that our function was achieved based on the requirement.
• Next step refactoring code. Done. The code looked neat and pretty

But it looked something missing…… Ah! Comments! Yes, I remembered that the first thing my teacher taught me in Java programming was “Don’t forget writing down your comments, otherwise people would not understand them.”

Hu kai, why did not write some comments in your code?— Xiaoming

You don’t have to because all the tests and code are self-explaining and highly comprehensive.— Hu Kai

Then people in the room had a discussion when should we have comments in Java code with Agile practice. My idea was that for those legacy system, if there were no comments or documents, how could people understood them? Different opinion was to write as high-level self-explaining code as possible. For example, make the names of classes, functions human-readable. I would buy their ideas except in some cases, comments are necessary

• Interfaces, libraries. Yes these abstract information need comments to help programmers to understand how to use them. We might call it “User guide” rather than comments.
• Complex algorithm. It would be very difficult for programmer to understand without spending much time on it. So it’d better to have comments for the brief explanation of this section of code.

Meanwhile, functions should be as simple as possible so you don’t have to write comments for complicated ones. Basically breaking down complex functions into simple ones would be a good idea.

All in all, when we initiative to learn something, it always came to the end with more knowledge and experience in your pockets. What a brilliant enthusiasm of learning!

Unfortunately, in most of the university classes and labs, students have not got chances to do useful exercises like this. I highly recommend doing more in our universities classes or labs.

~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.

According to Lingling’s question, let me give a real example. Firstly list the three acceptance criteria.

Given a positive integer A ,When I calculate it with abs function, then I get the same number A.

Given a negative integer “-B” ,When I calculate it with abs function, then I get a positive number “B”.

Given number “zero” ,When I calculate it with abs function, then I get zero.

Let’s write the first test case: My idea is to show the logic so it would not be the real code

Public boolean testAPositiveNumberShouldReturnPositiveNumberWithSameValue(4){
if(object.abs(4)=4){
return true;}
else{
return false;
}
}

When we have this test case for acceptance criteria one, and run the test. Obviously, the test failed because we do not have the function abs yet. So let’s try to write some code to make the test pass

Public int abs(a){
if(a>0){
return a;
}
}


Build the code, once you run the calculator tests, it will pass because the method provide the function of test “testAPositiveNumberShouldReturnPositiveNumberWithSameValue”

Then we add another test case based on Acceptance Criteria two

Public boolean testANegativeNumberShouldReturnPositiveNumberWithSameValue(-4){
if(object.abs(-4)=4){
return true;}
else{
return false;}
}

When you run the test, you can imagine that the test failed.

It is time for you to write some code to fix the fail test. Can you do it? OK let me do it for you:-)

Public int abs(a){
if(a>0){
return a;
}
else{
return -a;
}
}


Build, run test, Yeh!!!! Test passed!!! Even when u try the third test case, it passed either. It means that you don’t have to write more code about it. This is the beauty of TDD

Next step code refactoring. You may use Math.abs() to replace that piece of code

So, let’s answer your question one by one:

• Is each test case designed to test one of the three acceptance criteria?

The answer is “Yes” You can write the three test cases all together. However I highly recommend to write each by each.

• How do you define the test is “failed”? e.g. If the result data is not “exactly match” the expected data? or the test doesn’t run properly?

I might not need answer this question. If you do not have the function to satisfy the JUnit test, the test would definitely fail. If you are familiar with Eclipse you might easily understand what I am talking about.

• Why did you “pass” this test with only one test case for each requirement?

The beauty of Agile is to do every little bit each time then increase little by little. As soon as you find out that no more code is needed, the job is done!!