スクラムスプリントを継続的に実行すると、バーンアウトが発生する可能性がありますか?[閉まっている]


92

私はかなり小さなスタートアップで、私たちはある種のスクラム/アジャイル開発サイクルを使い始めました。

多くの点で私はスクラムを楽しんでいます。スプリントは比較的短い(2週間)ので、バーンダウンチャートでチームの進捗を追跡するのが好きです。フィーチャーボードも気に入っているので、次に何をすればよいかを常に知っています。フィーチャーのカードをボードから取り除き、それを完成させてから、それをバーンダウンパイルに置くのは良い感じです。

しかし、私たちは今、18回目のスプリントリリースサイクルに入っており、少し焦げたように感じ始めています。私が仕事や同僚を好きではないということではありません。これらのスプリントが...まあ、スプリントだというだけです。最初から最後まで、開発スピードを維持するために、文字通り時計と競争しているような気がします。スプリントが終了したら、次のスプリントの機能セットと見積もりを計画するために1日を費やし、その後、再び出発します。

成熟したアジャイル/スクラム開発プロセスで働く人々にとって、これは正常ですか?それとも何か不足していますか?スクラム環境に、割り当てられていない/追跡されていないいくつかのマイナーなことを実行し、頭をクリアする時間は通常ありますか?


方法論よりもスプリントの内容を詳しく見ていきます。純粋な開発(テスト、スパイク、コードレビューなし)は、しばらくすると人々を殺す可能性があります。また、スクラムマスターは、不当なロードマップ、チームからの時間の見積もりなどからチームを守る必要があります。可用性の計算中に、予定外の会議、トイレの休憩、気晴らしなどを考慮して、コミットされていない時間を10〜20%考慮してください。 。次に、式典中にあらゆるものを計画します。最終的にはすべてがバランスします。
Sinaesthetic 2014年

12
これが建設的でない場合、Stackexchangeエコシステムのどこに配置するのが最適ですか?
Ryan Schultz 14


21
53票の質問。回答は49で受け入れられました。建設的ではないためクローズされました。明らかに、一部の独善的な「モデレーター」は薬の服用をやめています。再び。
SzG 2014

同意します。質問はキャパシティプランニングの要件に関するものであり、選択された回答も同様です
charo

回答:


68

これは比較的正常な状態であり、プロジェクトが長期間続く場合、チームメンバーの不満になることがあります。

ここで私たちが話していることの鍵は、持続可能なペースです。あなたとあなたのチームが長期にわたってあなたのペースを維持することができれば、それは素晴らしいことです-あなたはすべてのスクラムチームが目指している超生産性を達成しています。

または、1日に実際に実行できる作業量を過大評価していることがわかった場合は、振り返りの際に再評価する必要があります。チームがスプリントのキャパシティプランニングを行うときにチームが認識することを選択した1日の生産的な時間の量は、フォーカスファクターと呼ばれます。

Henrik Knibergはこう言っています:

私が新しいチームに使用する「デフォルト」のフォーカスファクターは通常70%です。これは、他のチームのほとんどが時間の経過とともに終わっているためです。

http://www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf

ただし、あなたが話しているように聞こえるのは、スプリント後のスプリントのノンストップの勢いであり、必ずしも1日の生産性ではありません。これが私たちがそれに対処しようとしたことのいくつかの提案です:

  • 金曜日の朝にスプリントを終了します。午前中にスプリントのレビューと振り返りを行い、チームは1日の残りの部分で他の作業を行って頭をきれいにします。月曜日にスプリントプランニングを受け取ります。
  • 「ラボデイ」の概念を紹介しました。チームがプロジェクトから取り除かれるこれらの日は丸一日であり、彼らは1日を費やして、お互いの研究と特定の技術トピックに関するコラボレーションを通じて、自分の技術スキルの向上に取り組んでいます。ほとんどの場合、彼らは特定のプロジェクトとはまったく関係がなく、チームメンバーは軽いトピックについて考えることができます。

3
「フォーカスファクターは、本から引き離したいものの1つです。本を書いた直後に使用を停止しました...」— twitter.com/henrikkniberg/status/207853426967715841
MPV

24

ウィキペディアのバーンアウトに関する記事:「バーンアウトは、主に長時間、わずかなダウンタイム、そして継続的な同僚、顧客、優れた監視によって引き起こされる組織的な問題です」

