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 Session

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. 

 

Learning Outcome

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.

Target Audience

Anyone tasked with improving their projects - particularly managers, leads and customer facing developers

Requirements

A projector. Participants just bring themselves, we will get their attention!

schedule Submitted 2 years ago

Comments Subscribe to Comments

comment Comment on this Proposal
  • Naresh Jain
    By Naresh Jain  ~  2 years ago
    reply Reply

    Avinash, uneven skill levels is a big problem at many companies. So this topic would certainly be appreciated by many. Just need a couple of clarifications:

    • Is this based on real experience across multiple projects? If yes, can you take one of your recent project and present this as a case-study? Before and After kind of case study with relevant examples?
    • Can you highlight key challenges you faced?
    • Can you list down what are your key recommendations on how to deal with uneven skill levels?

    If this makes sense, please update your proposal.

    • Avinash Rao
      By Avinash Rao  ~  2 years ago
      reply Reply

      Hi Naresh, thank you for your comments - I have updated the proposal. From the multiple projects where we are implementing the Double Helix, we will pick a $12M/year greenfield product development to present as a case study. For the pitfalls, we will also use examples from our Support and Mixed Support / ADM projects.

      Please let me know if you would like to see any other details.

      thanks,

       

      Avinash

      • Naresh Jain
        By Naresh Jain  ~  2 years ago
        reply Reply

        Thanks Avinash. This sounds very interesting. Can you please share some more concrete details around the structures before and after the implementation of Double Helix? Also what were specific, quantifiable improvements you saw with this approach?

        P.S: I noticed that the session type is still Talk, can you please update it to case-study?

        • Avinash Rao
          By Avinash Rao  ~  2 years ago
          reply Reply

          Hi Naresh, the Outline / Structure has become rather lenghty, so updated the structural changes and quantitative improvements in the Abstract section. Also, updated the Type to Case Study. Thanks!

          • Naresh Jain
            By Naresh Jain  ~  2 years ago
            reply Reply

            Thanks Avinash. Can you please give a timewise breakup of what you plan to cover in 45 mins? I see a lot of interesing points, but not sure about the flow and how you'll cover them.

            • Naresh Jain
              By Naresh Jain  ~  2 years ago
              reply Reply

              Hi Avinash, any update on this?

              • Avinash Rao
                By Avinash Rao  ~  2 years ago
                reply Reply

                Hi, here is our proposed time breakup:

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

  • Pramod Sadalage
    By Pramod Sadalage  ~  2 years ago
    reply Reply

    Avinash,

     

    Would you be able to post a work in progress deck of your proposal for us to understand the scope of the proposal.

    Thanks

  • Tathagat Varma
    By Tathagat Varma  ~  2 years ago
    reply Reply

    Avinash - can you share the deck for the topic that you have proposed so that reviewers can take a call on your proposal?

    -TV