最近、システムコーチング®を学ぶスクラムマスターの方やアジャイルコーチの方が増えてきましたので、アジャイルな現場でのORSC®活用方法を記事にしてみました。 もしよければご参照頂ければと思います。（Google Documentで記載したのですが良いWeb公開方法がよくわからず、一旦以下のような形で公開しています）

今週、筑波大学のenPiT夏合宿をやっています。 大学生10チームがソフトウェアプロダクトを作るというプロジェクト型教育のなかで、1週間の夏合宿で1日1スプリントのスクラムを採用してアジャイル開発を実践しています。 ちなみに9月には琉球大学のenPiT夏合宿もやります。 詳しくは過去にいろいろ書いてきたのでそちらを参考にしてください。 miholovesq.hatenablog.com 今回は、「スプリントゴール」をうまく使いこなせないチームを目にして全体に伝えた内容に加筆して、ブログにも残しておきます。 スプリントゴールとは 現時点で最新のスクラムガイド 2020年11月版から引用します。 スプリントゴールはスプリントの唯一の目的である。スプリントゴールは開発者が確約するものだが、スプリントゴールを達成するために必要となる作業に対しては柔軟性をもたらす。スプリントゴールはまた、一貫性と集

これは Chatwork Advent Calendar 2日目のエントリです。 また、このエントリの公開日翌日に開催される"だいくしーのスクラムBar #1" で取り扱うテーマについての詳細な解説記事も兼ねています。 chatwork.connpass.com スクラムマスターって何をする人なの？ 本項ではこれについて少し考えてみたいと思います。また、ぼく自身が普段どういうことを考えながらスクラムイベントや、その他の仕事をしているか、なども書いてみようと思います。 スクラムマスターは、ソフトウェア開発に関する他の職種と比べても、具体的な職務内容がわかりづらい役割なのかな、と思います。少し乱暴な言い方をしてしまうと、デザイナーがいなければデザインはできないし、プログラマーがいなければアプリケーションコードを書くのはとても困難です。しかし、スクラムマスターがいなくても別に開発はできます。 そ

この記事では、私たちのチームがスプリントゴールの達成とコード品質の低下を防ぐために行っているプラクティス、「死亡前死因分析」について紹介します。 スクラムチームと計画 変化への適応が強調されるスクラムですが、だからと言って事前の計画をないがしろにすることはできません。 私たちのチームが大切にしているキーワードのひとつに、“Measure twice, cut once” （二度測って、一度で切る）があります。もともとは優れた大工の仕事を指す言葉で、注意深く計画し一度で仕事を済ませる、手戻りのない状況を表現する言い回しです。 私たちにとっても、“Measure twice, cut once” の大切さは大工にとってのそれと変わりません。手戻りはデリバリの速度だけでなく、実装の素直さやコードの端的さにも悪い影響を与えるためです。ソフトウェアのバグが一番現れやすい箇所は「苦労と試行錯誤の末にな

どんなエントリ？コニチハ、経営管理クラウド ログラスのエンジニアの佐藤です。 前職（ビズリーチ）チームのスクラムが社内でもトップクラスの完成度だったので忘れないようにまとめようと思います（事実上の退職エントリ）。 スクラムの知識を前提としてスクラムイベントで気をつけていたことを順番に書いていきます。 注意: ここで書かれていることはあくまで前職のチームでは、ということなので、公式のスクラムガイドで明確に定義されていることから逸脱している可能性があります。 リファインメントリファインメントは1週間スプリントに対して週2時間固定で行います。POとステークホルダーであるデザイナーとチームメンバーが参加します。 リファインメントのゴールは以下の3つでした。 1. PBI（チケット）の受入基準を明確化する 2. ストーリーポイントを見積もる 3. 3pt以上のPBIを可能な限り分割する リファインメ

