スクラムを導入するチームで最初にする話
はじめに 私はスタートアップを中心にWebエンジニアをしながら、アジャイルの展開をしています。いろいろな会社のいろいろなチームでアジャイルの展開をしてきました。今所属しているHITOTSU社ではVPoEやVPoTをやらせて頂きながら、開発エンジニアやスクラム寄りのアジャイルコーチをしています。 大体どのチームでも同じような話をさせて頂きまして、スクラムを始めるチームやスクラムが上手く回っていないチームに対して、アジャイルの価値観やマインドを理解せずに盲目的にスクラムイベントなどを実践するのは止めようという話をします。 まずアジャイルってなんだっけ 基本的にはアジャイルソフトウェア開発宣言(アジャイルマニフェスト)やアジャイルソフトウェアの12の原則）に則っていればアジャイルと言えます。 アジャイルソフトウェア開発宣言: https://agilemanifesto.org/iso/ja/m
高度に発達したウォーターフォールはアジャイルと見分けがつかない - An Epicurean
tl;ldr ウォーターフォールという言葉を悪口として使うのは良くないんじゃない？ 空想上の開発手法ウォーターフォールと進化したウォーターフォール アジャイル開発の説明がされるとき、アンチパターンとして「ウォーターフォール」が使われることがあります。これは「ダメな開発現場」と同義で使われており、共通仮想敵としての空想上の開発手法とも言えます。 それは、曰く、硬直化していて変化や手戻りを許さず、一本道でフィードバックサイクルがない、数十年アップデートされていない古臭い手法のことらしい。 もちろんそういう開発をしている現場もまだ数多く存在するでしょう。ただ、ウォーターフォールをカイゼンし進化させている人達もいます。そういう人たちの話を聞くと、例えば以下のような話を聞きます。 一ヶ月で１ウォーターフォールを回す 前の手順に戻る手続きが定められている 初期フェーズから開発者を巻き込む 定期的なレビ
チームに新しく飛び込んだスクラムマスターが最初にやること - Money Forward Developers Blog
こんにちは、クラウド会計の開発チームでスクラムマスターをしているasatoです。 新しいチームにジョインするのって、ドキドキしますよね。新しい環境、新しい人々、そして新しい課題。それぞれのチームが直面している問題は異なりますが、スクラムマスターとして私たちが共有する目標は一つです。それは、チームの有効性を最大化し、素晴らしいプロダクトを生み出すこと。 私は今年の1月にマネーフォワードにジョインし、今のチームでスクラムマスターとして働くことになりました。事前に聞いていたチームの情報は以下の通りです。 プロダクトマネージャー、UI/UXデザイナー、複数のバックエンド/フロントエンド/QAエンジニアから成る 従来のプロジェクトの進め方に課題感があり、4ヶ月前からスクラムを実践中 ここで一つの質問です。もし、あなたがスクラムマスターとして新しいチームにジョインしたとしたら、最初に何をしますか？この
アジャイル開発やスクラムにもマネジメントは必要だ
Photo by Pixabay on Pexels.com 最近、よくお客さま向けに「アジャイル開発やスクラムにも、マネジメントやプロジェクトマネジメントは必要だ」と話すことが多い。事の背景はこんな感じ。 背景 よくあるのが「アジャイルチームは自律して動くからマネージャはいらない」という意見だ。この意見はおおむね正しいと思う。「おおむね」の理由は、マネージャという役割は自律型組織にとって必要なくなってくるだろうけど、マネジメントという仕事はなくならないからだ。 会社全体が自律型であれば、もしかしたらマネジメントすらいらなくなるのかもしれない。ただ、ほとんどの組織がそうではないのが現状だろう。よって、四半期ごとに目標設定と評価が発生するし、人材を採用したり育成する計画は必要だし、予算管理や体制変更も検討しなければならない。 こんな状況から「マネージャとマネジメント」を引っこ抜いてもうまくい
mikanデザイナーの"スクラムで回す1週間"を覗いて行きませんか？｜Ayaka Nagataki
はじめにこんにちは！株式会社mikanでデザイナーをしているayataki（@ag_ayakan）です。 主に英語アプリ「mikan」の体験設計やUIデザインの作成を行なっています。 カジュアル面談などで話す際に、「mikanのデザイナーさんてどんなことをやってるんでしょうか？」という質問をよくいただくようになりました。 社外への発信が少ないこともあり、イメージを持ってもらいづらい状況にあるのではないかなと感じています。 そこで今日は、mikanのデザイナーとして働くわたしの1週間のスケジュールについてご紹介します！実際にあった直近のスケジュールを具体例に出していきます。 mikanのデザイナーに少しでも興味のある方に、具体的なイメージを持ってもらえたら幸いです🍊 それでは行ってみましょう！ [前提] 仕事の環境ほぼリモートワーク mikanのメンバーは基本的にフルリモートワークで働いて
スクラムとデッドライン壊れゆくチームをつなぎとめるもの/Scrum and Deadlines
見えづらい活動の成果の伝え方は日頃からめちゃくちゃ悩んでるけど、実際こんな取り組みをしな がら温度感を合わせにいってるよ / Conveying Hard-to-See Results
スクラムチーム用セルフチェックリスト
みなさんこんにちは。@ryuzeeです。 スクラムに限らず開発プロセスそのものは目的を達成するための手段に過ぎないので、定義されたプロセスやプラクティスを単に守れば良いというわけではありません。 根底にある価値観や原則を理解することが重要です。 とはいえ、自分たちのプロセスが定義されたもの、一般的なものとどれだけ違うかを知ることは、改善のキッカケにもなります。 今回、スクラムチームが、自分たちの仕事のやり方を改善する際に参考にできるような、セルフアセスメントのチェックリストを作ったので共有します。 現時点では単なる試作品なので、ご利用は自己責任でお願いします（この記事に限らず当サイトの記事を参考にする場合も同様です）。 使えそうなら適宜更新していく予定です。 観点はスクラムの主要要素（3-5-3）にしています。フィードバックなどがありましたら、@ryuzeeまでお知らせください。 使い方使
(翻訳) ストーリーポイント再考 - forest book
本稿は Ron Jeffries 氏によって書かれた次の記事の日本語翻訳です。著者に翻訳の許可を得て公開しています。 ronjeffries.com また本稿は DeepL Pro を使って下訳したものに手を加えています。日本語翻訳の不具合または誤訳については Ron Jeffries 氏ではなく、本稿のコメント欄にお願いします。 ここから本文です。 ストーリーポイント再考 私はストーリーポイントを発明したかもしれない。もしそうだったとしたら、いまは申し訳なかったと言いたい。ストーリーポイントに関する私の現在の考えを探ってみよう。少なくとも何人かは私の考えに興味をもっているでしょう。 もちろん、ストーリーは XP のアイディアであり、スクラムのアイディアではありません。どういうわけか、スクラムの実践者はこのアイディアを採用しています。公式のスクラムガイドではバックログアイテムに言及している
スクラムワークショップに参加して改めてカイゼン活動は楽しいと思えた - tawara's blog
スクラムのワークショップに参加したので、イベントレポートを書く。 kentarotawara.hatenablog.com 知人のアジャイルコーチの呼びかけに応じた現役エンジニア10名は渋谷の某所のビルの会議室に10時30分に集まった。僕も含めて実務経験歴0-2年くらいのジュニアエンジニアが多い。 「それではみなさんには、２チームにわかれてもらいます」というアジャイルコーチの号令のもとにワークショップが始まった。アジャイルについて詳しい順に一列に並び、A,Bと組分けをしていく。なるほどー、知識の偏りをなくすには効果的だなー、と先頭で立ちながら思っていた。僕は普段からスクラム形式の開発をしているので、知識は少しばかりあるし、経験もあったからだ。一番詳しいかもしれない、とすこしばかり慢心した覚えがある。何と愚かな。 5人ずつに分かれての最初のワークは、さらに２グループに分かれて、スクラムガイド
スクラムでベロシティを安定化するにはどうしたらよいか - 貳佰伍拾陸夜日記
このブログではあまりこういう話は書いてこなかったけど, 以前少しだけ触れたように, 僕はここ最近エンジニアリングマネージャをやっていて, こういう話題を考える機会はけっこう多い. 具体的には, エンジニアリングマネージャとして複数チームのテクノロジ/プロセス/プロダクト/ピープルのマネジメントを日々やっていて, そのうちのプロセスマネジメントとして, 各チームのスクラムマスタ的な人に助言したり, 開発プロセスの改善のためにチームが起こそうとしている変化を受け入れるようラインマネージャを説得したり, といったことにけっこう時間を割いている. スクラムに関して以下のような話を見かけて, これはまさに日々悩まされていることだった. 一言で言うと「ベロシティの安定化でみんな躓く」という話. これは僕の経験上も納得できる. この記事に寄せられたコメントを見ると, 「で, じゃあどうやってベロシティを
ゾンビスクラムを解決するための10の成功要因 | サーバントワークス株式会社
はじめに 2020年12月に、Johannes Schartau と Christiaan Verwijs と私で、『Zombie Scrum Survival Guide』（ゾンビスクラムサバイバルガイド）を出版しました。スクラムが、ゾンビスクラムになってしまいがちな理由を読者に理解してもらい、実践的で地に足のついた手助けを提供するために書き記したのです。ゾンビスクラムは、簡単な実験で解決できるものではりません。組織に深く浸透しているほど、解決にはより多くの労力が必要となります。そこで、書籍が発売されてからのおよそ半年後に、本書に書かれている実験を実践することで、わたしたちのコミュニティがどのように進歩しているかを確認したいと思いました。経験したゾンビスクラムとの闘いの成功例とは？そこで何が起こったのか？ゾンビスクラムはどのようなもので、どのようにしたら状況を改善することができたのか？を
ゾンビスクラムの4つの症状
4つの症状を紹介し、「外の世界との接触を望まない」という症状について詳しく説明する この記事は、Zombie Scrum Resistanceのブログ記事「The Four Symptoms of Zombie Scrum」を日本語訳したものです。翻訳に快諾していただきありがとうございます。 訳がおかしいところがありましたら、お気軽にご連絡ください。 また、現在『Zombie Scrum Survival Guide』を誠意翻訳中です。 来年には出版される予定ですので、楽しみにお待ちください。 ステークホルダーを招待するの忘れた ああ、そうですか この投稿は、私たちが書いている本、『Zombie Scrum Survival Guide』から抜粋したものだ。これは、小さなインクリメントを提供し、ステークホルダーである読者のみんなを巻き込む方法である。みんなからのフィードバックや励まし、斬新
みてねの開発スタイルを大きく変えた話
とても久しぶりに個人ブログの方に記事を書きます。 冒頭ちょっとだけ在職エントリ的な内容を。 今も元気にミクシィでエンジニアとして在職中です。2011年11月に入社したので、もうすぐ丸10年。 みてねを新規事業で立ち上げ、開発を始めてからももう7年ほど経っている。この10年で技術スタックも役割も自らいろいろ変えてきたので、全く飽きてはいないし、それどころか仕事をすればするほど新しく仕事が生まれるので飽きる暇もなく毎日を忙しく過ごしている。 最近の状況はざっくり書くとこんな感じ。 引き続き、みてねのエンジニアリングマネージャーとSREモバイルアプリとインフラの間での改善とかコスト削減とか外部リソースを使いながら開発している案件のディレクションとかあとは、開発の足回りでみんながちょっと嬉しいと思ってくれそうな改善とか、ライブラリの導入・バージョンアップとかを勝手に拾ってやってるさて、ここからは本
2022年版 みてねを支えるプロダクト開発体制
この記事では、以前に別記事で「みてねを支えるプロダクト開発体制」という記事の中で説明した「みてねのプロダクト開発体制」を最近になってアップデートをしたので、その詳細をお伝えします。 プロダクト開発体制については、数多くカジュアル面談や面接を行なっている中でも多くのエンジニアの皆様にご質問をいただく部分で、特に「エンジニアがどの段階から施策に入り込んで開発できるのか？」であったり「エンジニアと他職種のメンバーとの関わり方は？」など、確かに自分自身もソフトウェアエンジニアとして事業に関わるときに気になることではあるので、ここで再度整理したいと思います。 みてね開発体制のこれまでみてねの開発チームは、これまで組織規模や事業課題に合わせて複数回の大きな体制変更を行なってきました。どのような変遷を辿ってきたかを整理してみます。詳しい時期はあまり覚えていないので、年の記載はおおよそです。 2014年~
スクラムチームで実践しているソロプロとモブプロを両立したスウォーミングの紹介 - Cybozu Inside Out | サイボウズエンジニアのブログ
みなさんこんにちは。kintone フロントエンドリアーキテクチャプロジェクト（フロリア）で、エンジニア兼スクラムマスターとして活動している村田（@kuroppe1819）です。 現在、フロリアには兼務も含めて約 30 人のメンバーが参加しています。フロリアは小さな 4 つのクロスファンクショナルチーム体制で、それぞれが独立したスクラムチームとして活動しています。 今回はその中のひとつのチームである、サイレントリリースを部分的に試みているチーム（Mira チーム）で取り組んだ、ソロプログラミング（以下、ソロプロ）とモブプログラミング（以下、モブプロ）を両立したスウォーミングの実践事例を紹介します。 スウォーミングとは？ まずはスウォーミングという言葉について説明します。 Swarming を直訳すると「群れる」です。ソフトウェア開発の文脈では 1 つの問題やタスクを皆で群がって解決するとい
チームトポロジー を読んだ - 下林明正のブログ
必要にかられていて、社内でも読書会がはじまった。読書会はまだやってるけど、先行して読み終わった。愛称は「ちいとぽ」らしい。 チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計 作者:マシュー・スケルトン,マニュエル・パイス日本能率協会マネジメントセンターAmazon どういう本なのかは、訳者の方が用意してくれた以下の資料が良いのではないか。 自分が読み始めたモチベーションとしては、チームの分け方について知見を得たいというものだった。 shimobayashi.hatenablog.com 本を読んでみた感想としては、元々の自分の考え方もそんなに外してないことが分かって安心感があった。もちろん考慮の幅・深さ・質は違うので、この本を読んで良かった。 どれくらい根拠のある内容なのかはよく分からなかったけど、個人的にはこれまで勉強してきたことと整合的だった気がするので全体的にはす
Microsoft Word - Scrum- A Framework to Reduce Risk and Deliver Value Sooner_V2.1_Ja.docx
スクラム:リスクを軽減し早期に価値を提供するフレームワーク | Scrum.org © 2020 Scrum.org. All Rights Reserved. | 1 スクラム:リスクを軽減し早期に価値を 提供するフレームワーク スクラムの初学者や学び直したい⼈に向けた スクラムフレームワークの概要解説 CHRISTIAAN VERWIJS, BARRY OVEREEM, JOHANNES SCHARTAU (THE LIBERATORS) 著、⻑沢 智治 訳 | NOVEMBER 2020 序⽂ 「スクラムのことは気にしていない」と、私たちはときどき⾔うことがある。それは確かに 眉をひそめることであるが、私たちが⾔いたいのは、スクラムフレームワークそのものでは なく、スクラムフレームワークが何を可能にするのかが重要だということである。このよう な⾒⽅ができると、多くの理論的な疑問が⾃明
アジャイル手法提唱者が涙ぐんだ「日本発の論文」 | Japan Innovation Review powered by JBpress
アジャイル手法提唱者が涙ぐんだ「日本発の論文」 論文著者、野中郁次郎教授が指摘する「アジャイルの真髄」 新しいソフトウェア開発方法論「アジャイル開発」の一手法である「スクラム」の源流は、日本発の論文にあった。その論文著者の一人、野中郁次郎氏（一橋大学名誉教授、中小企業大学校総長）が語る「アジャイルの真髄」とは何か。（JBpress） 新しいソフトウェア開発手法として、さらに組織変革やビジネスの革新手法として注目を集めている「アジャイル」。「スクラム」はその中で最も普及している具体手法である。その「スクラム」提唱者の一人ジェフ・サザーランド氏が着想を得る原点となったのが、日本企業におけるイノベーションの成功要因を研究した日本発の論文なのだ。 サザーランド氏が、その論文を竹内弘高氏（現ハーバード・ビジネス・スクール教授）とともに執筆した野中郁次郎氏に実際に対面したのは、「スクラム」を提唱してか
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
KPTに慣れたチームがよりよい振り返りを行うために、K/P/Tのそれぞれにフォーカスをあてた考察
デイリースクラムいらなくなくなくなーい！？
