Many adopting organisations treat Agile like a shiny new project management overlay for development teams and invest their entire energies to extract every ounce of productivity without any significant structural or cultural change to support it. This talk discusses the symptoms commonly found in such large scale product development agile adoptions. With structural and cultural changes being the focal point, the session then describes the principles of Lean Thinking & Agile and how these can be used as growth tools for organisations in such a context. The principles are followed by set of experiments/practices and how each one of these relates to the laws of organisational behaviour and how it influences both culture & strategy. The talk is supplemented with anecdotal observations, experiments that failed and learning from these experiments. Though mostly framework agnostic, the attendees will get some flavor of commonalities between scaling frameworks like LeSS/SAFe/Nexus and would be able to take home some improvements that they can readily apply to set on an inspect/adapt journey of their own.

 
2 favorite thumb_down thumb_up 0 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/structure of the Session

This session outlines the symptoms commonly found in agile adoptions involving multiple product teams where necessary structural and cultural changes are not made to support the transition. The difference between "Doing Agile" vs "Being Agile" is highlighted by tying these symptoms to lack of understanding of underlying principles of Lean & Agile and why these principles matter to the continuous improvement bottom line. The session will then suggest some experiments/practices for attendees that they can use as takeaways. Though mostly framework agnostic, the attendees will get some flavor of commonalities between scaling frameworks like LeSS/SAFe/Nexus and how we can augment "Doing Agile" with necessary structural & cultural changes to "Being Agile".

- Introduction (~5 minutes)
- Symptoms of Dysfunction (~15 minutes)
- Failure-averse Culture
- Individual Appraisals
- Hand offs, Big Batches
- Waste of Variability
- Sprints without PSPI
- etc.
- Organisational Growth Tools (~15 minutes)
- Managers as Teachers
- Adaptive Performance Review
- Feature Teams
- Requirement Areas
- etc. (each tool discussed will be referenced back to underlying principles of lean & agile e.g. feature teams is based on 'removal of queues' managers as teachers based on "Genchi Genbutsu", etc.)
- Suggested Experiments/Practices (~15 minutes)
- Employee Engagement Survey
- Communities of Practice
- Joint Sprint Review
- Unified Product Backlog
- etc.
- Conclusion and Q&A (~5 minutes)

Learning Outcome

Today, many medium and large organisations are taking the Agile route for their product development work. If not implemented properly, nuisances like micro management, local optimisations, contracts designed to transfer blame, dependency hell, overly complex processes/roles and delayed time to market are common sightings. Workforce world-over is split between going back to their traditional project management methodologies, shunting the Agile process entirely or using a half-baked Agile implementation. All of these do not unfold the full potential promised and delivered by simple principles of Agile & Lean.
This talk tries to make amends by highlighting the core issue and the symptoms that attendees can use as litmus test in their own working environments. For practitioners having experienced Agile at a team level and ready to start their journey for Advanced Agility, this session will present underlying principles of Agile at scale . The principles will be complemented with a set of experiments that have worked for a large set of large-scale, multi-site, distributed teams across the globe in variety of industries. Intended audience include traditional functional managers, organisation change agents, Scrum Masters, Product Owners or anyone interested in reducing organisation's cycle time. Equipped with knowledge of underlying principles and their interplay at scale, the attendees should be able to run these experiments with confidence with their own inspect & adapt cycles to make adopt/discard decisions.

Target Audience

Intended audience include traditional functional managers, organisation change agents, Scrum Masters, Product Owners or anyone interested in reducing organisation's cycle time.

Prerequisite

Some experience of applying Agile principles and practices at an enterprise with multiple teams.

schedule Submitted 3 weeks ago

Comments Subscribe to Comments

