A Never Ending Battle for Continuous Improvement

1. A Never Ending Battle for Continuous Improvement J.J. Zang 200 E Randolph St # 2500 Chicago, IL 60601-6501, USA XP 2011 conference

2. Outline • Introduction • Changes Made • Outcomes • Continuous Improvement • Too Much Waste in Deployment Process Flow • Transfer • Customer Redefinition • Run a True Iterative Iteration • Summary

3. 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: • There was no scope defined • There was no measurement of the team capability • There was no “Kanbanboard”1 (Story card board) • “Push scheduling”2 mentality was pervasive • The trust of business stakeholders in the team was minimal • Most of the team members were junior with little experience and exposure to • Agile methodology

4. 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).

5. Fig. 1

6. 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.

7. Fig. 2

8. 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.

9. 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?

10. Too Much Waste in Deployment Process Flow • We all know dependencies are bad and that is why we have beentrying our best to get rid of architecture dependencies, code dependencies and storydependencies. This holds true with team dependences too. With team dependencies, itwill be so difficult to deliver even a small feature set since it requires a large amount ofcommunication and coordination among teams. The complexity of the communicationadds time and increases the likelihood of error, and the added overhead cost makessmall incremental releases almost impossible. Decoupling is often the approach we useto minimize technical dependencies. This applies to teams too. Teams work betterif they can operate independently, without significant dependencies on other teams.Building cross-functional teams by pulling some folks from each team and embeddingthem in this cross-function team would help in mitigating the boundary-spanningproblems.

12. Transfer • The implications of Agile must be pushed far enough into other partsof the organization so that the entire team effort is not pulled back by organizationalgravity. 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 itsown to make it successful. If the implication of using Agile is not transferred to otherdepartments, organizationally inertia from those departments will eventually stall andkill the whole team effort.

13. Customer Redefinition • Traditional customer definition is limited to project sponsors,stakeholders or end users. We need to redefine customer to include the ones whosupport, maintain or derive value from the system. In our case, the support team, thetraining team, and the transformation teams are also our customers. Including thesecustomers will give us a complete boundary-spanning view of our work. In addition,as complexity increases, cross-functional teams sometimes are not enough. A singleteam will not be able to handle the complexity, thus handovers are inevitable. Withevery handover, it is important to clarify the immediate customer’s needs and flagwhenever there is an issue.

14. Run a True Iterative Iteration • A true iterative iteration means the development team should strive toproduce a releasable application. Software needs to go through a thorough systemtesting including such things as end-to-end scenario testing, stress testing, UAT (UserAcceptance Test), etc. to make sure that the code is ready for release. It is a mistake todelay all staging activities until the system is ready for release. It is risky not to pullthe “Andon”8 cord to “stop-the-line” if a true iterative iteration can’t be achieved. Inour case, we should have exposed the test environment problem at an earlier stage andcalled for attention and action instead of hoping to chase away problems with “workaround”.

15. 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”.