スクラムマスターの世界に飛び込んだリアルな心境 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、サイボウズでGaroonモバイル開発チームのスクラムマスターをしている東條です。 私はスクラムマスターになってまだ半年も経っていません。駆け出しの身として、スクラムマスターとしての役割は何なのかを日々模索しています。 本記事は、サイボウズのスクラムマスター職能で開催しているリレーブログ企画の一本です。 リレーブログ企画：スクラムマスターって何をするの？チームを健全に保つ多様なリーダーシップの実際 対象読者：スクラムマスターが近くにいるけどありがたみを感じたことがない人 学習成果 (Learning Outcome)：記事の内容に関連する悩みについて、近くのスクラムマスターに相談できるようになる リレーブログ企画の学習成果を得るためには、スクラムマスターに親近感を持ってもらうことが大切です。 本記事は、読者の皆さんに「スクラムマスターに親近感を持てるようになった」と言っていただく
Scrum@Scaleの日本語書籍を出版します & 執筆の様子の記録 - だいくしー(@daiksy)のはてなブログ
実は密かな長年の夢だったのですが、この度、技術評論社さんから単著を出版することになりました。 Scrum@Scaleの解説書で、全編書き下ろしです。 紆余曲折があり編集者さんに本を書きませんか、と打診いただいてから2年半ほどの大仕事でした。 Scrum@Scaleについてまとまった日本語の書籍は他にはなく、複数のスクラムチームで仕事をされている現場の大きな手がかりとなるはずであると自負しています。ぜひお手にとってみてください。 スクラムの拡張による組織づくり──複数のスクラムチームをScrum@Scaleで運用する 作者:粕谷 大輔技術評論社Amazon 書籍の内容について 本書はぼくが現職でScrum@Scaleを導入した際の知見を惜しみなく注ぎました。全7章の構成です。 第1章 スクラムのスケーリングと大規模の難しさ アジャイルコーチになんの前提もなく「スクラムをスケールするにはどうす
【資料公開】スプリントレビュー Deep Dive
みなさんこんにちは。@ryuzeeです。 2023年1月11日-13日に開催のイベント「Regional Scrum Gathering Tokyo 2023」の登壇資料を公開します。 スプリントレビューは非常に重要なイベントです。 5つのイベントのなかでいちばん重要なイベントを選べと言われたら、僕はスプリントレビューを選びます。 スクラムはプロダクトを届けるためのものであり、プロダクトを成功させるにはプロダクト自体の検査と適応が必須だと思うからです。 一方で、スプリントプランニングの精度を上げようと頑張る割にスプリントレビューが雑に扱われる例が多くて懸念していました。 ということで、本セッションでは、スプリントレビューの目的や参加者、進め方、コツなどを深掘りしてみました。 みなさんの参考になれば幸いです。 忙しい方向けのまとめ スクラムチーム全員が参加しろ スクラムチームの外側のステーク
【資料公開】スプリントプランニング Deep Dive
みなさんこんにちは。@ryuzeeです。 8月26日に新刊『エンジニアリングマネージャーのしごと』が発売になったのでぜひよろしくお願いします。 2022年8月26日〜27日までスクラムのコミュニティイベントであるScrum Festが初めて仙台で行われました。 このイベントで「スプリントプランニング Deep Dive」というタイトルで話をする予定だったのですが、急遽体調不良となり、代わりに弊社の@miholovesqに登壇してもらいました。 ただ、資料をそのままにしておくのも勿体ないので、こちらで公開します。 スクラムガイドの複数回の改訂で、スプリントプランニングにも何度か変更が加わっています。 ところが巷のブログなどを読んでいると古い知識をベースにしていたり、特定のツールの従来からの仕様に引きづられた運用になっていたりするのを多く見かけます。 ということで、今回スプリントプランニングに
Re: スクラム開発チームと業務委託エンジニアの相性が最悪だと思っている - terurouメモ
この記事を読んだ。 note.com よーある話だなと思いつつ、「業務委託はダメで、社員ならOK」という話はちょっと話が雑だなあと思ったので、コメントを書く。 スクラムチームで人の出入りが激しいとキツイ これはそう。 ただ、スクラムかによらず、出入りが激しいとキツイけど… 業務委託では、高パフォーマンス人材は単価つり上げがきつく、結果契約打ち切りになる 実際の事象としてはよくある話。ただし、業務委託のみの話ではなくて、社員でも「会社に不満があったからやめた」は良くある話。 たぶん、ここが気になるのは、このあたりの違いだとは思う。 報酬の見直し頻度 社員だと給与体系の見直しが年1回であるのが普通 業務委託だと契約期間ごと（業界慣習的に3カ月単位が多い認識） 条件交渉者が本人なのか営業なのかの違い 営業の仕事は売上を上げることなので、当然ガンガン言ってくる 対して社員が自分の雇用条件について、
スクラム開発チームと業務委託エンジニアの相性が最悪だと思っている｜s_semiya
はじめにこの記事の対象読者は「機能しているスクラム開発チームのメンバーないし関係者」をイメージしています。 また会社のフェーズや資本状況、フルタイムでないメンバーを雇いたいなどのコンテキストもあるので業務委託が一概に悪とは言いません。 単純に相性が悪いってだけです。 また相性が悪くてもチームが即崩壊するとかそう言う話でもないです。 僕は業務委託の人が嫌いなわけではありません。ただスクラム開発と相性悪いな（主に単価的な意味で）と思っています。 あとここで言うSES的に送り込まれる業務委託の人の単価は月100万~150万円くらいです。 実は「業務委託契約」とは限らないWeb界隈の一部の慣行として「協力会社(個人を指す)」とほぼ同義語として「業務委託」は使われています。「業務委託」と呼ばれる個人に対してリーダーが指揮命令権を持ちます。契約形態は関係ありません(パねぇな)。 実態の契約形態が業務委
チームのベロシティを上げる vs. 安定させる - yigarashiのブログ
タイトルの議論はよく見られるもので、スクラムコーチの間ですら（一見すると）意見が分かれることがあるようです。自分は「安定させる」派だったのですが、CSPO研修を受講したチームのPOが「上げる」派のコーチングを受けてきて、改めてチームとしてどういうスタンスを取るか考える機会を得ました。結論から言ってしまうと、そもそもこれは二項対立ではなく、「上げる」派の人も「（安定させた上で）上げる」と言っているだけで、単に目指している高さが違うだけだろうと解釈しました。その上で、チームの現状に合わせて適切な目標設定をすれば良いと考えました。以下でもう少し掘り下げてみます。 大前提 まずソフトウェア開発の大前提として、開発チームには常にベロシティを下げる方向に様々な力がかかっています。これは「変化」と呼ばれて恐れられ、プロダクトや開発チームに次々と襲い掛かります。例えば以下のようなものです。 市場が求めるも
プロダクトバックログアイテムがたくさんあって整理に時間がかかるのですが、どうしたらいいですか？
プロダクトバックログに含まれるアイテムが多すぎて、整理しきれなかったり整理に時間がかかったりする状況は不健全です。 以下のような点について見直してみましょう。つまり、効率的な管理の方法を模索するのではなく数を減らしましょう。捨てましょう。 ゴミが混ざっていないか。何年もプロダクトを運用していると時間の経過とともに、プロダクトバックログが全部入りのごちゃごちゃしたものになりがちです。一旦全部眺めて、不要なものを捨てましょう。半分くらいのアイテムは捨てられるはずです。どうしても捨てられない場合は、当面関心を持ちそうにない項目を別の場所に移しましょう。それでしばらくの期間みないようであれば捨てることができるはずです粒度が細かすぎないか。プロダクトバックログは上位ほど具体的で、下位になるにしたがってざっくりとした内容になります。着手時期が近づくにつれて詳細化されて、1スプリントに収まるサイズに分割
スクラムガイドに新たに追加された「プロダクトゴール」とは？ あるいはプロダクトゴールの設定には何が必要か？（前編） Regional Scrum Gathering Tokyo 2022
スクラムガイドに新たに追加された「プロダクトゴール」とは？ あるいはプロダクトゴールの設定には何が必要か？（前編） Regional Scrum Gathering Tokyo 2022 代表的なソフトウェア開発手法として知られる「スクラム」を開発したケン・シュウェイバー氏とジェフ・サザーランド氏によるスクラムの公式ガイド「スクラムガイド」。2020年11月付けの最新版には新たに「プロダクトゴール」と呼ばれる概念が導入されました。 スクラムガイドによると、プロダクトゴールはプロダクトの将来の状態を表しており、スクラムチームの⻑期的な⽬標である、と説明されています。スクラムチームにとって非常に重要なものだと位置付けられているのです。 この重要なプロダクトゴールをどのように考え、どう設定すべきなのでしょうか。 1月5日から7日までの3日間、都内およびオンラインのハイブリッドで開催されたイベント
スクラムチームを超生産的にするためのパタン・ランゲージ｜天野 祐介 (ama_ch)
The Patternsハイパープロダクティブチームを体系的に生み出すため9つのパタンはこちらになります。 1. Stable Teams 2. Yesterday's Weather 3. Swarming: One Piece Continuous Flow 4. Interrupt Pattern: Illigitimus Non Interruptus 5. Daily Clean Code 6. Emergency Procedure 7. Scrumming the Scrum 8. Happiness Metric 9. Teams that Finish Early Accelerate Faster https://www.scruminc.com/wp-content/uploads/2014/05/teamsthatfinishearlyacceleratefaste
スクラムマスターは「スクラムチーム改善」のプロダクトオーナー - maru source
今年からスクラムマスター(SM)を始めた。1ヶ月ほどたったので、「やってみて気づいたこと」や「具体的に取り組んだこと」を残しておく。 ただし、僕はスクラムマスター研修は受けてない野良SM（？）である。なので、間違いとか超基本すぎることなどがあるかもしれない。 やってみて気づいたこと スクラムマスターの仕事は「スクラムチームを改善する」ことに尽きると思った。その観点で次の事が特に大事だと気づいた。 「スクラムチームの改善」は「プロダクトの改善」と同じ スクラムチームを一種のプロダクトだと考えて、課題見つける→PBIにする→解決する SMはスクラムチームの改善において、いわゆるプロダクトオーナー的な役割である 司会・議事録係・ミーティング調整役ではない まずはとにかく透明性をあげる プロダクトオーナー(PO)、BizDev、エンジニア、デザイナー、ドメインエキスパート、SM、etcのやってるこ
スクラムチーム用セルフチェックリスト
みなさんこんにちは。@ryuzeeです。 スクラムに限らず開発プロセスそのものは目的を達成するための手段に過ぎないので、定義されたプロセスやプラクティスを単に守れば良いというわけではありません。 根底にある価値観や原則を理解することが重要です。 とはいえ、自分たちのプロセスが定義されたもの、一般的なものとどれだけ違うかを知ることは、改善のキッカケにもなります。 今回、スクラムチームが、自分たちの仕事のやり方を改善する際に参考にできるような、セルフアセスメントのチェックリストを作ったので共有します。 現時点では単なる試作品なので、ご利用は自己責任でお願いします（この記事に限らず当サイトの記事を参考にする場合も同様です）。 使えそうなら適宜更新していく予定です。 観点はスクラムの主要要素（3-5-3）にしています。フィードバックなどがありましたら、@ryuzeeまでお知らせください。 使い方使
一年半同じチームで色んなふりかえりをやったので手法と学び紹介していく
Scrum Fest Mikawa 2021の登壇資料です。 以下は資料内で引用している参考リンクです DPA https://qiita.com/viva_tweet_x/items/97e819c626979b78947a KPT http://objectclub.jp/download/files/pf/KPT_TIPS.pdf TimeLine https://developers.freee.co.jp/entry/timeline-is-a-good-retrospective-method 象、死んだ魚、嘔吐 https://no-kill-switch.ghost.io/elephants-dead-fish-vomit/ Start Stop Continue https://www.retrium.com/retrospective-techniques/start-
スクラムマスターの育て方 / Training Scrum Master
スクラムフェス三河の登壇資料です。 https://confengine.com/conferences/scrum-fest-mikawa-2021/proposal/15593
チームの状況にあったいろいろなタイプのスクラムマスターの見つけ方 / How to find the Scrum Master that fits your team's situation
ScrumFestOsaka2021 での発表資料です
すごい開発チーム育成ハンドブック · すごい開発チーム育成ガイド
すごい開発チーム育成ハンドブック プロダクト開発の｢やること｣リストはTrelloで順序立てておくとうまくいく ビジネス上の要求が変化しやすいときは、タスクの優先順位を2週間変えないようにする ビデオ会議で遠方チームに「伝わらない」と思ったら、一度「顔合わせ会」を開催する 「これは使えない」と言われたら、機能の意思決定を「担当者」に委ねる エンジニアに期間が「わからない」と言われたらタスクを細分化して具体的に 仕様を考えるときはエンジニアと対話する 開発チームの開発速度がわからないときは、短い期間で速度を計測する 開発状況を把握できないときはスクラムで開発する 「Scrum for Trello」でストーリーポイントをチームで共有する やってみないと分からないタスクは調査する スクラムが定着しないときは、2日のスプリントで慣らす ストーリーポイントの見積もりは「比べる」が基本 ストーリーポ
なぜスクラムチームの開発者が複数チームを兼任しないほうがよいのか
みなさんこんにちは。@ryuzeeです。 よく受ける相談の1つに、「スクラムチームの開発者は複数のチームやプロダクト、プロジェクトを兼任してもよいのか」というのがあります。コーチ業をしている人ならみんな受けたことがあるものだと思いますが、詳しく見ていきます。 まず最初に結論ですが、タイトルにもあるとおり、「スクラムチームの開発者は複数チームを兼任しないほうがよい」です（スクラムガイドには書いていないですが、スクラムガイドは全てを詳細に記したハウツーではありません。あくまでゲームのルールです）。 理由を順番に見ていきましょう。 1. 開発に使える時間がかなり少ないスクラムチームの開発者はスプリントプランニング、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブといったイベントと、プロダクトバックログリファインメントのような活動に一定の時間を使います。 チームによって時間は変わ
スクラムガイドの変更に伴うヤフーのスクラムの変化
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは。アジャイルコーチの荒瀬中人です。 スクラムガイドが約3年ぶりに更新されました。スクラムガイドとはスクラムについて書かれている唯一無二のガイドです。 スクラムの取り組みの中で活用できると思い、最新版のスクラムガイドに沿ったスクラムのフレームワークの各要素や目的をシンプルにまとめた1枚の概要図にしました。 私自身簡単に見直せるとともにセミナーなどでスクラム説明する際に活用しています。このブログを読んでくれている方のお役に立てればと思い、今回公開することにしました。 こちらからダウンロードください スクラム概要図ダウンロード（PDF 332KB） さて、今回のスクラムガイドの変更点に“指示的な部分を削減(*1)”、“幅広い読
スクラム提唱者とアジャイル普及の第一人者が解説する『アジャイル開発とスクラム 第2版』発売
スクラムの考え方を提唱した1人である野中郁次郎さんと、国内におけるアジャイル普及の第一人者である平鍋健児さんによる解説書『アジャイル開発とスクラム』の第2版が、CodeZineを運営する翔泳社より4月7日（水）に発売となります。アジャイル開発の実践者として著名な及部敬雄さんを迎え、内容を大幅にアップデートしてお届けします。 日本でも一般的になってきたソフトウェア開発手法であるアジャイル。中でもスクラムの人気が高いですが、その考え方を世に知らしめたのは、実は経営学者の野中郁次郎さんらによる研究でした。 そんな野中さんと、国内でアジャイル普及に尽力した第一人者である平鍋健児さんによる『アジャイル開発とスクラム』（2013年）が発売されて8年、翔泳社では同書に最新の知見を盛り込んでアップデートした改訂版『アジャイル開発とスクラム 第2版 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
こうしてふりかえりは終わってしまった / A Demise of a retrospective
