Simple^4 Xiaoming Wang

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