スクラムガイド2020からは、IT以外の分野にも適用してもらいたいみたいなので、ソフトウェアに特化したものはできるだけ排除する（とはいえ、なかなか難しいね） スクラムガイドでは「我々は1990年代初頭にスクラムを開発した」とあるので、まずは当時の状況を把握しておくとよさそう。おおざっぱに言うと、ソフトウェア業界的にウォーターフォールじゃダメだという雰囲気になっていて、何かいい方法がないものか……とみんなが模索していた時代。 そこで、過去の文献を遡り、当時でも使える概念が発掘された。それが、以下の竹内・野中論文である。Jeff Sutherlandはここから「スクラム」という名前を拝借しており、両名は「スクラムの祖父」と称される。 Takeuchi, H., & Nonaka, I. (1986). The new new product development game. Harvard

TL;DR: アジャイルメトリクス 適切なアジャイルメトリクスは、チームが「アジャイルになる」ための状況もしくは、組織が「学習する組織になる」ための状況のいずれかを反映したものになります。 チームレベルでは、アジャイルメトリクスは、定性的な方が定量的な方より、機能することが多いです。組織レベルでは、これが逆になります。定量的なアジャイルメトリクスは、定性的な方よりもより良いインサイトを与えてくれます。 26,000人が登録する「Food for Agile Thought」ニュースレターに登録しませんか？または、「アジャイルメトリクスサーベイ（Agile Metrics Survey 2020）」への貢献を検討してください。 良いアジャイルメトリクス 一般的にメトリクスは、現場をより良く理解するのに役に立ちます。また、時間経過とともに、変化に対するインサイトを得ることができるようになります

こんにちは、河口です。 atama plusというAI×教育のスタートアップでスクラムマスターをしています。会社と私の紹介については、以下のスライドとnoteを参照ください。 みなさん、「デュアルトラックアジャイル」という言葉をご存知ですか？ デュアルトラックアジャイルとは、「事前に最小コストで最大のリスクをつぶしながら、価値あるプロダクトを作っていく」ための開発プラクティスです。 atama plusでは創業当初からデュアルトラックアジャイルを実践しようと取り組み、たくさんの失敗と成功を重ねてきました。ディスカバリーバックログとデリバリーバックログを分けてプロセス化してしまったことによるミニウォーターフォール化など・・・。 今年のはじめに弊社のデザイナーも、atama plusのデュアルトラックアジャイルの取り組みを紹介していました。今回は、プロダクトオーナー、スクラムマスターの視点から

“Since 2005, we've worked with clients to apply the LeSS (Large-Scale Scrum) organizational system for scaling Scrum, lean and agile development to big product groups. We share that experience and knowledge through LeSS so that you too can succeed when scaling.” —Craig Larman & Bas Vodde

スクラムの原則を、いかにして実践するか - 現場にありがちな悩みを吉羽龍太郎に相談してみた スクラムは多くの開発現場で取り入れられており、その原則を学ぶのは簡単です。しかし原則を現実に実行しようとすると、さまざまな課題が……。アジャイルコーチの吉羽龍太郎さんにスクラムの基礎から、ありがちな課題への対処法をたっぷり聞きました。 スクラムは軽量で理解が容易、だけど実際にやるのが難しい 【スクラムの基礎知識】3つの役割を理解する 【スクラムの基礎知識】5つのイベントを理解する 【スクラムの基礎知識】3つの作成物を理解する スクラムを“現実的に”実践する手法 見積もりは誰のもので、誰が作るのか フィボナッチ数列よりも「Tシャツ見積もり」。素早く見積もりを作る手法 スプリントの期間は1週間が計画しやすくておすすめ スプリントプランニングの極意。タスクの粒度は小さければ小さいほど扱いやすい タスク管理

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 序文 このエントリーは Engineering Manager AdventCalendar 2018 の 11日目の記事になります。 筆者とエンジニアリングマネジメントの関わり 現在、サーバサイドエンジニアのエンジニアリングマネージャという肩書きでエンジニアリングマネージャをしています。 現職ではエンジニアリングマネージャはピープルマネジメント中心とした役職です。 前職でもエンジニアのマネジメントするポジションで、技術に関する部分のプロダクトマネジメント、プロジェクトマネジメント、ピープルマネジメントなどの全ての責任を持っており、チー

Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

