Organizations invest energy, effort and real dollars to stay in trend. Here's one of the trend: Agile is no longer a buzz word, Scaling Agile is. Terms like Enterprise Agile, Scaled Agile, SAFe, LESS, DAD, Agility Path are conveniently thrown around in meetings and speeches as organizations line up to get on the bandwagon of 'Scaling Agile'. Scaling Agile - from the team and product level to the organizational level has it's own benefits and challenges. Is scaling Agile right for you? Are you ready for it? If you've been thinking of scaling, you might be in luck. In this session, we will discuss grounds up approach of how to analyze and evaluate if an organization (or a business unit) is ready for scaling Agile. You'll create your own set of evaluation criteria specific to your organization's situation and learn steps your organization can take to be more prepared for scaling Agile and reap organization-wide benefits. The focus will remain on your context and not on promoting any particular scaling framework.

        "Scaling. Its about the context not the process." - Jeff Sutherland

PS: This will be a no slides, hands-on workshop. Be prepared to actively participate throughout the session.

 
1 favorite thumb_down thumb_up 6 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/structure of the Session

- Introduction of the topic: 4 min

- Analysis of Scaling Factors Part I: 10 min

Here are quick highlights of the factors around which the coversation will revolve. With these points, audience will, based on their situation and context, create their own Scaling evaluation:

1- Why Scale (the vision, goals and challenges faced specific to their organization)

2- Organizational Structure [Hirerchical v/s Flat organizational structure, Collaboration/Silos between departments/teams, Range/Number of teams working on large programs]

3- Organizational Culture [Strategic Decision making mechanism/Politics, Culture of oragnic adoption of bright ideas v/s Process Police trying to impose (Buddhism - Catholicism), Transparency of communication, Be Innovative v/s Seek Approvals]

4- Management Agility [Centralized v/s De-centralized decision making - funding, hiring, process adoption, Portfolio mangement approach]

5- Automation [Engineering Practices - CI, CD, Unit testing, build and deployment, reporting]

6- Quality [Customer interaction, why the developers type in bugs, waste, why hardening, code merges]

7- Product Owner and the Backlog - [Strong, Expert and Available PO, READY backlog]

8- Agile/Lean Thinking and Training [untrained pilots in the cockpit, we all speak no Americano]

- Review of each factor and selection of criteria Part I: 10 min (done among the teams)

- Analysis of Scaling Factors Part II: 10 min

- Review of each factor and selection of criteria Part II: 10 min (done among the teams)

