現実世界のアジャイルソフトウェア開発：変化への対応と計画
この記事は、Michael Parkerの「Agile Software in the Real World: Responding vs Planning」を本人の許諾を得て日本語訳したものです。Michael ParkerはDocker, IncのSenior Software Engineerで、Docker HubやDocker Desktopなどのツールの開発に携わっています。日本語訳の誤りなど、お気づきの点があれば御連絡ください。 「アジャイルソフトウェア開発宣言」にある４行のうち、この記事では最後の１行に焦点をあてている。 計画に従うことよりも変化への対応―アジャイルソフトウェア開発宣言 計画しすぎないようにしようソフトウェア開発プロジェクトの計画は難しいものだ。誰もが成功を確信したうえでプロジェクトを開始したいと考えている。しかし、どうすればプロジェクトの成功を予め確信でき
The Problem with Scrum Experts
Recently, I stumbled upon the paper “Nothing is Written — Learning is an Adventure” by Johnnie Moore & Viv McWaters. I loved every part of it and felt myself nodding in agreement continuously. When it comes to training & teaching, I fully agree with statements like… “Rather than giving people reassuring — right answers — we may do better to model experimentation, curiosity, and openness.” and… “Fo
The Next Iteration of the Scrum Guide: What to expect?
What can we expect from the next Scrum Guide?The definition of Scrum is hosted at ScrumGuides.org. Since the publication of ‘the rules of the game’ in 2010, this definition has been updated roughly once every 18 months. The last update was in November 2017, and it looks like another is on the way. What will be added? What will be removed? What will be changed? In this post, I look ahead and try to
The dangers of Agile for your organization | by Marty de Jonge | Serious Scrum | Medium
Nowadays you can read and hear everywhere that your organization has to switch to an Agile way of working and in particular by using the Scrum framework. The promised advantages are so huge that organizations are almost forced to switch to Agile in order to remain viable at all. And be honest, who doesn’t want things like: - Higher productivity - Shorter time-to-market - Increased customer satisfa
配属初日にデプロイする
春なので、新卒者が現場に入る時期ですね。弊チームでは、配属初日に何かの機能のデプロイをしてもらうということを数年間続けているので、その話をします。 なぜ初日が大事なのか「開発者として何かをデプロイするという行為は価値提供につながるから」というのが理由だ。他の行為、例えばアーキテクチャやドメインの把握、ミーティングから名刺交換に至るまで、そいつらは成果を出すためのオマケにすぎない。あ、名刺交換が役に立つかはわからん。 新卒者向けにもやるし、中途採用や社内異動、インターンの受け入れのときもやっている。 まあとにかく、デプロイするっていう我々の仕事を一回りすることで、成果を上げていくリズムを作ることに役立つはずだと考えて、続けている。 アイデア自体は新しいものではなく、昔どこかで読んだ記憶はある。 準備は？初日のタスクとしてどれが良さそうかを選ぶくらいだ。過去に選んだものとして、例えば: UIの
『闇鍋』で振り返りをやってみる
概要闇鍋とは、ryuzeeさんが提案したメンバーが議論したいこと・改善したいことを付箋に無記名で書いて箱に入れます。ここから誰かが1つを引いてそれについて深掘りして議論していく振り返り方法です。 手順はシンプルで以下になります。 (任意)テーマを決めます。 例えば、普段の振り返りで出てこないような『理想のプロダクト』『理想のチーム』など,etc…メンバーがモクモクと付箋に議論したいこと・改善したいことを記載して、箱をいれ闇鍋を完成させる ※10mファシリテーター(例)の人が1つを引いて議題を決めて、皆に共有する ※1mあとは、ホワイトボードを使いながら議論を深める。効果予測KPTやYWTなどは、複数の問題点に議論が散らばるので、闇鍋のようにひとつを深掘りするといったことがしにくい。※時間的にも皆が共通して同じものを課題と感じているのであれば、それが引かれる可能性が高いポイント以下に実施する
回答: スクラムマスターを雇う時に聞いてみるとよい38個の質問
採用の話がだいすきなみなさんこんにちは。@ryuzee です。 アジャイル開発をはじめた当初はだいたいパイロットチームを作って、そこでうまくいくと組織内に横展開していくパターンが多いと思いますが、そのときに困るのがスクラムマスターです。… では、始めよう。 スクラムマスターの役割についてアジャイルマニフェストでは「プロセスやツールよりも個人と対話を」といっている。プロセスを守らせるスクラムマスターは、それとは反対のことをしているのではないか？ 私もそう思うので、プロセスを守らせる方針は取らないし、プロセスを守らせるスクラムマスターは信用していない。 自分の組織でアジャイルがうまくいっていることを示す兆候は何か？また自分の働きが成功している兆候は何か？ 事業としてうまく行っていること、そしてみんなが自由に働けていること。 追跡しないといけないメトリクスはあるか？もしそうだとしたら何の目的でど
スクラムチームのためのカンバンガイド by Scrum.org
※本記事は旧版です。最新版（2019年9月）はオフィシャルサイトからPDFをダウンロード可能です。 この作品は The Kanban Guide for Scrum Teams の翻訳です。クリエイティブ・コモンズ 表示 — 継承 4.0 国際 ライセンスの下に提供されています。 目的カンバンにおけるフローベースの考え方は、スクラムフレームワークとその導入を強化・補完する。チームがこれからスクラムを使う場合でも、これまで長年スクラムを使ってきた場合でも、カンバンは適用可能である。 この「スクラムチームのためのカンバンガイド」は、Scrum.orgのコミュニティのメンバーとカンバンのコミュニティのリーダーがコラボレーションして生み出した結果である。その両者が協力して「スクラムチームのためのカンバンガイド」を支援している。カンバンとスクラムを組み合わせれば、プロのソフトウェアの実践者が恩恵を受
10 Experiments With Product Backlog Refinement
It might feel frustrating to practitioners at times, but Scrum does not prescribe ‘how’ to do certain things. Many Scrum practices only emerge with experimentation, and this is in fact the best way to build a shared understanding of context with a Scrum team. Over the last few months, I’ve been experimenting together with one team in relation to how we do Product Backlog Refinement. With this team
“We don’t try out new things - what if it fails?” – Serious Scrum – Medium
The Sprint Retrospective is a pivotal Scrum event: “The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint. “ — SG A plan for improvement. How do you know something is an improvement? And when you can’t answer this question, should you plan to work on it? Does this question appear far-fetched to you? T
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Do you really have to do Scrum by the book? About ScrumBut, ScrumAnd and maturity
Four types of Product Managers and how to deal with them
Do You Want to be a Product Owner? You Better Know What Awaits!
Leveraging the Sprint Review to simplify your stakeholder management
A letter from a fake Product Owner
Why Innovative Scrum Teams Need a Safe Space to “Fail” and How to Create One
Here’s what's wrong with maturity models
Apply FOCUS to set great Sprint Goals
The Evolution of the Scrum Guide— ‘10 to ‘19
What Scrum and Super Mario Have in Common – Serious Scrum – Medium