また、バーンアウトの定義の横にスクラムのアイコン画像がある場合もあります。

バーンアウトを修正するための簡単な迂回のために誰かを別の誰かに送ることができると思うなら、明らかにそれを熟考していません。燃え尽きて休暇を取り、仕事に戻って考えてみてください。さて、私はリフレッシュして、最後に再び休憩を取るまで、この拷問のさらに6か月の準備ができています。いいえ、何が起こるのですか。私の仕事は最悪です。今、私は本当に私の愚かなマネージャーのマイクロ管理、開発プロセスが私のためにもっと多くのことをより少なくするためのもう一つの方法であり、人生はこれには短すぎる...本当に私は見ることができます... 。

私見、2週間という短いスクラムは、少量の場合を除いて、4〜8行を超えないように禁止する必要があります。継続的ではなく、例外的または重要な事柄のツールとして使用してください。常識を使用してください。


3
これはばかげたFUDです。スクラムは確かに人々が燃え尽きるようにすることではなく、短いスプリントは週に80回働くことではありません。
Pascal Thivent、2010年

7
これはまさにその通りです。スクラム愛好家がそれがどのように「想定」されているかというおとぎ話でそれを守る方法は面白いですが、ほとんどの開発者はOPが語ったことだけを体験します。
kirk.burleson 14

2
私は過去数年にわたってこれに気づき、ここで述べられていることに完全に同意します。しばらくの間お尻になって貯蓄を使うことになるかもしれないが、私はこのように仕事から抜け出すのに必死です。恐ろしい「毎朝」は言うまでもありません。私は目を覚まして、私がどこか他の場所にいたらいいのにと願い、それを実現するために取り組んでいます。
スキルM2

5
私にとって、スクラムは燃え尽き症候群を引き起こします。勤務時間と生産性は変わりませんが、気分は変わりません。スクラムがなかったので、私は仕事をやり遂げて、それをうまくやっていました。スクラムプロセスを追加したとき、私は同じ作業を同じペースで実行しましたが、締め切りと会議に絶えず焦っていたので、もはや楽しんでいませんでした。あなたの仕事を楽しんでいないことは、やめるための道です。また、バーンダウンチャートは、スプリントがうまくいかないときに驚くべき動機付けになる可能性があります。
orfdorf

3
私が見た会社の間には、さまざまな違いがあると言いたいのですが、スクラムとは、最も純粋な組織の場合、成果物を修正し、予定通りに納品し、それを確実にするために多くの計画を立てることを意味しますスクラムとは、最も純粋でない組織の場合、2週間ごとに配信することが期待され、要件が常に流動的であり、毎朝マイクロ管理会議が開かれることを意味します。後者のバージョンのスクラムは、前者よりも頻繁に発生し、上記のバーンアウトをはるかに早く引き起こします
Edwin Buck

14

36週間のハードワークの後、あなたはすり減っています。それはスクラムではなく、人間の性質です!スクラムは、仕事をより効率的にするためのものではなく、より一貫性のある、より高い予測可能性で作業するのに役立ちます。私は、通常のプロジェクト管理の症状とアジャイル方法論の症状を混同している人々をよく見かけます(つまり、「顧客は要件を変更し続けている-それはスクラムのせいだろう!」)。原因を特定しないと症状を治療できないため、これは重要な違いです。個人的には、ストレスマネジメントの手法など、燃え尽き症候群を減らす方法を探しています。ストレスの多い環境で成功する方法については、たくさんの情報があります。


11

私が現在取り組んでいるチームは、この問題を本当にうまく解決しています。3回のスプリントの後、1週間があり、各開発者は自分の望むものに取り組みます。これらのサイドプロジェクトはビジネス価値にリンクする必要がありますが、それを成し遂げる必要はありません。これは、開発者が新しいテクノロジーを探索できるようにするための手段ですが、1週間のリラックスした楽しい作業も提供します。

これは確かに私が燃え尽きないようにするのに役立ちます。


11

スプリントは100ヤードのダッシュではありません。マラソンでは1マイル(ランダム)です。つまり、無期限に維持できるペースです。

あなたのチームは各スプリントの終わりに遡及を行っていますか?これは、チームのプロセスを「検査および適応」する機会ですか?スクラムマスターとして、私は定期的にチームにエンティティとしてのチームがどのように「感じる」か、そして彼らが楽しんでいるかどうかを評価するように依頼します。理由と理由を探り、調整と代替案を試します。