スクラムマスターがやること、やらないこと - アジャイルトレーニングの専門家に聞いてみた スクラムマスターとして日々仕事に邁進していても、教科書どおりにいかないこともしばしば。イベントに人が来ない……、タスク終わらなさそう……などなど、スクラムマスターが直面しがちな、「あるある」な悩みを、アジャイルコーチの吉羽龍太郎さんに相談してみました。 イベントマネジメントの心得 スプリントレビューでは言いたい放題言わせよう！ スプリントの期間延長は絶対NG　大切なのは原因の究明 スコープと期限の両方を守るのは難しい よいチームを作るためにスクラムマスターができること アジャイル開発の定番手法ともいえる「スクラム」。開発チームにスクラムを導入し、効率的に開発を進めるには、スクラムマスターの手腕が欠かせません。しかし、いざスクラムを運用しようにも、現実には教科書どおりいかない場面もあるでしょう。 イベン

https://agiletalks.connpass.com/event/153398/

2020/01/08から、Regional Scrum Gathering Tokyo 2020（以下、RSGT2020）が始まりました！ 2020.scrumgatheringtokyo.org 本ブログでは、RSGT2020のセッションの発表資料をまとめています。 個人で発見した発表資料のみですので、掲載していないセッションの発表資料がありましたら、コメント欄などで教えていただけるとさいわいです。 現時点では、1日目のスライドのみです。 2日目まで追加しました！ 3日目まで更新しました。 1日目（2020/01/08） keynote The Ten Bulls of the Scrum Patterns Hall WEST アジャイルコーチ活用術 slide.meguro.ryuzee.com みなさんのプロダクトバックログアイテムはOutcomeを生み出していますか？ プロダクト生

先日、現場の人から質問を受けました。 「スクラムで進めているプロダクトに、大きめの問題(バグっぽい挙動)が見つかった。POは最優先で対応したいと思っているが、まず状況把握や原因調査だけでも時間がかかりそうで、ましてや対応までどのくらいかかるかわからず、1スプリントに収まる気がしない。どう対応していくのがいいか」 バグ対応とスプリントについては、いろいろな人が言っています。自分の中ではそういう話と自分の経験がまぜこぜになってしまっていますが、それを思いつくままに書き出して回答を送りました。なんとなく、自分にとっても整理された感があったので、こちらにも置いておきます。 問題を特別扱いしない。問題も、機能追加も、どちらも「理想と現実のギャップ」であり別々に扱う必要はない。どちらも同じように、調査や準備をし、見積もり、プロダクトバックログに入れ、優先順位を検討し、スプリントで開発する。 POが優先

EOF2019と登壇の経緯 こんにちは、Delivery Management Team の Tanigawa です。 2019年10月31日、渋谷がハロウィンムードに包まれている中、私は浅草橋にて EOF2019 というカンファレンスでLINEにおける組織/チームマネジメントに関する取り組みを紹介してきました。 本カンファレンスは今回 EOF2019実行委員会によって初めて開催され、様々な企業で日々奮闘するエンジニアリングマネージャーやプロジェクトマネージャーが自身の経験やチャレンジ、失敗などをオープンに共有しあうという目的で開催されました。詳しくはイベントページを参照してみてください。 LINEは11月に開催した LINE Developer Day 2019 の宣伝も兼ねて、ゴールドスポンサーとしてこのイベントに協賛させていただきました。 このカンファレンスで私から共有したのは、LI

それぞれの現場の「正しいものを正しくつくる」 登壇資料です。

Agile/Scrum へ取り組むことで、プランナー・エンジニア間の課題が解消し協調的に取り組めるようになり、チームがより自律的に動けるように成長していくお話 https://confengine.com/regional-scrum-gathering-tokyo-2019/proposal/8175/scrum