Bringing innovative and breakthrough ideas to market doesn't have to slow down due to multiple geographies and scale of product development. In fact that's an added reason to be agile, test the product-market-fit early and reduce risk. 
 
How can organizations benefit from being Agile at Scale For Innovation and Growth? 
 
What are the wastes in the traditional organizational structure at scale? and What does it take to build customer value delivering feature teams?
 
We'll dissect a case-study, Kamlesh Ravlani - the presenter, was involved with and learn how Google brought one of their innovative idea rapidly to market that involved multiple partners and teams in multiple geographies.
 
3 favorite thumb_down thumb_up 8 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/structure of the Session

This session is a combination of presentation, case-study and a 3 step simulation.

Introduction (5 min)

Large Scale, Multi-Site, Multi-Partner Product Development Case Study Part I (10 min)

 

(Lean) Wastes in Traditional Product Development at Scale (10 min)

Identifying and Eliminating Product Development Wastes Simulation: (30 min)

  -> Step 1: Component Teams will be formed to deliver a simulated product, sequentially

  -> Step 2: Component Teams will deliver the simulated product with the help of an integration team

  -> Step 3: Feature Based Team will be formed to deliver the simulated product

  -> Debrief

How to structure Value Delivery with Feature Teams (10 min)

Innovation at Scale and Growth - Case Study (continued) Part II (10 min)

Mapping the redesign of Team Structure from Component to Feature Based Teams (10 min)

Q&A (5 min)

 

Learning Outcome

  • Understand the core organizational structure that enables agility in product development at scale
  • What does it take to build value delivering Feature Teams
  • Learn how Google rapidly experiments new and breakthrough ideas
  • How to be Agile and rapidly adapt to changes
  • Ways to seek user feedback when your ideas can't be shared with the world yet

Target Audience

Leaders, Agile Coaches, Product Owners, Scrum Masters, Anyone tasked with leading New Product Development at Scale,

schedule Submitted 1 year ago

Comments Subscribe to Comments

