A Never Ending Battle for Continuous Improvement J.J. Zang 200 E Randolph St # 2500 Chicago, IL , USA XP 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 defined 2.There was no measurement of the team capability 3.There was no “Kanban board”1 (Story card board) 4.“Push scheduling”2 mentality was pervasive 5.The trust of business stakeholders in the team was minimal 6.Most of the team members were junior with little experience and exposure to 7.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”.