私の経験では、チームメンバーはSprintタイムボックスが制約する「プレッシャー」を(限界まで)楽しんでいます。重要なのは、そのゾーンに近づくが、それを超えないことです。必要に応じて、そのゾーンの調整は、過去を振り返る上での主要なチェックポイントです。

「...割り当てられていない/追跡されていないスクラム環境で、いくつかのマイナーなことを実行し、頭をクリアする時間」については、チームのコミットメントを使用可能な容量のx%に維持します(ポイント、できれば、時間を使用することもできます)必要に応じて;どちらの場合でも、60-70%の範囲の何かが標準であると思われる)がスプリント内の持続可能性の鍵であり、時折「フリーコードデー」がスプリントの外でうまく機能します。


20
たぶん彼らはそれをスプリントと呼んではいけません、え?彼らはそれをラップと呼ぶべきです。
Alex Baranosky、2009

4
チーム外の人々が干渉しないようにするために、これをスプリントと呼んでいると思います。スプリントは、邪魔してはいけないような音です。
ポールテヴィス

ラップはゴールを意味せず、その1つだけsprintです。スプリントは、最終的には「ゴールまでのラン」を定義します。用語は正しいIMHO
Jakub

2
「反復」を使用するだけです。私たちのほとんどにとって、これらの用語はすでに同義語ですが、「反復」には、「完全に枯渇するまで実行」という暗示全体が欠けています。
mindcrime 2017

10

どのような開発プロセスを使用していても、チームが燃え尽きてしまった場合は、何か問題があります。必要な休暇を取っていない人と同じくらい簡単かもしれませんし、スクラムの扱い方の詳細かもしれません。全員が途中で必要な残りを手に入れるので、チームは長期にわたって効果的です。


8

1つの解決策は、スプリントに費やされる1日の時間数を減らすことです。

就業日がわずか2時間半のスプリントで構成され、残りの日は、サポート、技術的負債の軽減、研究など、その他のさまざまな活動に焦点を合わせた人々がいることを知っています。開発速度はそれに応じて設定されました。

それは少し極端に思えるかもしれませんが、私が誤解しない限り、最近の広範囲にわたる経済的ショックが打たれるまで、それは利益のある会社でした。


1
現在、1日6時間のスプリントに設定されていると思います。たぶんそれは少し多すぎます。
mmcdole 2009年

それは多くのように聞こえないかもしれませんが、私はそれが歩くためにかなりタイトなロープであることがわかります。日中に問題が発生しなければ問題なく維持できますが、障害が発生すると、その日の速度が失われます。
mmcdole 2009年

私のチームは、1日に5つの生産的な時間に基づいて計画を立てています。TBHは、4.5時間の方が適していると思います。だから私は、1日6時間の生産は、と思いますですたくさん。
ジョンレイナー、

6

あなたは18回目のスプリントにいます!?

スプリントごとに2週間を考えると、同じプロジェクトで36週間ノンストップで作業することになります。また、毎日6時間程度働くとコメントしています。それはたくさんのように聞こえます!

アジャイル方法論についてはあまり知りませんが(現在のプロジェクトでは実際にスクラムを使用しています)、勤務時間(つまり、タスクの実行に費やす時間)に関する原則があります60% 〜70%。労働時間が8時間で6時間働いている場合、実際に労働時間の約75%を費やしています。これは少しの逸脱である可能性があり、最終的にはその感覚を感じさせます。

OTOH、あなたのプロジェクトが完了するまでに長い時間がかかる場合、スプリントは2週間ではなく1か月ではなく、もっと大きくすべきだと思います。バーンアウトチャートの下降曲線について考えてみましょう。定期的なタスクのバーンからスプリントを開始し、スプリントが終了する前の2日間または3日間のアクティビティを減らします。

アジャイルは、「より速く/より強く/より良く/より硬く」という彫刻が施された石ではありません。それは、「うまく機能し、より美しく、より生産的」と書かれた白い雲のある青い空のようなものです。(最後にdaft punk + radioheadの好意で少し笑)。


6

