ウクライナ軍に入隊したアジャイルコーチが、さまざまなメソッドを駆使して中隊長としてのリーダーシップを実現した話（前編）
ウクライナ軍に入隊したアジャイルコーチが、さまざまなメソッドを駆使して中隊長としてのリーダーシップを実現した話（前編） アジャイル開発の代表的な方法論であるスクラムをテーマに、都内で1月に開催されたイベント「Regional Scrum Gathering Tokyo 2024」で、経験豊富なアジャイル開発のエキスパートとしてウクライナを拠点にアジャイルコンサルタントをしていたドミトロ・ヤーマク（Dmytro Yarmak）氏が、ロシア軍の侵攻後にウクライナ軍に入隊し、中隊長としてリーダーシップを発揮するためにさまざまなメソッドを駆使して軍隊の組織を変革していった経験を語ったセッション「A True Story of Agile Coaching in Ukrainian Armed Forces」が行われました。 軍隊という、企業とは異なる構造や目的を備えた組織で、しかも多くの民間人が入
プリウス開発に見るアジャイル開発要素と今時の進め方：続編 / The Agile Development Elements and Current Approach as Seen in Prius Development: Sequel
弊社の伝説の開発のひとつ、スクラムの源流でもある、初代プリウスについて、当時の開発者たちが語る熱く、時には洩れる本音のトークを紹介します。また日本を代表するアジャイルコーチの皆さんと、温故知新の心構えでこれらを分析しました。開発者たちのトークに、いくつかの共通ワードが存在し、それがスクラムの源流と繋がっている所まで整理できたので解説します。更に、変化の時代、環境変化に対し、ハードウェア開発をどう進めるべきか？ いまどきの取り組みを現場の開発者たちの声と共にお届けいたします。本内容は、スクフェス三河「初代プリウスにみるアジャイル開発の要素と現代の環境での進め方について」の続編という位置付けになります。 / We will introduce passionate and occasionally candid discussions by the developers of our lege
スクラムとデッドライン壊れゆくチームをつなぎとめるもの/Scrum and Deadlines
循環する学び～現場とコミュニティの境目で考える～/Learning Cycle between a team and a community
プロダクトバックログリファインメントはいつ何をするのか
みなさんこんにちは。@ryuzeeです。 プロダクトバックログリファインメントのやり方について立て続けに聞かれることがあったのでまとめておきます。長文ですが参考になれば幸いです。 まずはスクラムガイド2020を確認しておきましょう。該当する箇所は3箇所です。 スプリントでの説明（9ページ） スプリントでは、（中略） プロダクトバックログを必要に応じてリファインメントする。 スプリントプランニングのトピック2での説明（10ページ） 開発者は、プロダクトオーナーとの話し合いを通じて、プロダクトバックログからアイテムを選択し、今回のスプリントに含める。 スクラムチームは、このプロセスの中でプロダクトバックログアイテムのリファインメントをする場合がある。 それによって、チームの理解と自信が高まる。 プロダクトバックログでの説明（13ページ） 1スプリント内でスクラムチームが完成できるプロダクトバッ
個人分担性がスタートアップの成長を殺す �〜協働でチームがめっちゃ進化する話〜
※ スクラムフェス仙台2023 で登壇した際の資料です。 スタートアップでの開発形態は、ウォーターフォールに依存しがちなJTCと違って、プロダクトバックログやカンバンぽいものを使ったアジャイル風の開発をしていることが多いです。 しかし一方で、そういったスタートアップにはプロダクトバックログはあっても、たいていPBIの1つ1つがやたらでっかくて、1つ1つにしっかり担当者がアサインされてて、何ならデッドラインまで記されています。 これを引き起こすのは、スタートアップ特有の個人分担制です。 多くのスタートアップ企業はたいてい、エンジニア1〜2名からスタートし、個々のエンジニアの馬力で開発をこなしていくところから始まります。このときのバリバリ個人開発なノリが、エンジニアが増えても継続してガチガチの個人分担制に移行しがちです。 このセッションでは、個人開発をこじらせたスタートアップ企業がどうやって個
「スクラムで生産性は上がらないしリリーススケジュールが狂いまくりなんですよ」とか言うお前らに告ぐ
前提 この記事は内製開発をしているSaaSの中の人であるエンジニアが、SaaSの内製ソフトウェア開発をする上での話として書いています。 前ふり 「スクラムで生産性は上がらないしリリーススケジュールが狂いまくりなんですよ」 「何が原因なんですか？どうすればいいんですか？」 という相談を受けました。 NDAを書いてから、どれどれとチームの状況を見てみました。 該当チームのスプリントゴール 該当チームのスプリントゴールはこんな感じでした。 QAフェーズのプロジェクトAを、QA作業を完了してリリースできる状態まで進める 実装フェーズのプロジェクトBを、フィーチャーの実装率を50%まで進める 設計フェーズのプロジェクトCを、要確認な点を除いて実装レディーな状態まで進める スプリントゴールが3つありますね。とても面白いですね。 思わずボンドルド卿みたいな反応をしたくなりますがここは先に進みましょう。
SAFe（Scaled Agile Framework）の価値と原則 | Atlassian
Scaled Agile Framework® （SAFe®）は、エンタープライズ規模でアジャイル・プラクティスを導入するための、一連の組織およびワークフローのパターンです。このフレームワークは、役割と責務に関する体系的なガイダンス、作業の計画と管理の方法、維持すべき価値などの知識がまとめられたものです。 SAFe は、多数のアジャイル・チーム間での調整、コラボレーション、デリバリーを促進します。アジャイル・ソフトウェア開発、リーン製品開発、システム思考の 3 つの主要な知識を中心に形成されています。 SAFe は、企業の規模の拡大に合わせてアジャイルを拡張するための体系的なアプローチを提供します。さまざまなレベルの拡張に対応するために、SAFe には、Essential SAFe、Large Solution SAFe、Portfolio SAFe、Full SAFe の 4 つの構成が
アジャイルで「偉い人」はどう振る舞うべきか - arclamp
アジャイルを展開していくうえで、現場の開発チームがどう振る舞えばいいかは具体的なテクニックがあるのですが、「偉い人」がどう振る舞うべきかについての情報が少ない気がしたので整理します。なお、僕の元ツイートはこちらからの一連です。 アジャイルを推進している偉い人の中にはスプリントレビューに出るなど、マイクロマネジメントになりがちな人がいる。理由を聞いたら「成果物が、普通に考えたらそうならないでしょ、みたいなものを作るから目を離せない」という。進言したのは「それはチームに考えさせてないからですよ」（続— 鈴木雄介/Yusuke SUZUKI (@yusuke_arclamp) 2023年2月4日 前提 偉い人、とは 偉い人は関わりすぎてはいけない なぜ、チームは普通に考えないのか 偉い人が関わらないのもダメ 偉い人は適切に関わる 追記 前提 この議論において「そもそも、偉い人やPOやエンジニアに
私はスクラムを解っていなかった - LIVESENSE ENGINEER BLOG
これは Livesense Advent Calendar 2022 DAY 2 の記事です。 はじめに 身を以て学んだアンチパターン スクラムガイドを理解したつもりになっていた スクラムによってリリースが早くできるわけではない 見積もりを約束にしてはいけない プロダクトオーナーはスクラムチームメンバーでありお客様ではない ロール（プロダクトオーナー、スクラムマスター、開発者）の兼任は出来るだけやめた方が良い プロダクトバックログは会話ツール まとめ はじめに 転職会議事業部でエンジニアをしている、前山です。 アドベントカレンダー2日目の記事です。 今回は、スクラムマスターとして苦しんだ経験について、アンチパターン的に書いてみたいと思います。 スクラムマスターは2年ほど前からやらせてもらっており、今年に入ってから発足したチームで、もっとちゃんとスクラムマスターをやろうと本気で勉強をやり始め
アジャイル迷子のための「アジャイルの本質」。あとDDDとのつながり - little hands' lab
記事の構成 アジャイルソフトウェア開発とは アジャイルマニフェストとは アジャイルマニフェストの問題 そこで、アジャイルの本質 by マーティンファウラー アジャイルソフトウェア開発とは？ アジャイルソフトウェア開発とはなんでしょうか？ 「アジャイルマニフェスト(後述)の4つの価値観、12の原則に従う開発方法の総称」 これが最もオリジナルな定義です。 なぜこんなややこしい言い回しをするのは後から説明します。 重要なことは、「アジャイル」という具体的な手法があるわけではないということです。 アジャイルはマインドセット(思想、考え方)です。そのため、 ✖️ do agile 「アジャイルをやる」はありません。 ⭕️ be agile 「アジャイルになる、アジャイルの思想に則る」はあります。 アジャイルの思想に則った開発手法として ・スクラム ・エクストリームプログラミング(XP) ・リーンスタ
「1人アジャイル」から始める、アジャイル開発導入のススメ｜Agile Journeyローンチによせて - Agile Journey
みなさん、こんにちは。 ユーザベースという会社でSaaS事業のCTOを務める林 尚之です。 本日、新しいWebメディア『Agile Journey』がローンチされました。私はこのメディアに編集長として関わりますが、本稿では『Agile Journey』がどんなメディアで、なぜアジャイルをテーマとしたメディアを立ち上げたのかをお伝えしたいと思います。 『Agile Journey』はできるかぎり「実践」にフォーカスしていきたいと考えています。すでに世の中には、アジャイルに関する事柄を解説する本や資料がたくさんあり、「ペアプロってなに？」「TDDってなに？」という問いに対する基本的な解は容易に見つかるでしょう。しかし、「やり方を知る・理解する」と、「それをいかに実践するか」には別の難しさがあります。実際、私も「アジャイルをいかにして、実践するか」に関して日々、頭を悩ませていますし、試行錯誤を繰
スクラムチームで実践しているソロプロとモブプロを両立したスウォーミングの紹介 - Cybozu Inside Out | サイボウズエンジニアのブログ
みなさんこんにちは。kintone フロントエンドリアーキテクチャプロジェクト（フロリア）で、エンジニア兼スクラムマスターとして活動している村田（@kuroppe1819）です。 現在、フロリアには兼務も含めて約 30 人のメンバーが参加しています。フロリアは小さな 4 つのクロスファンクショナルチーム体制で、それぞれが独立したスクラムチームとして活動しています。 今回はその中のひとつのチームである、サイレントリリースを部分的に試みているチーム（Mira チーム）で取り組んだ、ソロプログラミング（以下、ソロプロ）とモブプログラミング（以下、モブプロ）を両立したスウォーミングの実践事例を紹介します。 スウォーミングとは？ まずはスウォーミングという言葉について説明します。 Swarming を直訳すると「群れる」です。ソフトウェア開発の文脈では 1 つの問題やタスクを皆で群がって解決するとい
最速でフロントエンドを刷新するための開発フロー - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、フロリアでQAエンジニアをやっている中園です。 現在サイボウズでは kintone のフロントエンドリアーキテクチャプロジェクト（フロリア）と称して、Closure Tools から React へと置き換えるプロジェクトが進行中です。 フロリアの詳細については 次の記事をご覧ください。 今回は、フロリアのチームの一つで、利用者に気づかれない形で React への置き換えを行っている Mira チーム1の開発・テストフローの紹介をします。 "最速で" React に置き換えたい Mira チームはただ React に置き換えるのではなく「最速で React に置き換える」という目標があります。 フロリアの各チームはそれぞれのチームごとにオーナーシップを持っており、チームごとに意思決定を行っています。Mira チームでは「最速で置き換える」という目標に向かって、開発スピードを向上
スプリントの属人性を減らしたらベロシティが安定した話 - Commune Engineer Blog
【2022/07/04追記】 この記事の結果に至るまでを示した補足記事を書きましたので、良ければ見て頂けると嬉しいです。 tech.commmune.jp はじめに これは何？ 誰向けの記事？ 自己紹介 前提：「ベロシティの安定」とは 取り組み導入の背景 属人性を減らす取り組みの一覧 ① WIP制限 どうやったか 得られた成果 補足 ② タスクサイズの制限 どうやったか 得られた成果 ③ 死亡前死因分析（プレモーテム） 死亡前死因分析とは？ どうやったか 得られた成果 全ての取り組みの結果 得られた成果 何故この成果を得られたか？ 注意点 まとめ 最後に はじめに これは何？ スプリントの属人性を回避しようと取り組んだらベロシティが安定したので、実際に行った以下の取り組みを紹介する記事 WIP制限 タスクサイズの制限 死亡前死因分析 誰向けの記事？ スクラム最初の壁であるベロシティの安定化
Four Keysがなぜ重要なのか - 開発チームのパフォーマンスを改善する方法について - yigarashiのブログ
ソフトウェアエンジニアとして働き始めて以来、ずっとソフトウェアデリバリーのパフォーマンスに興味を持って、さまざまな改善活動をしてきた。当初はスクラムを中心としたプロセスの改善に注力したが、最近はチームの成熟に伴って技術的なプラクティスに興味が移りつつある。より広い視点からデリバリーについて考えるのは非常に楽しい仕事だ。 デリバリーのパフォーマンスを改善していくには、定量指標として確立されたFour Keysを計測し改善するのが業界標準となりつつある。恥ずかしながら、私はこれまでこのFour Keysが腹落ちせず、積極的に計測してこなかった。しかし、多方面に興味が向いて知識や経験が蓄積するにつれて、猛烈にFour Keysの重要性が腹落ちしてきた。この記事では、現時点における自分のFour Keysに関する理解と解釈を整理してみようと思う。 Four Keysとは Four Keysの妥当性
だからお前のチームはスクラム導入で満足して、いつまでたっても生産性が上がらないんだよ
最初に タイトルは煽りで釣りです。ごめんね。 この記事の結論を先に書くと タイトルは釣り スクラムチームは導入当初はスムーズに成功できるように感じる。しかし途中でどこに進むべきかの方角を見失い、迷走してスクラムバットに陥る スクラムに求める効能はベロシティの安定が必須なものが多いのに、ベロシティの安定を意識すらしないままスクラムをやるので、迷走に陥る じゃあどうしてそうなってしまう？という話を個人の経験をもとに書いていこうと思います。 前提として この記事を書いた人はWebサービスの内製開発をしているアプリケーションエンジニアだったので、基本的に内製開発のWebサービスでのスクラム導入について語ります なぜこの記事を書いたか やっとむさんのツイートを見て思いつきました。 スクラムの導入をしたいというチームは数多く見ますが、かなり中途半端なところでスクラムのレベルアップをやめて、小手先の「改
スクラムでベロシティを安定化するにはどうしたらよいか - 貳佰伍拾陸夜日記
このブログではあまりこういう話は書いてこなかったけど, 以前少しだけ触れたように, 僕はここ最近エンジニアリングマネージャをやっていて, こういう話題を考える機会はけっこう多い. 具体的には, エンジニアリングマネージャとして複数チームのテクノロジ/プロセス/プロダクト/ピープルのマネジメントを日々やっていて, そのうちのプロセスマネジメントとして, 各チームのスクラムマスタ的な人に助言したり, 開発プロセスの改善のためにチームが起こそうとしている変化を受け入れるようラインマネージャを説得したり, といったことにけっこう時間を割いている. スクラムに関して以下のような話を見かけて, これはまさに日々悩まされていることだった. 一言で言うと「ベロシティの安定化でみんな躓く」という話. これは僕の経験上も納得できる. この記事に寄せられたコメントを見ると, 「で, じゃあどうやってベロシティを
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
こうしてふりかえりは終わってしまった / A Demise of a retrospective
https://twitter.com/Akira_Akagawa/status/1581555970840604677
OKRはツリーではない
