A Never Ending Battle for

Continuous Improvement

J.J. Zang200 E Randolph St # 2500

Chicago, IL 60601-6501, USAXP 2011 conference

Outline• Introduction• Changes Made• Outcomes

• Continuous Improvement• Too Much Waste in Deployment Process Flow• Transfer• Customer Redefinition• Run a True Iterative Iteration

• Summary

Introduction• When I was assigned to FFM project (Field Force Management) for one of the biggest international

telecom companies in March, 2010, I was told I was the 7th project manager for the team and for the project. The team on the ground was completely lost and morale had hit record low. Before I agreed to take over the project, I interviewed the core team members and also spent a couple of days shadowing with each of them while they were working. The challenges the team had been facing immediately surfaced:

1. There was no scope defined2. There was no measurement of the team capability3. There was no “Kanban board”1 (Story card board)4. “Push scheduling”2 mentality was pervasive5. The trust of business stakeholders in the team was minimal6. Most of the team members were junior with little experience and exposure to7. Agile methodology

Changes Made• As a team, the first thing we did was try to understand the business purpose of

the project.• Once we settled on the business goal, the team worked with our business proxy

to flush out high level features.• We went a little further by breaking feature sets into stories with just enough

descriptions and assumptions.• Keep in mind, we didn’t write detailed stories and acceptance tests.• Detailed analysis of each feature and story was delayed until immediately before

it was developed.• The list of feature sets with highest priority was the backlog for our first release

(see Fig. 1).

Fig. 1

Changes Made• Next, the team tried some experiments to corroborate the viability of

architectural design, technical approach, and some large estimation numbers.• The team also had a couple of iterations3 to understand the team’s

capability.• Set up a “Kanban board” to track each story as it flowed through the

workflow.• Had one column for each step in the workflow (see Fig. 2).• Almost for each iteration, the team picked technical cards such as

spikes, technical debts along with feature stories.

Fig. 2

Outcomes• What completely changed the attitude of business towards the team

was our small demo at the end of each iteration.• We usually demonstrated our achievements during our IPM (Iteration

Planning Meeting).• With steady velocity and without overtime, the team actually finished

the back log one iteration ahead of time.• Meanwhile, the team grew more self-organizing with some leadership

guidance.

Continuous Improvement• There have 9 branches in total for the nationwide release.• Adopted an incremental rollout approach due to the constraints such

as the size of the branch, he readiness of the branch and the availability of rollout resources.• Believe it or not, it took 3 months, equivalent to development time, to

roll out to the first branch, then another two months to the second branch.• What went wrong? What did we miss? But more important, what did

we learn?

Too Much Waste in Deployment Process Flow• We all know dependencies are bad and that is why we have been trying our best

to get rid of architecture dependencies, code dependencies and story dependencies. This holds true with team dependences too. With team dependencies, it will be so difficult to deliver even a small feature set since it requires a large amount of communication and coordination among teams. The complexity of the communication adds time and increases the likelihood of error, and the added overhead cost makes small incremental releases almost impossible. Decoupling is often the approach we use to minimize technical dependencies. This applies to teams too. Teams work better if they can operate independently, without significant dependencies on other teams. Building cross-functional teams by pulling some folks from each team and embedding them in this cross-function team would help in mitigating the boundary-spanning problems.

Transfer• The implications of Agile must be pushed far enough into other parts

of the organization so that the entire team effort is not pulled back by organizational gravity. It is a relatively easy job to gain acceptance for Agile among developers, Qas (Quality Assurance), project managers, database developers, user experience designers, analysts and so on. But it is impossible for a development team to remain Agile on its own to make it successful. If the implication of using Agile is not transferred to other departments, organizationally inertia from those departments will eventually stall and kill the whole team effort.

Customer Redefinition• Traditional customer definition is limited to project sponsors,

stakeholders or end users. We need to redefine customer to include the ones who support, maintain or derive value from the system. In our case, the support team, the training team, and the transformation teams are also our customers. Including these customers will give us a complete boundary-spanning view of our work. In addition, as complexity increases, cross-functional teams sometimes are not enough. A single team will not be able to handle the complexity, thus handovers are inevitable. With every handover, it is important to clarify the immediate customer’s needs and flag whenever there is an issue.

Run a True Iterative Iteration• A true iterative iteration means the development team should strive

to produce a releasable application. Software needs to go through a thorough system testing including such things as end-to-end scenario testing, stress testing, UAT (User Acceptance Test), etc. to make sure that the code is ready for release. It is a mistake to delay all staging activities until the system is ready for release. It is risky not to pull the “Andon”8 cord to “stop-the-line” if a true iterative iteration can’t be achieved. In our case, we should have exposed the test environment problem at an earlier stage and called for attention and action instead of hoping to chase away problems with “work around”.

Summary• Most companies are aware that continuous improvement is critical

but few practice it as hard as Toyota.• Feeling the pain is easy, seeing the problems is hard, but taking

actions towards them is even harder.• This project was a successful one since the development was

completed ahead of schedule and the release was on time.• We would like to share our lessons, our experience and our journey

with others so we can all “Change for the better”.