comment Comment on this Proposal

  • Liked Takahiro Kaihara
    keyboard_arrow_down

    Takahiro Kaihara / Yuichiro Yamamoto - 帰ってきた地獄のデイリースクラム

    100 Mins
    Workshop
    Beginner

    innocent 地獄のデイリースクラムやります!yell

    地獄風景

    スクラムの中でも、比較的とっつきやすいイベント『デイリースクラム』
    しかし、現場ではこんな光景をよく見かけますね・・・?

    • 毎日できていない
    • 時間通りに始まらない
    • 特定の人しかしゃべらない
    • デイリースクラムがお通夜みたい…
    • そもそもやっていない…

    このワークショップでは、そんな悩みを解決いたします!

      『どうやったらデイリースクラムが良くなるの?』
      『スクラムマスターは何をしたら良いの?』

    皆さんと楽しく体を動かしながら、一緒に体験していきたいと思います。

    (名前は怖いですが、内容は恐くないですヨ!)

    Hell Card!!!!!!

    イベント終了後、私たちが知らなかったデイリースクラムの一面を発見出来るかもしれません。

    セッションに採択されましたら、職場で手軽に地獄を味わえる、自作『~地獄のデイリースクラム~ 地獄カード』の配布や『地獄カードデータ』のダウンロードサービスなどを検討いたします!!

    あと!RSGT2018を盛り上げるセッションになるようにがんばります!
    しっかりがんばります!ちゃんとします!

    ~毎日のことだから ちょっとの工夫で大きな差!~


    『地獄のデイリースクラム』とは?

    地獄のデイリースクラムとは、2004年10月にデンバーのScrum GatheringでWilliam C. Wake氏によって行われたチームでデイリースクラムについて学ぶ ことができる「Daily Scrum From Hell」をもとにしたワークショップです。

  • Liked Yoh  Nakamura
    keyboard_arrow_down

    Yoh Nakamura - 「ふりかえり」の始め方と続け方

    20 Mins
    Case Study
    Beginner

    このセッションでは、アジャイルコーチとして様々な現場のふりかえりを観察、ファシリテートしてきた経験から得た“ふりかえり”の始め方と続け方をお話します。

    ”ふりかえり”の目的は大きくは以下の2つです。

    1. 自分達の仕事のやり方をもっとうまくできるようにすること
    2. (うまくできるやり方を考えるために)仕事の手を止めて立ち止まること

    この目的を実現するために様々なことにファシリテートするスクラムマスターは意識することがあります(できれば参加者全員が)。

    • どのようなデータを収集すればよいか?
    • どういう話し合いのやり方をすればよいか?
    • 継続的にうまくできるように気をつけることは何か?

    また以下のような"ふりかえり"あるあるに出会うこともあります。

    • ふりかえりといえばKPTとばかりに同じやり方をしてマンネリしてしまう
    • うまくできるようにするアイデアが実行されない
    • なんとなく続いているんだけど効果がわからない

    このようなトピックをお話することで、みなさんのふりかえりをよくするヒントになればと思います。

  • Liked Takao Oyobe
    keyboard_arrow_down

    Takao Oyobe - Teamwork Revolution - モブプログラミングという働き方 -

    45 Mins
    Case Study
    Beginner

    モブプログラミングとはチーム全員で、同じ仕事を、同じ時間に、同じ場所で、同じコンピューターで行うことです。

    日本においても、2017年に一気に話題となりました。
    そのきっかけとなったモブプログラミングという働き方で紹介した楽天のモブ=チームがその後どうなったのかについてお話します。

    私達のモブでは、時間を決めてワークショップ形式で行うのではなく、朝来てから帰るまで働き方として実施しています。そのため、開発だけでなく資料作りや営業やモブプログラミングの体験会などすべてにおいてモブワークをしています。

    • スクラムを中心としたアジャイル開発を精力的に行ってきたメンバーがモブプログラミングを通してどのように変化したのか
    • 実際に仕事の成果が出せたのか
    • モブとその外の関係性はどうなのか
    • モブ=チームのその後(※今後の活躍次第)

    などについてお話したいと思います。

    スクラムとモブプログラミングは、チーム全体のアプローチやチームビルディングという点で共通項も多い一方で、別の視点で仕事の本質やチームの本質について考えるきっかけになりました。

    モブプログラミングに興味がある方はもちろん、そうでない方にとってもチームについて考えるきっかけを得られるようなセッションにしたいと思います。

  • Liked Harada Kiro
    keyboard_arrow_down

    Harada Kiro - Walking Scrum History with Patterns

    Harada Kiro
    Harada Kiro
    Senior Consultant
    Attractor Inc.
    schedule 2 months ago
    Sold Out!
    45 Mins
    Talk
    Beginner

    Scrum is a set of well-defined rules that enable teams to work effectively to deliver valuable products. Scrum Guide is the rule book of Scrum. You are requested to follow the rules to get benefits of Scrum.

    But why do you need to follow Scrum rules? Scrum says it is crucial to inspect and adapt. So why not inspect how Scrum rules work.

    This session explores the history of Scrum with patterns. The first Scrum paper was published in a form of pattern language. By looking how these patterns have evolved, we hope to see how these Scrum rules are formed and have better understand why they are rules.

    This session concludes with the update of ScrumPLoP.

    This session can also be delivered in Japanese.

  • Liked Rochelle Kopp
    keyboard_arrow_down

    Rochelle Kopp - サーバント・リーダーシップを掘り下げて考えましょう

    45 Mins
    Talk
    Beginner

    スクラムやアジャイルソフトウェア開発の関係で「サーバント・リーダーシップ」という言葉を良く耳にする人も多いかと思いますが、しかし実際具体的にサーバント・リーダーはどのような特性を持っていて、どのように行動しているか等について聞くチャンスはあまりないのではないでしょうか。

    このセッションでは、サーバント・リーダーシップの詳しい定義、またサーバント・リーダーのスキルを向上させる方法について紹介します。尚、サーバント・リーダーシップに関して、日本のマネージャーのどのような面がこれに適しているのか、そしてどの側面に改善する余地があるのかについてもお話しします。

  • Liked kyon_mm
    keyboard_arrow_down

    kyon_mm - Scrumが難しいのは幻想 -情熱の再定義-

    kyon_mm
    kyon_mm
    Test Architect
    オンザロード
    schedule 1 month ago
    Sold Out!
    45 Mins
    Experience Report
    Intermediate

    私達のチームは2016年までメトリクスの活用、スプリント期間の短縮、くじ引きで決めるPOやSM、などのプラクティスを通して改善を繰り返してきました。スクラムガイドもどんどん破りました。

    このチームはScrumが難しいなんて思っていませんし、誰でも出来ると信じています。

    チームが開発する製品は大きく変わりましたがScrumが難しいなんてことはありませんでしたし、

    なによりこのチームのエッセンスを大学生40名に導入したところなんと1週間で1日スプリントをモノにしました。Scrumが難しいのは幻想だったのかもしれません。

    我々のチームはこういったことを通して2017年にいくつかのプラクティスを確立しました。スプリント期間は1時間へ、チーム内ボトルネックへの対応時間は25分以内を保証、人的リソース活用の損益分岐点を常に意識できる開発プロセスです。

    結果、1週間でレビューを35回以上、振り返りを30回以上行っています。1週間で改善した項目は最大で20アイテムにおよび、それらのムダ取りによって6ヶ月間で最大2倍の成果を生み出しています。

    チームのパフォーマンスを最大化するために私達の計画的な学び方、偶発的事象からの学び方などをScrumの文脈でご紹介します。

  • Liked Iwao Harada
    keyboard_arrow_down

    Iwao Harada / Masakazu Takasho - Smug? Oyatsu Shrine ~ Improvement patterns seen through practicing "Oyatsu Shrine" ~ どや!?オヤツ神社 ~実践しているオヤツ神社を通して見る改善パターン~

    20 Mins
    Experience Report
    Beginner

    2017.10.25 update Clarified session contents
    2017.09.23 update 45min→20min
    2017.09.25 update Translate title to English. But I will speak in only Japanese this program, sorry.


    "Oyatsu Shrine" is the pattern that is published in Scrum PLoP.
    Scrum PLoP → oyatsu-jinja

    "Oyatsu Shrine" is being conducted at various GEMBA as a team communication tool. However, it is also a self-organizing activity base that teams can manage and improve on their own.

    Listen to how everyone practices "Oyatsu Shrine" on the GEMBA and feel the pattern.

    オヤツ神社とは、Scrum PLoPで挙げられているパターンです。

    チームのコミュニケーションツールとして色々な現場で行われているお手軽な「オヤツ神社」ですが、チームが自分自身で管理・改善できる自己組織的な活動拠点でもある奥が深いものです。

    また、オヤツ神社の運営は簡単ではありません。現場もいろいろあるので、神主がどのようにオヤツ神社を実践しているかを聞いて、パターンの一端を感じてもらいつつ、明日には現場で“上手くいく”オヤツ神社を設置できるようになる発表にする予定です

    最後にはみんなでオヤツ神社を建ててグランドフィナーレを迎えます。カッコいいオヤツ神社を建てられる技術はスクラムチームで働く我々にとっては必須スキルです。

  • Liked Tatsuya Kinugawa
    keyboard_arrow_down

    Tatsuya Kinugawa - アジャイル開発をさらに進化させる組織KPI導入のすすめ

    Tatsuya Kinugawa
    Tatsuya Kinugawa
    General Manager
    Rakuten
    schedule 1 month ago
    Sold Out!
    20 Mins
    Experience Report
    Intermediate

    楽天において複数の新規・中規模サービスを担当しているECインキュベーション開発部を担当しています。配下組織の多くがアジャイル開発を導入していて、数年経過しました。

    アジャイルプロセスが進行すると改善は自然と開発に組み込まれますが、最近この進化の度合いが緩やかになり、一段上の組織を目指すには工夫が必要ではないかと思い至りました。

    その課題に対して部署横断の組織KPI目標を導入した結果、アジャイルの改善に期間テーマを付与すること、またその成果を共有による相乗効果を創出することが出来てきています。

    この事例の紹介とともに、複数アジャイル開発組織の運営において現在取り組んでいることを紹介できればと思います。

  • Liked Mohammad Nafees Butt
    keyboard_arrow_down

    Mohammad Nafees Butt - A Toolset for Creating a Potentially Releasable Product Increment

    Mohammad Nafees Butt
    Mohammad Nafees Butt
    Lead Consultant
    Elabor8
    schedule 3 weeks ago
    Sold Out!
    45 Mins
    Talk
    Beginner

    Working software is one of the four Agile values. However, Agile practitioners today are seen following anti-patterns like special sprints for integration, leaving regression testing to special QA focus groups etc. This talk will set the stage by defining the context leading to such decisions. and indicative symptoms. This talk will conclude with recommendations to address the anti-patterns described earlier. Narratives, real-world examples and lessons learned from actual experience would be provided for the audience as key takeaway.

  • Liked Pondd Suwitcha Sugthana
    keyboard_arrow_down

    Pondd Suwitcha Sugthana - MASTERING CUSTOMER JOURNEY: creating artifact to bind the team

    20 Mins
    Talk
    Beginner

    "What are we building? And why?"

    "I need this info! Where do I get it?"

    "I've got a lot of user research, what's next?"

    Chances are you will hear these words from your team many times in any project.

    Is your team making wasteful decisions because they didn't have a common understanding - especially across different roles? Is your team slowing down because the knowledge and decisions are owned by just a few key people? And what if some of these key people who own the knowledge take a vacation when you most need them?

    In this talk you will learn how convert all the great user insights you gathered and discovered into easy and actionable items that your team can use to move your project forward.

    You will learn to:

    - Externalise knowledge from your team
    - Consolidate and align vision
    - Create a core onboarding journey
    - Make better user of empathy
    - Understand "as-is" state and how to drive to an ideal "to-be" state

  • Liked Kazunori Morita
    keyboard_arrow_down

    Kazunori Morita - 『ベヨネッタ2』におけるゲーム品質を上げる為の自動化 ~オートプレイと継続的なパフォーマンス計測~

    Kazunori Morita
    Kazunori Morita
    QA Engineer
    PlatinumGames Inc.
    schedule 1 month ago
    Sold Out!
    45 Mins
    Case Study
    Beginner

    関西で開催されましたゲームクリエイター向け大規模勉強会 GAME CREATORS CONFERENCE '16 や、日本最大のゲーム開発者向けカンファレンス CEDEC 2016、地方開催 CEDEC+KYUSHU 2016 にて講演させて頂きました3Dゲームにおける自動化の講演となります。

    開発者ブログでの記事公開が2014年という事で技術的にも古い内容とはなりますが、
    少ない作業時間の中から作成し最大限効果を出したオートプレイ。

    品質を上げる為の継続的なパフォーマンスチェックと、そのデータの見える化への技術選定と運用について

    必要な最低限の機能を「小さく素早く実装」したお話させて頂きたいと思います。

  • Makoto Takaesu
    Makoto Takaesu
    CEO
    Studio LJ, Inc.
    schedule 1 month ago
    Sold Out!
    45 Mins
    Tutorial
    Beginner

    アジャイル開発を実践、導入支援、他のコーチとの交流の中で蓄積された、雑多な小ネタを集めました。

    今の現場にそのまま導入するもよし、何かと入れ替えるもよし、自分たち流にアレンジするもよし、お好きな感じで使ってもらえればと。

  • Liked Kazunori Morita
    keyboard_arrow_down

    Kazunori Morita / Masahiro Taguchi - ゲーム開発現場の中心で心理的安全性を叫ぶ

    45 Mins
    Case Study
    Beginner

    何かを変えようと思っている。勉強会を開いてみたい。学んでみたい。

    そんな事を考えるスタッフは社内にいると思いますが、「言って怒られたらどうしよう」「勉強会を開くのは、ちょっと怖い」などが頭をよぎり、一歩踏み出せない状況にいるスタッフがいるかもしれません。

    本セッションでは、周りを巻き込み継続し次につなげれるような心理的安全性を確保する活動の、想い、経過、時期に応じた対応に関してお話できればと思います。

  • Liked Tatsuya Sato
    keyboard_arrow_down

    Tatsuya Sato - THE ONE - ヒトリからヒトツへ

    Tatsuya Sato
    Tatsuya Sato
    Software Developer
    Rakuten, Inc.
    schedule 1 month ago
    Sold Out!
    20 Mins
    Case Study
    Beginner

    One for All, All for One, To become The One

    - LIVE AT WEMBLEY / BABYMETAL

    登壇者は、スクラムでの開発を続けた後、ひとりでの開発、そしてモブプログラミングのチームで働くという経験をしてきました。また、現在ではモブプログラミングの原型から離れ、一見バラバラに見えつつも、ひとつの共通認識を持ちながら道なき道を突き進んでいます。本セッションでは、この経験を元に、両極端なひとりぼっちの開発とモブでの開発のそれぞれの良いことと悪いことをエンジニアの視点から紹介します。

    このセッションに参加した人が、ひとりでの開発ではなく、チームでの開発を望むようになっていただければ幸いです。

  • Liked Daisuke Watanabe
    keyboard_arrow_down

    Daisuke Watanabe - Scrum One on One / 自律的なチームを育む実践知「1on1」コミュニケーション

    20 Mins
    Case Study
    Beginner

    「最高の開発チームをビルドしたい、開発現場をよりよくしたい!」

    日々そう考えている皆さんと同じく、Gunosyの開発チームでも様々な課題を解決しながら組織のスケールアップを試みています。このセッションでは、私たちがプロダクト開発全体の価値の最大化の為に重視して実施している実践知「1on1」についてお話します。

    LeSS (Large-Scale Scrum)において、Scrumでは珍しく、マネージャーの役割についての記述があります。「マネージャーはプロダクトの一部だけを見るのでは無く、プロダクト開発全体の価値提供を見る。現地現物GoSeeによりプロダクト開発の改善を推進する事である」と提起されています。

    いわゆる上司と部下の「1on1」と、スクラムの流儀から実践知リーダーの自律的なチームを育む手段としての「1on1」。

    ここから生まれた課題と、それを乗り越える際に重視したポイントをご紹介します。

    LeSS、アジャイルコーチングの観点からの1on1手法、心得、改善の記録を紹介しながら、
    「1on1」をスクラム、コーチング、マネジメントとどのように協調させると最もプロダクト開発全体の価値提供につながるのか、皆さんと一緒に考えていきたいと思います。

    私たちの取り組みが、皆様の開発現場での改善の一助になれば幸いです。

  • Liked Tomonari Nakamura ( ikikko )
    keyboard_arrow_down

    Tomonari Nakamura ( ikikko ) / Yoh Nakamura - 2人のアジャイルコーチが語る、とある現場支援の回想録

    45 Mins
    Case Study
    Intermediate

    このセッションでは、ある現場の社内アジャイルコーチと、その現場を外部から支援するアジャイルコーチ、2人のアジャイルコーチの視点でお話します。

    社外のアジャイルコーチに支援してもらうとき、支援した方・された方、片方の視点からの事例を聞くことはありますが、案外双方の立場からの意見を聞くことは多くありません。ですが、ある一場面をとっても、お互い見えているものや感じていることは違うはずです。

    本セッションでは、社外のコーチにチームの支援を最初に相談した時・改善の踊り場に来た時といった各場面で、双方のアジャイルコーチは何を見てどんな行動を起こし、どういう結果となっていったかをお話します。

  • Liked Yuki Kubota
    keyboard_arrow_down

    Yuki Kubota / Tsutomu Asanuma / Yuki Kubota - 超ド級エンタープライズ企業のスクラム内製開発組織立ち上げ物語 ~0を0.1にするまで~

    20 Mins
    Case Study
    Beginner

    外部パートナーの開発管理しかしたことの無いメンバーを集め、内製開発組織立ち上げを、しかもスクラムで挑んできた経緯を、お話します。

    メンバーの意識は、どう変わっていったのか?

    モチベーションや情熱を、どう維持してきたのか?

    組織内でのマイノリティ軍団が、どう成果を挙げていったのか?

    独学で内製開発を始め、なぜ失敗したのか、なにが原因で、どう解決していったのか? 

    について、共有できればと思います。

    企業文化などから、すごく新たな文化を適用させにくい組織でも、文化やメンバーの意識は、必ず変えられる。そのためのツールとして「スクラム」について、何かのヒントをお伝えできればと思います。

  • Liked Masatoshi Endo
    keyboard_arrow_down

    Masatoshi Endo / Masahiro Kimura - モブプログラミング始めました

    20 Mins
    Experience Report
    Beginner

    2017/9/10 楽天の及部さんをお招きしてモブプログラミングを教えて頂き、2ヶ月。
    https://agile-no-wa-tochigi.connpass.com/event/65695/
    自分のチームでもモブプログラミングを実施するようになってきました。

    2015年にScrumチームが発足し、一時顧客の要望直ぐに答えることができ、
    更にチームとして活動することの重要性を学び、盛り上がりを見せたものの
    2016年からはマンネリ化してきて、活動も下火に。
    そんな中モブプログラミングが再びチームに火を灯してくれました。

    モブプログラミングが全ての解では無いですが、
    実施するメリットが大いにあると感じています。

    ソロワークしか知らなかったメンバーと共にモブプログラミングを通して、
    学んだ事を紹介します。
    属人化が進んでいてモブプログラミングなんて、と思っている方の
    心のハードルを下げたいと思います。