• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Agileと組織
 

Agileと組織

on

  • 9,399 views

2011/10/8のAgile Tour Osakaで講演した際の資料です。

2011/10/8のAgile Tour Osakaで講演した際の資料です。

Statistics

Views

Total Views
9,399
Views on SlideShare
7,270
Embed Views
2,129

Actions

Likes
41
Downloads
94
Comments
0

13 Embeds 2,129

http://www.ryuzee.com 1271
http://kaorun55.hatenablog.jp 467
http://pub.ne.jp 283
http://d.hatena.ne.jp 78
http://paper.li 11
https://si0.twimg.com 4
http://webcache.googleusercontent.com 3
http://a0.twimg.com 3
http://176.34.61.176 2
http://b.hatena.ne.jp 2
https://twimg0-a.akamaihd.net 2
https://twitter.com 2
http://us-w1.rockmelt.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Agileと組織 Agileと組織 Presentation Transcript

    • Agileと組織2011/10/8 Agile Tour OsakaRyutaro YOSHIBA http://bit.ly/nRQ6dC
    • 吉羽龍太郎アジャイルコーチhttp://www.ryuzee.com/
    • ???
    • Scrum Boot Camp
    • 本日の資料は後日公開します
    • よろしくお願いします
    • アジェンダ 企業のおかれた状況 „10分‟ なぜAgileなのか „10分‟ Scrumとは „15分‟ Agileな組織 „20分‟ まとめ・質疑応答 „5分‟※あくまで予定です…
    • http://bit.ly/ptKnqR1. 企業のおかれた状況
    • ビジネスをとりまく環境の変化
    • IT投資は業務効率化から戦略実現へ
    • 以前の競争http://bit.ly/rioQDZ
    • 現在の競争 競争の速度の変化
    • 迅速な 意思決定 が必要http://bit.ly/pccwAN
    • 意思決定をもとに素早く具現化する必要 http://bit.ly/r1ziWL
    • ビジネスモデルの賞味期限が短縮
    • 変化への対応“事前に綿密” にたてた計画を“長期間遵守” して大丈夫なのか?
    • 変化への対応“変化が起こる” ことを前提に“頻繁に軌道修正” することが必要http://bit.ly/oX9ImQ
    • 変化に対応できなければマーケットから見捨てられる
    • 価値がなくなれば滅びるhttp://bit.ly/qJg8EX
    • 継続的な イノベーション の創発http://bit.ly/nLACes
    • “イノベーションは「知」の創造プロセスであり、知の創造は単に理論だけではなく、実践を通して知識を磨き、知恵にするものである”“企業の優れた業績は研究開発投資の増加に要因があるのではなく、組織のイノベーション・プロセスの質による”野中郁次郎氏の発言要旨
    • http://www.slideshare.net/InnovationSprint2011/2011-6794551
    • プロセス プロダクトイノベーション イノベーションhttp://bit.ly/qpjFXr http://bit.ly/ornfUo
    • http://bit.ly/nMHv6P組織のマネージャや上級管理職、経営者の一部は変化に踏み出せない。 組織に対する背任
    • コンウェイの法則 “Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.”http://bit.ly/oIUrUI
    • マインドイノベーション http://bit.ly/nrDcZf
    • 2. なぜAgileなのか?
    • ソフトウェアの不確実性 不確実性コーン From 10 Deadly Sins of Software Estimation by Steve McConnell, ©2002-2007
    • 納期の確率分布 ソフトウェアの納期予測は確率分布である 一般的にプロジェクトマネージャがリリース可能日を設定する場合、 最もリリースできる確率が高い日を選ぶが、その日にリリースできな い可能性の方が高い
    • 付加価値を高めない各種現象や結果をムダと呼ぶ
    • 作り過ぎのムダ手待ちのムダ運搬のムダ加工のムダ在庫のムダ動作のムダ不良をつくるムダ
    • システムの機能の利用割合 いつも使う 7% よく使う 13 % 45 % たまに使う 16 % ほとんど使わない 19 % まったく使わないStandishの2000年の調査より
    • http://bit.ly/olku5164%の機能は、使われない
    • “Our highest priority isto satisfy the customerthrough early and continuous delivery ofvaluable software.”
    • Agileはリスクマネジメント ビジネス環境が変化するリスク 事前の予測が外れるリスク 必要なものが必要な時に出来上がらないリスク 無駄なコストが発生するリスク リスク度 時間の経過
    • Enterprise Value Creation Continuous DeliveryAdaptability / Agility Continuous Deploy Continuous Integration Iterative Development Strategic Impact
    • 経営 Lean 者企業活動自体の全体最適化 Scrum マ ネー価値あるものから継続的に ジャ 製品を届ける XP チー 技術面を高める ム
    • ツールやプラクティスを導入するとアジャイルな開発になるというのは幻想 http://bit.ly/pQrRmy
    • 我々が解決すべき問題は何なのか? http://bit.ly/qgox0e
    • http://www.flickr.com/photos/john_scone/493915787/3. Scrumとは?
    • http://www.flickr.com/photos/nocallerid_man/3638360458/
    • “Scrum is a framework for surfacing organizational dysfunction.” Tobias MayerScrumは組織の機能不全を明るみに出 すためのフレームワークである
    • 守破離 http://bit.ly/qRvi51
    • 野中郁次郎氏 ジェフ・ サザーランド氏
    • ビジネス価値を 早期に顧客に提供するhttp://www.flickr.com/photos/will-lion/2737995511/
    • 動作するソフトウェアを 繰り返し提供する
    • 頻繁に届ける
    • 顧客は優先順位をつける
    • 2〜4週間に 区切って 繰り返すhttp://www.flickr.com/photos/tonivc/2283676770/
    • 自己組織化されたチームhttp://www.flickr.com/photos/pasukaru76/4075888286/
    • 検査と適応
    • Scrum フレームワーク ロール •プロダクトオーナー •スクラムマスター •チーム ミーティング •スプリント計画 •スプリントレビュー •スプリント振り返り •デイリースクラム 道具 •プロダクトバックログ •スプリントバックログ •バーンダウンチャート
    • プロダクトオーナー スクラムマスター チーム (7±2人) ステークホルダー製品に対して責任をもち機能 スクラムプロセスがうまく プロダクトの開発を行う。 製品の利用者、出資者、管理職に優先順位を付ける いくようにする。 製品の成功に向けて最大限 などの利害関係者。鶏と称す 外部からチームを守る の努力をコミットする プロダクトバックログ デイリースクラム 製品の機能をストーリー形式で記載 毎日チームが以下の3つの質問に答える プロダクトオーナーが優先順位を付け、プラ ・昨日やったこと ンニングポーカーで相対見積もり。 ・今日やること 項目の追加はいつでも自由だが実施有無や優 ・困っていること 先順位はPOが決める。 バーンダウンチャート Doneの定義 スプリントタスクの「推定残り時間」を 何をもって「完了」とするかを 更新してグラフにプロットする 定義したリスト スプリント計画会議 プロダクトバックログを再度分析・評価し、 スプリント そのスプリントで開発するプロダクトバック 最大4週間までのタイムボックス ログアイテムを選択する。また選択した項目 各スプリントの長さは同一。この間は外部 をタスクにばらす からの変更を受け入れない 複 数 回タスク ス時間で見 プ積もり リ ン 毎日の繰り返し ト をスプリントバックログ スプリントレビュー ふりかえり 出荷可能な 繰そのスプリント期間中に行う スプリント中の成果である り スプリントの中での改善事項 製品の増分 返タスクのリスト 動作するソフトウェアをデモ を話合い次に繋げる する す
    • ロールhttp://www.flickr.com/photos/basictheory/4056636664/
    • プロダクトオーナー 製品の責任者 優先順位を決めたり見直す チームの成果を検証する
    • スクラムマスター スクラムプロセスをうまくまわす 外部の干渉からチームを守る 障害事項を解決する
    • チーム モノを作る 機能横断的で自己組織化されている 3〜9人でフルタイム参加
    • 豚と鶏POとSMとチーム ユーザー、マネージャ、 ステークホルダー…
    • プロダクトオーナー スクラムマスター チーム (7±2人) ステークホルダー製品に対して責任をもち機能 スクラムプロセスがうまく プロダクトの開発を行う。 製品の利用者、出資者、管理職に優先順位を付ける いくようにする。 製品の成功に向けて最大限 などの利害関係者。鶏と称す 外部からチームを守る の努力をコミットする プロダクトバックログ デイリースクラム 製品の機能をストーリー形式で記載 毎日チームが以下の3つの質問に答える プロダクトオーナーが優先順位を付け、プラ ・昨日やったこと ンニングポーカーで相対見積もり。 ・今日やること 項目の追加はいつでも自由だが実施有無や優 ・困っていること 先順位はPOが決める。 バーンダウンチャート Doneの定義 スプリントタスクの「推定残り時間」を 何をもって「完了」とするかを 更新してグラフにプロットする 定義したリスト スプリント計画会議 プロダクトバックログを再度分析・評価し、 スプリント そのスプリントで開発するプロダクトバック 最大4週間までのタイムボックス ログアイテムを選択する。また選択した項目 各スプリントの長さは同一。この間は外部 をタスクにばらす からの変更を受け入れない 複 数 回タスク ス時間で見 プ積もり リ ン 毎日の繰り返し ト をスプリントバックログ スプリントレビュー ふりかえり 出荷可能な 繰そのスプリント期間中に行う スプリント中の成果である り スプリントの中での改善事項 製品の増分 返タスクのリスト 動作するソフトウェアをデモ を話合い次に繋げる する す
    • Doneの定義何ができたら完了なのかを決める
    • プロダクトオーナー スクラムマスター チーム (7±2人) ステークホルダー製品に対して責任をもち機能 スクラムプロセスがうまく プロダクトの開発を行う。 製品の利用者、出資者、管理職に優先順位を付ける いくようにする。 製品の成功に向けて最大限 などの利害関係者。鶏と称す 外部からチームを守る の努力をコミットする プロダクトバックログ デイリースクラム 製品の機能をストーリー形式で記載 毎日チームが以下の3つの質問に答える プロダクトオーナーが優先順位を付け、プラ ・昨日やったこと ンニングポーカーで相対見積もり。 ・今日やること 項目の追加はいつでも自由だが実施有無や優 ・困っていること 先順位はPOが決める。 バーンダウンチャート Doneの定義 スプリントタスクの「推定残り時間」を 何をもって「完了」とするかを 更新してグラフにプロットする 定義したリスト スプリント計画会議 プロダクトバックログを再度分析・評価し、 スプリント そのスプリントで開発するプロダクトバック 最大4週間までのタイムボックス ログアイテムを選択する。また選択した項目 各スプリントの長さは同一。この間は外部 をタスクにばらす からの変更を受け入れない 複 数 回タスク ス時間で見 プ積もり リ ン 毎日の繰り返し ト をスプリントバックログ スプリントレビュー ふりかえり 出荷可能な 繰そのスプリント期間中に行う スプリント中の成果である り スプリントの中での改善事項 製品の増分 返タスクのリスト 動作するソフトウェアをデモ を話合い次に繋げる する す
    • プロダクトバックログ# バックログアイテム 優先順位 見積り1 ゲストとしてホテルを予約することができる 1 32 ゲストとしてホテルの予約をキャンセルできる 2 53 ゲストとして予約日時を変更することができる 3 3 ホテルの従業員として, 部屋ごとの4 4 8 収支レポートを作成することができる 要求の一覧5 システム管理者として、システムの エラー状況をログで確認できる 5 8 POによって優先順位がつけられる… ・・・ … 20 定期的に中身と優先順位を見直す… ・・・ … 40
    • 相対的な規模の見積もり
    • プランニングポーカー
    • プロダクトオーナー スクラムマスター チーム (7±2人) ステークホルダー製品に対して責任をもち機能 スクラムプロセスがうまく プロダクトの開発を行う。 製品の利用者、出資者、管理職に優先順位を付ける いくようにする。 製品の成功に向けて最大限 などの利害関係者。鶏と称す 外部からチームを守る の努力をコミットする プロダクトバックログ デイリースクラム 製品の機能をストーリー形式で記載 毎日チームが以下の3つの質問に答える プロダクトオーナーが優先順位を付け、プラ ・昨日やったこと ンニングポーカーで相対見積もり。 ・今日やること 項目の追加はいつでも自由だが実施有無や優 ・困っていること 先順位はPOが決める。 バーンダウンチャート Doneの定義 スプリントタスクの「推定残り時間」を 何をもって「完了」とするかを 更新してグラフにプロットする 定義したリスト スプリント計画会議 プロダクトバックログを再度分析・評価し、 スプリント そのスプリントで開発するプロダクトバック 最大4週間までのタイムボックス ログアイテムを選択する。また選択した項目 各スプリントの長さは同一。この間は外部 をタスクにばらす からの変更を受け入れない 複 数 回タスク ス時間で見 プ積もり リ ン 毎日の繰り返し ト をスプリントバックログ スプリントレビュー ふりかえり 出荷可能な 繰そのスプリント期間中に行う スプリント中の成果である り スプリントの中での改善事項 製品の増分 返タスクのリスト 動作するソフトウェアをデモ を話合い次に繋げる する す
    • スプリントとは? 最大4週間までの固定の期間 この期間内で動作するソフトウェアを作る 外部からの変更は受け付けない
    • スプリント計画1 プロダクトバックログから項目を選び 何を作るのか決める 作る量は過去のペースから決める
    • スプリント計画2 どうやって作るか決める 作業を細分化してタスクにする タスクを理想時間で見積もる
    • プロダクトオーナー スクラムマスター チーム (7±2人) ステークホルダー製品に対して責任をもち機能 スクラムプロセスがうまく プロダクトの開発を行う。 製品の利用者、出資者、管理職に優先順位を付ける いくようにする。 製品の成功に向けて最大限 などの利害関係者。鶏と称す 外部からチームを守る の努力をコミットする プロダクトバックログ デイリースクラム 製品の機能をストーリー形式で記載 毎日チームが以下の3つの質問に答える プロダクトオーナーが優先順位を付け、プラ ・昨日やったこと ンニングポーカーで相対見積もり。 ・今日やること 項目の追加はいつでも自由だが実施有無や優 ・困っていること 先順位はPOが決める。 バーンダウンチャート Doneの定義 スプリントタスクの「推定残り時間」を 何をもって「完了」とするかを 更新してグラフにプロットする 定義したリスト スプリント計画会議 プロダクトバックログを再度分析・評価し、 スプリント そのスプリントで開発するプロダクトバック 最大4週間までのタイムボックス ログアイテムを選択する。また選択した項目 各スプリントの長さは同一。この間は外部 をタスクにばらす からの変更を受け入れない 複 数 回タスク ス時間で見 プ積もり リ ン 毎日の繰り返し ト をスプリントバックログ スプリントレビュー ふりかえり 出荷可能な 繰そのスプリント期間中に行う スプリント中の成果である り スプリントの中での改善事項 製品の増分 返タスクのリスト 動作するソフトウェアをデモ を話合い次に繋げる する す
    • スプリントバックログNo No 内容 見積り時間#1 幹事として、飲み会企画の作成をすることができる 1 飲み会情報管理テーブルの作成 1 2 コントローラーの作成 4 3 画面htmlの作成 2 4 テストコードの作成 4 5 テストデータの作成 2#6 幹事として、参加候補者を追加することが出来る 1 参加者テーブルを作成 1 2 参加者追加用画面htmlを作成 1 スプリント計画会議2で決めたタスクの一覧 3 コントローラーを作成 2 チーム全員でタスクを消化する 4 テストコードの作成 2 5 テストデータの作成 1 毎日残り想定所要時間を更新する
    • スプリントバーンダウンチャート http://www.flickr.com/photos/kakutani/2761992149/ 毎日スプリントバックログの残時間を合計し グラフにプロットする 線の推移を見ることで異常を検知できる
    • プロダクトオーナー スクラムマスター チーム (7±2人) ステークホルダー製品に対して責任をもち機能 スクラムプロセスがうまく プロダクトの開発を行う。 製品の利用者、出資者、管理職に優先順位を付ける いくようにする。 製品の成功に向けて最大限 などの利害関係者。鶏と称す 外部からチームを守る の努力をコミットする プロダクトバックログ デイリースクラム 製品の機能をストーリー形式で記載 毎日チームが以下の3つの質問に答える プロダクトオーナーが優先順位を付け、プラ ・昨日やったこと ンニングポーカーで相対見積もり。 ・今日やること 項目の追加はいつでも自由だが実施有無や優 ・困っていること 先順位はPOが決める。 バーンダウンチャート Doneの定義 スプリントタスクの「推定残り時間」を 何をもって「完了」とするかを 更新してグラフにプロットする 定義したリスト スプリント計画会議 プロダクトバックログを再度分析・評価し、 スプリント そのスプリントで開発するプロダクトバック 最大4週間までのタイムボックス ログアイテムを選択する。また選択した項目 各スプリントの長さは同一。この間は外部 をタスクにばらす からの変更を受け入れない 複 数 回タスク ス時間で見 プ積もり リ ン 毎日の繰り返し ト をスプリントバックログ スプリントレビュー ふりかえり 出荷可能な 繰そのスプリント期間中に行う スプリント中の成果である り スプリントの中での改善事項 製品の増分 返タスクのリスト 動作するソフトウェアをデモ を話合い次に繋げる する す
    • デイリースクラム  毎日15分間厳守、起立して行う  3つの質問に答える  情報共有と迅速な意思決定のための場http://www.flickr.com/photos/karthikc/333796551/
    • 全員が3つの質問に答える 昨日やったこと 今日やること 困っていること
    • スプリントレビュー http://www.flickr.com/photos/gycib/3276543776/ チームが作った動作するモノを見せる 参加者からフィードバックを受ける このまま先に進めるかを確認する
    • プロダクトオーナー スクラムマスター チーム (7±2人) ステークホルダー製品に対して責任をもち機能 スクラムプロセスがうまく プロダクトの開発を行う。 製品の利用者、出資者、管理職に優先順位を付ける いくようにする。 製品の成功に向けて最大限 などの利害関係者。鶏と称す 外部からチームを守る の努力をコミットする プロダクトバックログ デイリースクラム 製品の機能をストーリー形式で記載 毎日チームが以下の3つの質問に答える プロダクトオーナーが優先順位を付け、プラ ・昨日やったこと ンニングポーカーで相対見積もり。 ・今日やること 項目の追加はいつでも自由だが実施有無や優 ・困っていること 先順位はPOが決める。 バーンダウンチャート Doneの定義 スプリントタスクの「推定残り時間」を 何をもって「完了」とするかを 更新してグラフにプロットする 定義したリスト スプリント計画会議 プロダクトバックログを再度分析・評価し、 スプリント そのスプリントで開発するプロダクトバック 最大4週間までのタイムボックス ログアイテムを選択する。また選択した項目 各スプリントの長さは同一。この間は外部 をタスクにばらす からの変更を受け入れない 複 数 回タスク ス時間で見 プ積もり リ ン 毎日の繰り返し ト をスプリントバックログ スプリントレビュー ふりかえり 出荷可能な 繰そのスプリント期間中に行う スプリント中の成果である り スプリントの中での改善事項 製品の増分 返タスクのリスト 動作するソフトウェアをデモ を話合い次に繋げる する す
    • ふりかえり 短い間隔でうまくいったこと、うまく行かな かったことを確認する 次はもっと良くする(できることから)
    • プロダクトオーナー スクラムマスター チーム (7±2人) ステークホルダー製品に対して責任をもち機能 スクラムプロセスがうまく プロダクトの開発を行う。 製品の利用者、出資者、管理職に優先順位を付ける いくようにする。 製品の成功に向けて最大限 などの利害関係者。鶏と称す 外部からチームを守る の努力をコミットする プロダクトバックログ デイリースクラム 製品の機能をストーリー形式で記載 毎日チームが以下の3つの質問に答える プロダクトオーナーが優先順位を付け、プラ ・昨日やったこと ンニングポーカーで相対見積もり。 ・今日やること 項目の追加はいつでも自由だが実施有無や優 ・困っていること 先順位はPOが決める。 バーンダウンチャート Doneの定義 スプリントタスクの「推定残り時間」を 何をもって「完了」とするかを 更新してグラフにプロットする 定義したリスト スプリント計画会議 プロダクトバックログを再度分析・評価し、 スプリント そのスプリントで開発するプロダクトバック 最大4週間までのタイムボックス ログアイテムを選択する。また選択した項目 各スプリントの長さは同一。この間は外部 をタスクにばらす からの変更を受け入れない 複 数 回タスク ス時間で見 プ積もり リ ン 毎日の繰り返し ト をスプリントバックログ スプリントレビュー ふりかえり 出荷可能な 繰そのスプリント期間中に行う スプリント中の成果である り スプリントの中での改善事項 製品の増分 返タスクのリスト 動作するソフトウェアをデモ を話合い次に繋げる する す
    • ベロシティ #1 #2 #3 #4 #5 完 5 3 8 8 8 了 し 3 3 5 5 3 た ス 1 3 1 1 3 ト ー 1 1 リ ー 9 10 14 15 14 スプリント内で完了した機能の見積りの合計 チームの生産能力の指標となる
    • ベロシティ スケジュールはベロシティから予測可能 スケジュール固定なら生産量を予測可能 自分たちの速度を常に把握する必要
    • 妨害リスト# 妨害リスト1 開発端末の性能が悪いので新しいPCが欲しい2 Jenkins用サーバのメモリ不足3 POがスプリント中に割り込みを入れたがる4 経営者が現場に来て自分の希望をすぐやるようにいつも言う 開発する上で妨害となっていることの一覧 5 会社の規定のドキュメントを必ず用意するように言われる スクラムマスターが解決を試みる… ・・・ 必要に応じて上位組織に解決を依頼する… ・・・
    • http://bit.ly/ndgMJ6 AGILEな組織4. Agileな組織
    • 競争優位は個人と集団の両方の継続的学習から生まれる。学習する組織とは「チームが目的を達成するための能力と気づきの状態を高め続ける組織」
    • メンタルモデル自己マスタリーシステム思考共有ビジョンチーム学習 / ダイアログ
    • メンタルモデル http://bit.ly/nRFmiTマインドセットやパラダイムを含めた「世の中や事象に関する前提」
    • 自己マスタリー 自分がどうあり たいか、何を作 り出したいかに ついて理解しつ つ、現実との差 を認識し、それ に向かって行動 するhttp://bit.ly/q2RSEq
    • システム思考 物事を一連の要 素のつながりと してとらえ、そ のつながりの相 互作用に注目す る。全体最適化 や複雑な問題解 決の手法として 用いるhttp://bit.ly/nZTDdS
    • 共有ビジョン 組織を構成する人のそ れぞれのビジョンを重 ねて、組織として共有 し浸透可能なビジョン を作るプロセスhttp://bit.ly/nvZhqo
    • http://bit.ly/p2KAjx命令説得テスト相談協創
    • “リッツ・カールトンはお客様への心 のこもったおもてなしと快適さを提供す ることをもっとも大切な使命とこころ えています。 私たちは、お客様に心あたたまる、くつ ろいだそして洗練された雰囲気を常にお 楽しみいただくために最高のパーソナ ル・サービスと施設を提供することをお 約束します。”リッツカールトンのクレドより抜粋
    • “リッツ・カールトンではお客様へお約束した サービスを提供する上で、紳士・淑女こそが もっとも大切な資源です。 信頼、誠実、尊敬、高潔、決意を原則とし、 私たちは、個人と会社のためになるよう、持て る才能を育成し、最大限にのばします。 多様性を尊重し、充実した生活を深め、個人 のこころざしを実現し、リッツ・カールトン・ ミスティークを高める‥リッツ・カールトンは、 このような職場環境をはぐくみます。”リッツカールトンの従業員への約束より
    • チーム学習・ダイアログお互いのメンタルモデルに対する理解を深めること。集団での気づきの状態を高める
    • http://bit.ly/qEBgGV組織の多様性は強さ
    • コマンドコントロール 上司の命令に 従っていれば 良い、という価 値観 http://bit.ly/ogVP5F
    • 思い当たる節はないですか?メンバーはやらされ感を持つ上司の指示を遵守したかどうかが評 価の観点に人が育たない。通常は上司の劣化コ ピーに…現状に不満をもつ優秀な人から順に 退職…
    • 人は、有能な間は昇進を続ける。昇進して仕事が変化した結果、無能になると昇進がとまる。そのため、階層社会の上の方には、無能な人であふれ返る。
    • 自己組織化 上司は責任とチームで解消できな い問題の解決を担う 上司は後方支援、ファシリテー ター役になる チームを信じる http://bit.ly/r0Lc8F
    • http://bit.ly/ovenYk自己組織化されたチームで仕事をできるようにするためには、外部からのマイクロマネジメントを止める必要がある。
    • リーダーや管理職の役割の変化 従来の役割や振る舞い  求められる役割や振る舞い ピラミッド組織 ネットワーク型組織 コマンド・コントロール 自律・自発の支援 権威的 民主的 流動性がない 流動性のある 答えをいう 導く 叱る 褒める 否定 肯定 マイクロマネジメント チームの自主性に任せる
    • リーダーシップのモデル(SL理論)http://www.situational.com/ より図を引用
    • 権限の7レベル指示する売り込む相談する同意するアドバイスする問い合わせる移譲する
    • http://bit.ly/pdq0xn全てのアジャイルなプロセスはチームへの権限移譲とチーム内での文化および規範の確立を必要とする
    • 抵抗勢力は かならず発 生するhttp://bit.ly/paHrVi
    • ピラミッド組織ピラミッド組織は、同質なものを受け入れ、異質なものを受け入れられない。 http://bit.ly/qpntdu
    • 実行責任?説明責任?結果責任? …
    • コミットメントとは何か? http://bit.ly/mRCCGH
    • チームの責任チームが「全力で選択したストーリーをDoneにしようとする」ことをコミットメントと呼ぶこれはチームの責任であり、個人の責任ではない http://bit.ly/pKXeZh
    • 見積もりはコミッ トメントではない しかし多くの場合 見積もりがコミットメ ントとして扱われる悪 い習慣があるhttp://bit.ly/pOfAGO
    • 常に 改善する 責任http://bit.ly/mRLszj
    • プラクティスの採用理由をチームや顧客やステークホルダーに説明する責任
    • チームのルールに従う責任 デイリースクラムに出席する責任 完了の定義に従って作業を行う責任 チームメンバーを助ける責任http://bit.ly/qFy4Aq チームメンバーを育てる責任
    • 人材育成の責任 http://bit.ly/qb0Jd4 チームが人を育てる OJTによるマンツーマンな人材育成ではなく、チーム全員 が協力しあってお互いの能力を向上させる
    • ふりかえりによる改善 プロセス改善の場 個人攻撃はしない 個人の評価に結び付けない Tryはほんとうにできている? 追跡重要 同じProblemが毎回でてきていない? 一度に全部手をつけない 出来ることから改善する態度
    • http://bit.ly/nK3hBr××してはいけない?
    • ○○しよう!!
    • 人事評価のやり方 http://bit.ly/r00mRp 個人単位の評価からチーム単位の評価 単一の評価者からチームメンバーを含めた評価へ
    • アンチパターンアジャイルな開発における透明性をそのまま人事評価に利用する。(こなしたタスク数など) http://bit.ly/px6oa1
    • 対応策 http://bit.ly/pUG9Gp 個人の評価はチーム全員から「チームへの貢献度」「プ ロジェクトや顧客への貢献度」を中心に収集する
    • キャリアパス http://bit.ly/mUtDl7名選手名監督にあらず。開発のプロが経営のプロとは限らない。逆もまた然り
    • 採用プロセス
    • よくある問題固定化された企業イメージによって応募者の 属性が偏る面接官個人の判断に左右されるそのため似たタイプの人材が多くなる数回の面接では能力の見極めは困難
    • 失敗するAgile 個人の対立 混乱 規律がない 破壊的な振る舞い 無気力 恐れ 支配 反感・嫌悪 過剰な優越感 無視 立場を決める ぬるま湯 無関心
    • 失敗するAgile マイクロマネジメント ミニウォーターフォール 責任追及、詳細な報告 チームの決定を覆す スクラムマスター=チームの 責任者 ヒロイズム、悪い価値観 コマンドコントロール 専門化、責任の限定 階層組織型の思考 個人保証 コンプライアンス 非難
    • 失敗するAgile スプリントNのプロセスがスプリント1と 同じ ベロシティが分からない 顧客へのデモをしない コードレビューをしない 単調なスタンドアップミーティング チェックインの前にテストがない 悪いメトリクス チームでのリフレクションの欠如 個人でのリフレクションの欠如 コミットメントがない 学習しない、価値の誤った定義 安全地帯の範囲しかやらない
    • 失敗するAgile 変化に対応する時間を持たない アクションのないふりかえり うまくいかないことを繰り返しやる リファクタリングの欠如 結論や決定事項のないスプリントレビュー テストがない やり方が決まっていない うまく機能しないスクラムマスター 弱いプロセス、押し付け型のプロセス 組織からのプレッシャー、プロダクトオーナーが見えない、 権限委譲がない 適応しない、変化の頻度が高すぎる
    • 失敗するAgile 成り行きまかせの結果 タスクの引継ぎ 特定の人だけが顧客と相対する チーム計画がない チームメートのペースにあわせない 顧客のかわりに決めてしまう チェックイン競争 コミュニケーションパスの硬直化 責任をシェアしていない プッシュ型 縄張り争い 分散 政治
    • http://bit.ly/oOISEC5. まとめ
    • • ビジネス環境が変化• ソフトウェアは不確実• 顧客の欲しいものを早期から届ける• Scrumは組織の機能不全を明らかにする• アジャイルな開発を行うには学習する組織 が求められる• コマンドコントロールから自己組織化へ• あなたの責任は何?• 人事評価や採用プロセスも変えるべき