あなたの言っていることがよくわかります。「あなたのペースが速すぎる」と言うあなたのために、人々がこのプロセスによって燃え尽きるとき、ペースが常に問題であることに私は同意しません。すべての進捗状況を追跡することは良いことですが、上司やPMが何かがうまくいかない場合にあなたのところにいるだけでなく、それ自体がストレス要因になることもあります(追跡しないことも同様です)。計画に従って、しかしあなた自身のために。このログに記録された情報を持つだけで、ほとんどの人はいつもよりも少しだけ作業が困難になります。時間の見積もりにもっと時間をかけることで、すべての人がこれを修正できるかどうかはわかりません。私は(あなたのバーンダウンチャートのような)動機が常にポジティブであるとは思いません。

このように感じない人もいれば、そう感じる人もいます。すべてに適合する作業方法は1つではありません。私の意見では、決してならないでしょう。

また、これらのアジャイル手法とスプリントがより効果的/生産的にならないと言うなら、なぜそれをまったく使用しないのですか?企業がこれらの方法をまったく使用したいと思うのはなぜですか?彼らが楽しいからではありません...

私の意見では、有効性/生産性は常にある種の価格でもたらされます。魔法の方法を使用しただけでは、どこからもポップアップしません(私のポイントを取得した場合)。

あなたがより効果的になり(仕事と圧力に関して)、仕事を減らす唯一の方法は、誰かに仕事をさせるか、それを自動化することです。

私の意見では、常に自分のプロセスを確認し、自動化できるものを確認し、代わりにプロセスの自動化に時間を費やす必要があります。自動化は、「本当の仕事」をする代わりに余分な仕事をするという代償を払うことになりますが、長期的に見ると、自動化されたタスクがどれほど小さくても常に利益を得るでしょう。常に!1日でない場合は2日です。1か月ではなく2か月。1年ではなく、2年で。あなたはアイデアを得ます。

しかし、私は個人的なプロジェクトに取り組むために休暇を取るという考えが好きです。ほとんどの企業はこれを決して許可しません。しかし、おそらくこの時間をプロセスの自動化に使用するように雇用主を説得することができ、この作業は「スプリント制御の外」であり、話している時間を「休憩」して新しいスプリントのためにエネルギーを取り戻すことができます。

それらはちょうど私の2セントでした。これらの方法は、私たちをより効果的にし、一生懸命働かせるためにここにないと人々が言うとき、私は少し怖くなります。もちろんそうです!あなたが何をしているかの痕跡がないとき、あなたの体はあなたに指示したときにあなたは休むでしょう。あなたがする「すべて」をたどると、あなたは自分をプッシュします。または私は自分自身を修正します。ほとんどの人がこのように働きます。一部はとにかく休むでしょう。


2

持続可能なペースはアジャイルの重要な信条です。管理(SCRUM)プラクティスとエンジニアリング(XP)プラクティスを一緒に行うと、チームはスプリントを無期限に実行できます。ただし、できるからといって、そうする必要があるわけではありません。

あなたはあなたがあなたの前に見えるスプリントの無限のストリングに対して変更を必要とするように思えます。いくつかのオプションを提供できます。X個のスプリントごとに、チームメンバー(またはペア)はチームからローテーションできます。ローテーション中に、実行チームをサポートし、クラスを受講し、一連のスパイクに集中し、休暇を取ることができます。

チームに5つのペアがあり、ラインから人をローテーションする場合、人は10回のスプリント(1人の場合)または5回の反復ごと(ペアの場合)にオフローテーションを行うことができます。あなたの活動のための予算と投資収益率の問題は、あなたのリーダーシップやビジネスパートナーによって対処される必要があります。しかし、明らかに、「のこぎりを研ぐ」ための時間があれば、チーム、つまりプロジェクトに利益をもたらすでしょう。チームを新鮮で集中的に保つことは非常に良いことです。しかし、私たちは覚えておかなければなりません。私たちは給料を受け取っており、稼いだドルに価値をもたらす必要があります。


3
たぶん彼らはそれをスプリントと呼んではいけません、え?彼らはそれをラップと呼ぶべきです。
Alex Baranosky、2009

2

何かが足りないと思いますが、あなただけではありません。ジム・ハイスミス氏は次のように述べています。「ベロシティは、提供されるストーリーポイントの量に過度に注意を向ける生産性測定(意図されたキャパシティキャリブレーション測定ではない)としてますます使用されています。」

それがあなたのチームに起こっていることだと思います。私はこのHighsmithのIMHOの重要な記事を読むことをお勧めします:Velocity is Killing Agility!

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.