The Double Helix Model for Lean Agile
We are living through a winter of discontent in the Enterprise IT space serviced by IT services organizations.
Agile is no longer new; Agile projects which are running effectively are being asked to be efficient; at the same time, cost efficient projects are being asked to be more Agile (with Agile meaning different things to different stakeholders). In the minds of clients, the words Agile and Lean have become synonymous with effective and efficient IT services delivery. Long seen as two parallel ways of work, we are now being asked to do both. Does ‘Lean Agile’ – which is becoming fashionable with some clients - exist, and what does it look like?
The authors of this session come at the problem from opposite directions. Avinash’s starting point is a tightly managed traditional project burned by a (past) failed Agile implementation, that nonetheless needs to deliver the value Business is demanding; Jay runs a large successful Agile program that the customer is now demanding efficiencies from. We came together to create the Double Helix, a model to implement Lean Agile.
Before the implementation of Double Helix, our structures existed in traditional forms - a Hierarchy in case of projects that thought themselves efficient. and for agile, a Scrum structure within a deeply entrenched structure based on designations and seniority. By implementing the Double Helix, we overlaid this structure with Planning teams that cut across designations (from the program manager to entry level trainees) and Execution teams that are mainly peer-level (all managers, all leads, for example). Power shifts from a experience and role basis to the basis of contribution to the respective planning and execution teams. As we will show, this is very similar to the Lean organizations that Japanese manfacturers have adopted.
Our measurements reflect this change. Our efficiency measures indicate the progress made in reducing waste (57% of the project work was non-value add, in the example presented, reduced to 20%) and effectiveness measures show the RFT (Right First Time) and also use feedback from the end-users (defects / fresh Function Point delivered) to measure how effectively the program is delivering value.
We will share how tooling was used to idiot-proof (Poka Yoke) development, especially during steep ramp ups - reducing the time for a new entrant to be productive in a mission critical development project from 45 to 30 days.
Outline/Structure of the Case Study
Several of our key learnings come from observing Nissan and Olympus production teams in Japan. Dealing with a workforce of uneven quality, these companies have implemented a 2 pronged strategy – improvements can come from anyone (as in our Agile retrospectives), but failures and corrective steps are taken by a smaller group of trained personnel. An Andon stops an assembly line, but everyone doesn’t gather around; a team of trained experts in Failure Mode Analysis come together to analyze the failure, provide fixes and implement correctives to prevent recurrence.
We observe that In Agile teams, we romantically bring everyone together for retrospectives without giving them the tools and training to be able to systematically implement the improvements that are captured. Agile brings in the collaboration and cross-teaming that is necessary to deliver value, including a focus on the end goal; Lean brings the rigor that is not explicitly prescribed in Agile. With uneven skills, and target fresher ratios, problems are a natural consequence in IT service companies.
It is now also common to blame Agile project failures on culture; in the Double Helix, we benefit from the Lean principles of respecting current people and practices as an entry point to change, and to prevent rejection of change.
We show that separate Planning (Agile) and Execution (Lean) focused teams provide both the effectiveness and efficiency that clients are demanding today; these practices implemented together lead to a series of upward spirals, connected by common themes or rungs, that allow us to ascend each level, like the stands in a DNA double helix, linked together by common practices and ways of work.
To illustrate our point, we present the case of a $12 Million a year greenfield product development project, where we show the structures before and after the implementation of Double Helix. We also present how each of the changes (planning and execution teams, categorization of personnel into roles, and the bringing in of Agile principles and rituals that instill Agile practices) are brought in; we also show that how an acceptance of traditional ways of work (and an acceptance of effectiveness and efficiency as being either/or, a choice) work against the easy acceptance of Lean Agile.
Our proposed time breakup is as follows:
- Setting up the case study context and problem statement - 5 mins
- Comparison of the issues faced in Lean Agile with other industries (with comparative examples from Japan) - 10 mins
- Applying the lessons to the project presented in this case study (including Planning and Execution structures set up) - 10 minutes
- Presenting results achieved and specific Waste reduction, Poka Yoke and RFT metrics - 10 mins
- Q&A - 10 minutes.
In case additional time is available for Q&A, we will spend 5 additional minutes on parts 2 and 3 each.
There are 3 outcomes we want to deliver:
1. Lean Agile is possible, but needs a structured approach, particularly where the skill levels in the team are varying.
2. Outcome and Execution improvements must be separated, with a different emphasis on each team.
3. Show how Lean and Agile work together to continously improve effectiveness as well as efficiency.
We will take the analogy of a Japanese factory (Nissan) to illustrate that the challenges that we face in dealing with many peers doing the same job, but with uneven skills - who do we choose to include in Planning teams? Execution teams? We then show how we define paths that provide people with differing skills and interests an opportunity to effectively contribute to the program's success, without setting up a rat race where the team members compete for scarce leadership positions.
Anyone tasked with improving their projects - particularly managers, leads and customer facing developers