スクラムでもっと開発スピードを上げたいって思いませんか?スクラムやモブなどのアジャイル開発は、プロセスとマインドが大事でしたね。知的生産性を上げるマインド強化ちゃんとやっていますか?伝統な会社ほどマッチョ経営が根付いていて、中々知的生産性が上がらなくて困っていませんか?マネージメント3.0はそのソリュー…
こんにちは。PocochaでRelease Train Engineer(RTE)をしている山下です。 Pocochaでは大規模アジャイルフレームワークの一つであるSAFe®を導入しています。 どのような理由で導入したのか、どのように導入したのかについては こちら の記事をご覧下さい。 SAFe®に興味を持っていただけたでしょうか? この記事ではスクラムやXPをすでに導入していて大規模アジャイルフレームワークSAFe®の導入を検討している方を対象に、SAFe®の心臓と呼ばれているPIプランニングを詳しく紹介します。 PIプランニングは多数のアジャイルチームが協調し、一つの大きな目標に向かって協力するためのSAFe®の一大イベントです。 この記事が私たちと同じように異なるアジャイルチームのコミュニケーションや作業の調整に課題を抱えている方の助けになれば幸いです。 それではPIプランニングを学
近年のアジャイルムーブメントにおいて「職能横断チーム」は当たり前の概念になっています。ユーザーに価値を届けるのに必要なあらゆる機能をチームが備え自律的にコントロールすることで、リードタイムを短縮するとともに、イノベーションが起こりやすい環境を作ることができます。しかしながら、7〜8人を超える大きめの集団になってくると、開発の効率を著しく下げるアンチパターンを踏んでしまうことがあります。 「職能横断チーム」の実践におけるアンチパターン そのアンチパターンとは「いつも全員一緒」です。バックエンドエンジニアだろうとアプリエンジニアだろうと、デザイナーだろうとプランナーだろうと関係なくとにかく全員です。サイロ化のカウンターとしての「職能横断チーム」に囚われ過ぎてしまって、チーム内に部分集合を作ることを極端に避けてしまっている状態です。その結果、10人もいる会を開いて細かい相談で時間が伸びたり、そも
Failed #SquadGoals Spotify doesn’t use “the Spotify model” and neither should you. By Jeremiah Lee Sunday, April 19, 2020 • Listen • Watch • En français • 日本語で • Português (Brasil) About the cover illustration Of all the allures of startup culture, few are more desireable than the speed and nimbleness of a small team. Maintaining that feeling as a company grows is a challenge. In 2012, Spotify sha
みなさんこんにちは。@ryuzeeです。 昨年12月に新刊『チームトポロジー』が発売になったのでぜひよろしくお願いします。 アジャイルコーチや技術顧問の仕事は多岐にわたりますが、その1つに社内での講演やセミナーがあります。 今回、技術顧問先のイベントで登壇しましたので、その際の資料を公開します。 アジャイルとは直接関係ないものも多々含まれていますが、ネタということでご了承ください。 アジャイル全般QCDSを同時にすべて固定することはできない要件の決まったものを早く・安く作る方法ではない開発だけをアジャイルにしても意味がないアジャイルで請負契約は無理だと心得ようすべてがアジャイルに適しているわけではない大規模アジャイルは小さなアジャイルの成功後アジャイル導入を支援しようアジャイル推進での組織的な課題に取り組もう無駄な社内プロセスを廃止するよう働きかけよう効率ではなく成果に着目した組織設計をし
数年前、私はこんな絵を書いて、アジャイル開発やリーン開発のついての様々なプレゼンで用いた。 そこから、この絵は急速に広まっていった!記事、プレゼン、さらには本(Jeff Pattonの”User Story Mapping”という素晴らしい読み物なのだが)にまで至る所で姿を見せた。多くの人がこの絵は反復型開発、リーンスタートアップ、MVP(minimum viable product)の本質をよく捉えていると伝えてくれた。しかし、元の文脈から切り離して物事を捉える際にはごく自然なことであるのだが、この絵を誤解している人がいる。簡素化しすぎだと非難する人もいる。(正しい指摘である) この絵はあくまで比喩である。実際の車の開発の話ではなく、車を比喩とした一般的なプロダクトの開発の話なのである。 とにかく、これらのバズからこの考えの背景を話す時だと判断したのだ。 1つ目の例:not like
Register for free to elevate your testing career @ Experience 2022! 先日、第10回目となるmablコミュニティウェビナーを開催させていただきました。今回のテーマは「アジャイルテスティング(実践編)」です。 アジャイルテスティングについてさまざまな質問を井芹さんにぶつけたのですが、井芹さんは考える指針となる言葉を沢山教えて下さいました。アジャイル開発におけるQAの役割や責任、そしてアジャイルテスティングを読み解いていくイベントになったように思います。 なお、イベント動画を公開する予定でしたが、諸事情により今回は非公開とさせていただきました。申し訳ありません。 何名かの方から「イベントに参加できないからあとで見みたい!」とありがたいお言葉を頂いていたので、今回のレポートではイベントで議論された内容を整理してみたいと思います。「
I am proud to be one of the 17 founders/authors of the The Agile Manifesto back in 2001. I think it provided a jolt of energy, hope of a better way of doing things, of creating software and making the world work better. It was a pivotal turning point. But in the 14 years since then, we‘ve lost our way. The word “agile” has become sloganized; meaningless at best, jingoist at worst. We have large sw
4/26 に発売されます! 「ユニコーン企業のひみつ」をいただいて読みました。読みやすくて面白かったー。4/26 に発売されます!チームをリードしている人や組織づくりをしている人にはもちろんおすすめだし、メンバーの一員としてチームの中で仕事をしている人も「なるほどそんな風に仕事をしてるのかー!」って感じることができて面白いと思うー。あと、アジャイルな開発とかスクラムをやってる人ももう一度自分の大切にしているものを見直すことができるんじゃないかなぁ。ぜひどうぞ。 www.oreilly.co.jp ユニコーン企業はスクラムをやっていない この本の「ユニコーン企業」とか「テック企業」って「大きくなってもスタートアップみたいな働き方をしている企業」のことで、Google・Amazon・Facebook・Spotify のような企業を指してる。そういった企業が何を大切にしているか、どんな風に開発を
ARR20億円を3年で達成したエンジニア組織が実現したDeveloper eXperience~3つの落とし穴と乗り越え方~(ver2)
みなさんこんにちは、@ryuzeeです。 スクラムにおいてはフィードバックが重要です。プロセスに対するフィードバックはスプリントレトロスペクティブ、プロダクトに対するフィードバックはスプリントレビューを活用します。 今日はスプリントレビューについて、一般的な手順や注意点を紹介します。 なお、あくまで一般的な手順であることに注意してください。スクラムの基本は「透明性・検査・適応」です。自分たちで随時やり方を検査して、もっとうまくできるように適応していかなければ効果はあがりません。 スライドはこちらをご参照ください。 1. スプリントレビューの目的 2. スプリントレビューの参加者 3. スプリントレビューのアジェンダ(例) 4. スプリントレビューの事前準備 5. ステークホルダーへの質問(例) 6. 良いスプリントレビューの特徴 7. スプリントレビューのアンチパターン 1. スプリントレ
Agile Team Organisation: Squads, Chapters, Tribes and GuildsThere is a growing trend around agile company organization reorganization with Agile and Scrum. Why Reorganise?Obviously building a product that is flexible, high quality and that can react to market demand quickly is important, but for me having a process and organization that emulates this is as equally as important. “Don’t just fix the
アトランタで、リーン・ソフトウェア・アンド・システムズ・カンファレンス(Lean Software and Systems Conference)2010 が開催されています。 とても行きたかったのですが、今回はいけなったので、ちょっと起こっていることの概要を。プログラムはこちら。 http://atlanta2010.leanssc.org/agenda/ この LSSC というコンセプトは、もちろんソフトウェア開発の文脈ではアジャイルからはじまっていますが、より、Lean 運動の影響を強く受けており、工学との融合、マネジメント・リーダーシップとの融合、ソフトウェアとシステムの融合、を目指しています。Leanは、医療、建築、製品開発、の分野で現在とてもホットな領域で、さまざまな産業界が注目しているムーブメント。ソフトウェア開発では、Mary Poppendieck が先導を切ってアジャイ
Download the official Scrum Guide in over 30 different languages Select language & Download Scrum is a framework for developing and sustaining complex products. This Guide contains the definition of Scrum. This definition consists of Scrum’s accountabilities, events, artifacts, and the rules that bind them together. Ken Schwaber and Jeff Sutherland developed Scrum; the Scrum Guide is written and p
ログラスの選考プロセスにおけるアトラクト戦略 / Attraction strategy in Loglass interview process
みなさんこんにちは。@ryuzeeです。 スクラムにおいてプロダクトオーナーは非常に重要な役割を果たしますが、一方でうまくやるのが難しい役割でもあります。 たとえばプロダクトオーナーには、ビジネス価値を最大化する、プロダクトのビジョンを周りに示して理解させる、プロダクトバックログを管理する、ステークホルダーをマネージする、開発チームの成果物の受け入れ可否を判定するといった多岐に渡る責任があり、限られた時間の中でバランスを取りながらやっていかなければいけません。 今回は、こういうのは避けようというアンチパターンを紹介します。 そもそも…多忙すぎるプロダクトオーナー不在のプロダクトオーナースクラムイベントに参加しないプロダクトオーナー単にマネージャーやリーダーという理由だけのプロダクトオーナーそもそも複数人で意思決定権限が分散されたプロダクトオーナープロダクトオーナーとスクラムマスターを兼任す
Interaction Design Foundationはグローバルにデザインレベルの向上を目指す、デンマーク発の非営利団体です。 MVP(実用最小限の製品: minimum viable product)という考え方が広まったのは少し前のことです。MVPはFrank Robinson氏によって定義され、起業家であり学者のSteve Blank氏と、リーンスタートアップ(Lean Startup)を提唱したEric Ries氏という2人のプロダクトデザインの権威によって有名になりました。 MVPとは? 簡単に定義すると、MVPとは、製品を提供する上で必要最小限の機能のみをもつ、もっともシンプルな製品です。しかし一般的には、「顧客価値があり、利益を生み出せる最小限のもの」と考えられています。 MVP戦略においては、価値基準を理解することが決定的に重要です。たとえば、車輪は車輪だけではユーザ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く