- Consolidation and Presentation: 10 min (If 20 - 40 # of participants -> each team will present for 2 minutes, if 40+ participants -> few teams who volunteer / randomly picked will present)

- Q&A: 6 min

Learning Outcome

- Differences between agile implementations at the team level and the organization level

- Key factors to consider when planning to scale your agile implementation

- Identify analysis criteria unique to your organization's situation

- Take away a framework to your organization that could help with Scaling

- PS: This session is framework agnostic and no particular Scaling framework will be given preference over others.

Target Audience

Leaders, Managers, ScrumMasters, Product Owners

Requirements

- Flip Chart Paper (1 per 5 attendees)

- Sharpies (1 per attendee)

- 5" x 7" index cards (5 per attendee)

schedule Submitted 2 years ago

Comments Subscribe to Comments

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

    Can you please highlight some scaling factors that you are refering to? Is there a link where I can read more about it?

    • Kamlesh Ravlani
      By Kamlesh Ravlani  ~  2 years ago
      reply Reply

      Hi Naresh,

      Here are quick highlights of the factors around which the coversation will revolve. With these points, audience will, based on their situation and context, create their own Scaling evaluation:

      1- Why Scale (the vision, goals and challenges faced specific to their organization)

      2- Organizational Structure [Hirerchical v/s Flat organizational structure, Collaboration/Silos between departments/teams, Range/Number of teams working on large programs]

      3- Organizational Culture [Strategic Decision making mechanism/Politics, Culture of oragnic adoption of bright ideas v/s Process Police trying to impose (Buddhism - Catholicism), Transparency of communication, Be Innovative v/s Seek Approvals]

      4- Management Agility [Centralized v/s De-centralized decision making - funding, hiring, process adoption, Portfolio mangement approach]

      5- Automation [Engineering Practices - CI, CD, Unit testing, build and deployment, reporting]

      6- Quality [Customer interaction, why the developers type in bugs, waste, why hardening, code merges]

      7- Product Owner and the Backlog - [Strong, Expert and Available PO, READY backlog]

      8- Agile/Lean Thinking and Training [untrained pilots in the cockpit, we all speak no Americano]

       

      Thanks,

      Kamlesh

    • Prasad
      By Prasad  ~  2 years ago
      reply Reply

      Kamlesh,

      Scaling Agile, Enterprise Agile is the hot topic of the season. There are multiple proposals in similar lines. How are going to differntiate. As Jerry mentioned it is critical to get battel field experience, lessons learnt, KPI, impacted metrics, patterns found..

      ~PP

      • Kamlesh Ravlani
        By Kamlesh Ravlani  ~  2 years ago
        reply Reply

        Hi Prasad,

        Yes, the topic is hot and I'm sure there are many proposals. My session is designed to address only one specific area, that is to help the audience to assess for themselves how ready are they (and their organization) to scale their Agile implementation. In fact during the session they'll create their own assessment based on their own context.

        Targetted audience = Those are evaluating whether to jump on to Scaling bandwagon or not yet. If someone is already implementing any of the scaling frameworks, they'll attend other sessions.

        Should you've any specific input to address a particular aspect, I would be glad to discuss/incorporate.

        Thanks,

        Kamlesh

    • Jerry Rajamoney
      By Jerry Rajamoney  ~  2 years ago
      reply Reply

      Hi Kamlesh,

      Thanks for this proposal. Are you going to touch upon any past experience you had in scaling scrum, how you choose one over other, pitfalls from a real time perspective too?

      Thanks,

      • Kamlesh Ravlani
        By Kamlesh Ravlani  ~  2 years ago
        reply Reply

        Hi Jerry,

        Thanks for your comments. Yes, while discussing the factors I'm drawing it from my experience and hence mention of what we felt/faced will definitely be there depending on the context and need. My primary focus would remain on helping the audience to think through the factors within their own context by sharing my context (to some extent).

        To be clear, I'm not advocating any particular scaling framework during this session.

        Thanks,

        Kamlesh


    • Liked Yuval Yeret
      keyboard_arrow_down

      Kanban - A Way Towards DevOps in the Legacy Enterprise

      Yuval Yeret
      Yuval Yeret
      schedule 2 years ago
      Sold Out!
      45 mins
      Talk
      Beginner

      DevOps is a higher form of agility. It is a blueprint for a great culture and and process between the different groups involved in the delivery pipeline. The big question is how to achieve it. If you are founding a startup today, it can be quite easy to take that blueprint and use it to create your process, hire the right versatile flexible people, and start delivering without any technical/automation debt or friction. But most of us are not founding new startups. Most of us already have a running operation with people, culture, process that matured over the years and despite its flaws is currently the way we do things. Changing that is non-trivial. For things to change people need to understand WHY change, what we are changing, and we need an effective process for managing the change itself (HOW to change). So what ARE we changing to? DevOps is highly focused on looking at the whole value stream from idea to value and ensuring effective flow through this pipeline. Kanban is ONE way of HOW to change. It starts by visualizing all the work flowing in the pipeline, then managing the flow focusing on finishing things end to end rather than starting in order to stay busy. It continues to what we call the “Work in process Diet” – Straining the flow more and more in order to identify obstacles to tighter and tighter DevOps culture/operation and faster feedback cycles. You can expect to come out of this session with ideas how to take your current operation and DevOpsify it in a safe evolutionary way using the Kanban method.

    • Liked Diana Larsen
      keyboard_arrow_down

      Coaching for "Best Fit" Agile: Applying the Agile Fluency(™) Model

      Diana Larsen
      Diana Larsen
      schedule 2 years ago
      Sold Out!
      480 mins
      Workshop
      Intermediate

      Agile has a problem. When we started out with Agile, people used it because it made their lives and products better. Now people complain that Agile is about meetings, top-down mandates, and wasting time. We can do better. It’s time for a change.

      In response, Diana Larsen and James Shore developed The Agile Fluency™ Model and Martin Fowler published it, “Your Path Through Agile Fluency” (http://agilefluency.com). The model describes how teams grow in their understanding of Agile over time. It's a descriptive model, because it reflects what happens in the real world, and in it's an aspirational model, because you can use it to understand how to invest in improving your teams.

      We've found the model very useful for helping teams, managers, and executives understand what they can get from Agile and what they need to invest in order to get those results. The model's emphasis on concrete outcomes means executives are open—even eager—to devote the effort needed. Leaders appreciate being able to see the tradeoffs and make a strategic decision, and teams thrive when given meaningful goals and the time and resources needed to achieve them.    

      In this workshop, led by Diana Larsen, together we’ll dig deeper into the model, including:

      -       Agile Fluency Model Overview

      -       Bringing Agile Fluency into your organization

      -       Examples of Agile Fluency in real-world teams

      -       Examples of organizational investments

      -       Supplemental materials for metrics and assessments

      -       Agile principles and practices in the model

      -       New directions and support for the Agile Fluency Model

    • Liked Mark Lines
      keyboard_arrow_down

      Disciplined Agile Delivery: The Foundation for Scaling Agile

      Mark Lines
      Mark Lines
      schedule 2 years ago
      Sold Out!
      60 mins
      Keynote
      Intermediate

      Organizations are applying agile strategies with large teams, geographically distributed teams, in outsourcing situations, in complex domains, in technically complex situations, and in regulatory situations.  Sometimes they’re successful and sometimes they’re not.  The Disciplined Agile Delivery (DAD) decision process framework is a people-first, learning-oriented hybrid agile approach to IT solution delivery. It has a risk-value delivery lifecycle, is goal-driven, is enterprise aware, and is scalable. The DAD framework is a hybrid which adopts proven strategies from Scrum, XP, Agile Modeling, Outside-In Development, Lean/Kanban, DevOps, and others in a disciplined manner.  In this presentation you’ll discover how DAD provides a solid foundation from which to scale agile, learn how agile teams work at scale, and identify several common scaling anti-patterns which should be avoided.