• Liked Avinash Rao

    The Double Helix Model for Lean Agile

    Avinash Rao
    Avinash Rao
    schedule 2 years ago
    Sold Out!
    45 mins
    Case Study

    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.

Sorry, no proposals found under this section.