comment Comment on this Proposal
  • Kamlesh Ravlani
    By Kamlesh Ravlani  ~  9 months ago
    reply Reply

    Hello Reviewers,

     

    I got chance to present this session (60 min presentation, without simulation) at the Agile Tour - Pune earlier this month. Approx 35-40 participants attended the session. 6-7 participants specifically came up at the day end retrospective to mention that they found the session valuable and the questions discussed during the session to be thought provoking.

     

    The session facilitator also mentioned that the questions I raised were insightful and that he plans to use those questions in his coaching work with clients.

  • Jutta Eckstein
    By Jutta Eckstein  ~  11 months ago
    reply Reply

    Hi Kamlesh,

    I share the concern of the other reviewers. Thus, can you please elaborate the outline of the workshop. How exactly do you want to spend the 90 minutes? The way your session is described right now, I can only imagine you're filling 45 minutes - and maybe that's the way to go?

    Thanks,

    Jutta

    • Kamlesh Ravlani
      By Kamlesh Ravlani  ~  11 months ago
      reply Reply

      Hi Jutta, Thanks for your review and feedback.

      I've updated the outline of the proposed session.

      Can this session be presented in 45 minutes? Yes, however, without the simulation and the Component to Feature Team mapping.

      The simulation helps drive the point home with the participants. And the mapping (last point) provides next action steps to participants who may be interested in analyzing/implementing what they learn at the session.

      I would be happy to accommodate your ideas and tailor the session length.

      Thanks,

      Kamlesh

      • Jutta Eckstein
        By Jutta Eckstein  ~  11 months ago
        reply Reply

        Thanks, Kamlesh!

        This is helpful!

        Cheers,

        Jutta

  • Tathagat Varma
    By Tathagat Varma  ~  11 months ago
    reply Reply

    Is the presentation around a public-domain understanding of how Google does product development, or is it your own personal experience at/with Google? Also, it will help to get a bit more detailed breakdown of your proposed workshop.

    • Kamlesh Ravlani
      By Kamlesh Ravlani  ~  11 months ago
      reply Reply

      Hi Tathagat, Thanks for your review.

      The case study I present is my own experience, not the public domain information about Google.

      I've updated the workshop outline, hope that helps.

      Thank You,

      Kamlesh

  • Madhavi Ledalla
    By Madhavi Ledalla  ~  11 months ago
    reply Reply

    Hi Kamlesh, Thank you for your interest in Agile India 2017. Could you please elaborate on the outline/ structure of the workshop and the 3-step simulation that you mentioned. This would help us understand the workshop structure in detail. Thank you.

                                                                        

    • Kamlesh Ravlani
      By Kamlesh Ravlani  ~  11 months ago
      reply Reply

      Hi Madhavi - Thanks for your review. I've updated the outline and listed the simulation steps. The 3 step simulation is adapted from the workshop I facilitated at a conference - a video link is shared above. If you would like to watch the sample of the simulation watch the video from 00:56:30 to 01:09:00.

      I would be happy to answer any further clarification you may require.

      Thanks,

      Kamesh


  • Liked Vishal Prasad
    keyboard_arrow_down

    Vishal Prasad - SLICE - The Experimentation Framework

    Vishal Prasad
    Vishal Prasad
    Project Manager
    Springer Nature
    schedule 11 months ago
    Sold Out!
    45 mins
    Talk
    Intermediate

    Agile Principle # 12 defines that at regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. From Scrum to Kanban and other agile frameworks, this is accomplished through retrospectives and continuos improvement processes. The key to being a successful agile practitioner is to identify areas of improvement and then experiment ways of improving it. But it doesn't stop there; positive improvements ultimately become success stories for other teams and motivates them to experiment with newer ideas which eventually leads to innovation. A negative outcome isn't bad either since it adds to the experience of situations where ideas may not apply. Thus the key to this process lies in being a child, an explorer, and inculcate an experimentation mindset. The SLICE framework addresses this in the following way:

    • S hare: Share an area of improvement
    • L earn: Explore the area for ways of improvement
    • I mplement: Search & apply the learning to identify the success factors
    • C ollateral: Publish blogs, white papers, presentations, etc. as observations of the implementation
    • E xpansion: Grow, Seed, and Split in order to explore new venues for success

    In this workshop, I create an environment that inculcates an experimentation mindset and utilize the SLICE framework to drive the exploration.

  • Vishal Prasad
    Vishal Prasad
    Project Manager
    Springer Nature
    schedule 11 months ago
    Sold Out!
    45 mins
    Workshop
    Intermediate

    Technical debt is a very common phenomenon; in fact it occurs with virtually every line of code whether you want it or not. Although unoptimized coding due to the rush presented by management pressure may be one of the major reasons for technical debt, it occurs in various flavors based on the nature of execution. Sometimes, even the best written code may run into debt by introducing a minimalistic change in the business definitions, e.g.: a variable name that makes no sense anymore.

    This debt cause and effect is exponentiated when scaled teams come into play. In many cases these teams are distributed and an optimized code for one team may become a debt for another. These debt dependencies between teams is what creates the "Valley of Debt". Unfortunately these cannot be avoided but good engineering practices coupled with lean principles may keep them confined for long enough in order to push the validity of software applications.

    Sooner or later, the cost of change will outweigh the benefit of an application and turn it into legacy; the challenge is to keep it as far as possible by slowing down the fall into the valley of debt. In this (non-PPT) interactive workshop, we will witness first hand how debts are introduced and how these can be confined by utilizing good engineering practices coupled with lean principles.

  • Liked Manish Agrawal
    keyboard_arrow_down

    Manish Agrawal - Are “You” part of a Self-Organizing team?

    45 mins
    Talk
    Intermediate

    “People who contribute out of love for the work, shared vision and team camaraderie will surely
    out-innovate people who think otherwise.”

    With increasing popularity of Agile, Scrum, and Kanban, a lot of awareness is already out there, and much has been written about self-organizing teams.
    Still, I always felt there was some disconnect. It somehow didn't match my own first-hand experience of becoming self-organized team (since, nobody made us self-organized, but collectively as a team we became one.)

    Thinking deeper on it, I realized that the disconnect exists in the point of view (PoV),  since topic of "Self-Organizing team" is presented as a characteristic of Scrum from Scrum Master’s PoV, whereas “Self-Organization” should come within the team from their own awareness, will, effort, understanding, learning, and evolution.
    Self-Organizing is about the team determining how they will respond to their environment.

    So I felt there is a need to present this topic in a way that, members of the team can see it from their own PoV and realize the need, benefits, importance, essentials, attributes of a “Self-Organizing”.

    During this talk, we will see this topic mainly from Agile / Scrum teams perspective. Also we will touch base on role of other entities (like Scrum Master, Senior Management and Organization) in making of "Self-Organizing team".

  • Liked AnkitTandon
    keyboard_arrow_down

    AnkitTandon - Agile contracting- Starting with the right mindset

    AnkitTandon
    AnkitTandon
    Scrum Master
    Citibank
    schedule 11 months ago
    Sold Out!
    45 mins
    Workshop
    Executive

    One of the biggest challenges in achieving agility is the way contracts are written. More often than not, these contracts prove to be a deterrent to realize the ultimate benefits of Agile. The way contracts have done traditionally usually go well with the traditional way of building software where scope / time / cost are fixed. However when the focus is on delivering business value early to the customer for his competitive advantage, to reduce risk, cost by not building what is not needed, gain and retain users, traditional contracting does not help the cause. Agile is something that the entire organization has to embrace. It has to start with the sales team. It has to reflect in the contract. It has to start with the right mindset. It has to start with an Agile contract.

    Third value of Agile manifesto is Customer collaboration over contract negotiation. Not only should this collaboration be expressed during project development, it should be expressed in the contract language as well.

    In this talk + workshop session, I will be sharing various types of contracts that can be leveraged / customized for an Agile project, some good practices surrounding them and will be involving the participants into a small workshop of writing Statement Of Work (SOW) for Agile contracts related to a few real world scenarios.

  • Liked AnkitTandon
    keyboard_arrow_down

    AnkitTandon - Performance management in Agile: Time to plug the hole

    AnkitTandon
    AnkitTandon
    Scrum Master
    Citibank
    schedule 11 months ago
    Sold Out!
    45 mins
    Talk
    Intermediate

    Principles behind traditional performance management system are utterly opposite to that of Agile. While traditional one focuses on Individual ratings, surprises, one sided evaluation, Agile is built on the foundation of trust, transparency, respect and courage. Whole is greater than sum of its parts and individual ratings and outdated performance management processes may prove to defeat the bigger purpose. While aspiring for Agility both at team and organization level, it is important to ensure all the wheels are moving in tandem in the same direction. Technology has changed the way our people engage, work and communicate and the need for frequent and less formal points of progress reviews is in demand.

    Agile performance management is an attempt to plug the hole by providing an approach that compliments Agile values and proves to be a catalyst than detractor for a high performing team and organization.