スクラムが上手くいってないなら上手くいってる - やっとむでぽん
「スクラムでやっているんですが、問題が多くて、スクラム合わないのかなと思って……」 「問題あるならスクラムが上手くいってますね」 という会話をした。 スクラムをやっていて、いろいろ問題が起きる。スプリントゴールがわからないとか、チームの協力が難しいとか、プロダクトオーナーの権限がないとか。スクラムちゃんとできないなあ、うちには合わないのかなあ、と思う人は多いようだ。 だが、こうした問題が起きているならば、スクラムは正しく機能している。スクラムはチームや組織の問題を検出し、明らかにする仕組みだ。みんなが問題を意識できているなら、上手くいっているわけだ。「うちは〇〇だから、スクラム難しい」と思ったなら、その〇〇を解消できれば仕事がもっと上手くいき、よりよい成果が作れる。 スクラムが上手くいくと、問題が次々に現れる。問題を次々に解消していくと、仕事しやすくなり、コミュニケーションがスムーズになり
開発チーム作成ガイドを公開します - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは。シニアスクラムマスターの天野 @ama_ch です。 サイボウズの開発組織において、今後の成長を加速させるためには、組織の基本単位をスクラムチームのような自律的な小さなチームにしてスケールさせることが非常に大切だと考えています。サイボウズは比較的スクラムが普及している組織ではありますが、組織内のすべてのチームがスクラムを採用しているわけではありません。 フレームワークとしてスクラムを採用するかどうかはチームの自由です。しかし、健全なチーム環境を整えることはすべてのチームにとって重要です。チームやチームワークに関する情報は巷に多く存在しますが、我々のようにすでにある程度の規模で活動しているプロダクト開発組織で、チーム環境を整えるために実践的に使える情報がないことが悩みでした。 そこで、これまでのチームに関する学びと実践を踏まえ、サイボウズの開発組織の文脈において、スクラムを実践し
スクラムマスターがやること、やらないこと - アジャイルトレーニングの専門家に聞いてみた - エンジニアHub｜Webエンジニアのキャリアを考える！
スクラムマスターがやること、やらないこと - アジャイルトレーニングの専門家に聞いてみた スクラムマスターとして日々仕事に邁進していても、教科書どおりにいかないこともしばしば。イベントに人が来ない……、タスク終わらなさそう……などなど、スクラムマスターが直面しがちな、「あるある」な悩みを、アジャイルコーチの吉羽龍太郎さんに相談してみました。 イベントマネジメントの心得 スプリントレビューでは言いたい放題言わせよう！ スプリントの期間延長は絶対NG 大切なのは原因の究明 スコープと期限の両方を守るのは難しい よいチームを作るためにスクラムマスターができること アジャイル開発の定番手法ともいえる「スクラム」。開発チームにスクラムを導入し、効率的に開発を進めるには、スクラムマスターの手腕が欠かせません。しかし、いざスクラムを運用しようにも、現実には教科書どおりいかない場面もあるでしょう。 イベン
デザイナーとスクラム開発｜といとい
こんにちは。@toi_toi_yです。 サイボウズという会社でkintoneというプロダクトのデザインをしてます。 自分は数年前、kintone開発チームがスクラム開発を始めた頃にkintone専任のデザイナーとしてチームにジョインしました。 それから様々な変化がありつつもずっとスクラム開発のなかでデザイナーをやってきました。 というわけで、デザイナーとスクラム開発の話を書きます。 サイボウズのスクラム開発については弊社スクラムマスターの資料をご覧ください。 https://speakerdeck.com/ama_ch kintone開発チームのスクラム（2019年現在）- スプリントは1週間 - 開発チームはPG×3〜4人のサブチームが4つある - デザイナーは1人（+ チーム外のデザイナーが手伝ってくれてる） - 開発はモブプログラミングで進める。デザイナーも適宜必要に応じて参加するき
認定スクラムマスターになりました | おそらくはそれさえも平凡な日々
https://www.scrumalliance.org/community/profile/mmatsuki2 アトラクタ社の認定スクラムマスター研修を受け、テストも合格し、晴れて認定スクラムマスターとなりました。だからなんだというわけでもないですが、スクラムに関する交流や雑談などしたいとかあれば、ご相談ください。 受けたのは以下の研修で、Gabrielle Benefieldさんと原田騎郎さんが講師でした。 https://www.attractor.co.jp/info/csm-201905/ 比較的長年アジャイルやスクラムに関わってきたので、良い知識の再整理の機会になりました。ありがとうございました。 私とスクラム 意外かもしれませんが、僕はそれなりにアジャイルやスクラムを経験してきました。とはいえ、今の開発者が押さえておくべき技術分野の一つなので、人並みくらいかもしれません。M
あえて、スクラムを「捨てる」勇気 - 「越境」のための言語化とプラクティス選び - Lean Baseball
DevLOVE Advent Calendar 2018、18日目のエントリーです. と、同時に「Retty Scrum Meet up〜2018.12.18〜」でLTやったよ！っていう報告でもあります. 別に釣りたいわけじゃありません（汗） そんな話をこちらでしてきました. retty.connpass.com 自分がどうやって「越境」してきたか（&これからどう「越境」するか）についてサクサクと書きたいと思います. TL;DR サービスの価値を高める、チームを良くする手法・プラクティスは必ずしも一つ（アジャイル・スクラムetc...）ではない サービスやチームのフェーズ、メンバー次第であえてスクラムを「捨てる」のも一つの手 「越境」とは、「挑戦する」勇気と共に、「やることをやりきる、やらなくていいことは捨てる」意志と行動力がメチャクチャ大事 おしながき TL;DR おしながき Who a
誰がプロダクトオーナーをやるとよいのか？
みなさんこんにちは。@ryuzeeです。 最近立て続けにプロダクトオーナーを誰がやるとよいのか聞かれることがあったので、パターンとメリット・デメリットを整理しておきます。 なお、組織のサイズや業種、扱っているプロダクトによっても変わってくるので、考え方のロジックとして読んでいただければと思います。 プロダクトオーナーとは？まず最初に前提として、プロダクトオーナーの責任ややるべきことをスクラムガイド（2017）で確認しましょう。 5ページ：プロダクトオーナー プロダクトオーナーは、開発チームから生み出されるプロダクトの価値の最大化に責任を持つ。組織・スクラムチーム・個人によって、その方法はさまざまである。 プロダクトオーナーは、プロダクトバックログの管理に責任を持つ1人の人間である。 (中略) プロダクトオーナーは1人の人間であり、委員会ではない。委員会の要求をプロダクトバックログに反映する
組織変更したら部長がいなくなりました - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、最近愛媛から広島に移住した組織運営チームの水戸です。 2019年からサイボウズの開発本部から職能・地域毎に分かれた部署がなくなり、チーム主体の組織になりました。 組織変更をオープンに議論するというチャレンジングな試みの中で、新組織の理想はユーザー価値の最大化に定まり、個人やチームがより主体的に動ける組織構造に変わりました。 この記事では私がファシリテートを担当した組織変更をご紹介します。 開発本部の状況 開発本部の役割は製品を開発することです。 2018年までの開発本部はマトリクス組織を採用しており、プロダクト開発チームには様々な職能・地域毎に分かれた部署のメンバーが所属していました。 この組織構造は事業の中心がオンプレミスだった10年以上前から、事業の中心がクラウドに移った2018年に至るまで変わっていません。 一方、プロダクト開発チームに求められるものは大きく変わりました。
Chrome Github Points - GitHubのIssueでストーリーポイントを管理
MOONGIFTはオープンソース・ソフトウェアを紹介するブログです。2021年07月16日で更新停止しました 開発すると必ず工数がかかります。そのため、やらなければならない数あるタスクの中からなるべく小さなコストで大きな成果を達成できるものを選択する必要があります。その際に使われるのがストーリーポイントです。 ストーリーポイントを使うことで各タスクの相対的な大きさが可視化されます。そしてGitHub Issueとストーリーポイントを連携させる機能拡張がChrome Github Pointsです。 Chrome Github Pointsの使い方 各Issueに対してポイントを指定できます。 一覧ではIssue、Pull Requestそして合計でのポイントを確認できます。 プロジェクト機能でも同様にポイントが確認できます。 オプションです。 Chrome Github Pointsを使う
クリスと #NoEstimates について立ち話をして思ったこと - satoryuの日記
先日のRSGT2019の3日目に開催されたOSTにて、基調講演で来てくれていたクリス・ルーシャンに #NoEstimates について少し話を聞いてみたので、それのザックリとしたメモとして書き残しておく。 自分が途中から参加したテーブルのテーマは「見積もりをすることのメリット」だった。 自分はスタッフ業で聞けなかったのだけど、どうやらクリスは基調講演で、見積もりすることのデメリットについて語り、#NoEstimates をやっているという話をしたようだ*1。そこで、このテーブルでは、見積もりすることのデメリットだけではなく、メリットについても取り上げ、見積もりの可否について議論していた*2。 そこにクリスが覗きに来てくれたので、ちょっと話を聞いてみた。 超意訳になるのだけれど、そこはご容赦いただきたい。 さとう（以下、さ）: マイルストーンとかロードマップみたいな長期間の計画って持ってるの
#RSGT2019 に行ってきたメモ（これにて完了） - Mitsuyuki.Shiiba
昨日は、帰りの新幹線でさらっと感想を書いたのだけど #RSGT2019 に行ってきたメモ - Mitsuyuki.Shiiba どうもこのままではしばらく余韻に浸ってしまって、来月喋らせてもらうスクフェスへの頭の切り替えに時間がかかりそうなので。今日は感謝を込めてもうちょっと詳しく書いて、RSGT2019を自分の中で完了させておこうと思う。こんな流れかな。 RSGT? 1日目 2日目 3日目 RSGT2019 あとがき ## RSGT？ 2019.scrumgatheringtokyo.org よたさんが「カンファレンスじゃなくてギャザリング」って言っていた通り、セッションだけじゃなくて参加者同士の交流が中心にあるイベント。僕自身は、そこまで人との交流が得意な方ではないのだけど、ここは敬意にあふれていて、意見や立場の違う人達がお互いの違いを尊重しあう空気に満ちているので、自然と「お話したい
#RSGT2019 ちゃんとやってるのに なんかうまくいかないスクラム からの脱出
Regional Scrum Gathering Tokyo 2019
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
東名阪をまたいだLeSS HugeにおいてScrum Masterとして実践したこと #RSGT2019
スクラムチームをやめて、20人でカンバン運用してきた半年間の軌跡 / Stop Scrum Start Kanban