스크럼 스프린트를 계속할 때 번 아웃이 발생할 수 있습니까?

스크럼 스프린트를 계속할 때 번 아웃이 발생할 수 있습니까? [닫은]

---

저는 아주 작은 스타트 업이고 우리는 스크럼 / 애자일 개발주기의 한 형태를 사용하기 시작했습니다.

여러모로 스크럼을 즐깁니다. 우리는 비교적 짧은 스프린트 (2 주)를 가지고 있으며 팀의 진행 상황을 추적하는 번 다운 차트를 좋아합니다. 또한 Feature Board가 마음에 들어 다음에 무엇을해야하는지 항상 알고 있습니다. 보드에서 기능 카드를 가져 와서 완성한 다음 번 다운 더미에 넣으면 기분이 좋습니다.

그러나 우리는 이제 18 번째 스프린트 릴리스주기에 들어가고 있는데 조금 지쳐 가고 있습니다. 내가 직업이나 동료를 좋아하지 않는다는 것이 아니라 단지이 스프린트가 ... 음, 스프린트라는 것 입니다. 처음부터 끝까지 나는 우리의 개발 속도를 유지하기 위해 시간과 경쟁하는 것처럼 말 그대로 느낍니다. 스프린트가 끝나면 하루는 다음 스프린트의 기능 세트와 추정치를 계획하는 데 보낸 다음 다시 출발합니다.

성숙한 Agile / Scrum 개발 프로세스에서 일하는 사람들에게 이것이 정상입니까? 아니면 뭔가 빠졌나요? 일반적으로 스크럼 환경에 할당되지 않은 / 추적되지 않은 작은 작업을 수행하고 머리를 정리할 시간이 있습니까?

---

이것은 비교적 정상적인 현상이며 프로젝트가 장기간 지속될 경우 때때로 팀원들에게 불만이 될 수 있습니다.

여기서 우리가 말하는 핵심은 지속 가능한 속도 입니다. 당신과 당신의 팀이 장기적으로 페이스를 유지할 수 있다면 그것은 훌륭합니다. 당신은 모든 스크럼 팀이 추구하는 초 생산성을 달성 한 것입니다.

또는 하루에 실제로 수행 할 수있는 작업의 양을 과대 평가하는 경우 회고 중에이를 재평가해야 할 수도 있습니다. 스프린트 용량 계획을 수행 할 때 팀이 인식하기로 선택한 하루의 생산 시간을 초점 요인 이라고합니다 .

Henrik Kniberg는 이렇게 말합니다.

내가 새로운 팀에 사용하는 "기본"초점 요소는 일반적으로 70 %입니다. 그 이유는 대부분의 다른 팀이 시간이 지남에 따라 끝나는 곳이기 때문입니다.

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

그러나 당신이 말하는 것처럼 들리는 것은 단순히 스프린트 후 스프린트의 논스톱 모멘텀이지, 반드시 하루의 생산성은 아닙니다. 여기에 우리가 처리하려고 시도한 몇 가지 제안이 있습니다.

• 금요일 아침에 스프린트를 종료합니다. 아침에 스프린트를 검토하고 회고하여 팀이 나머지 시간 동안 다른 작업을 수행하도록하여 머리를 정리하십시오. 월요일에 Sprint 계획을 확인하십시오.
• "실험실 날"이라는 개념을 도입했습니다. 이 날은 팀이 프로젝트에서 제외되고 서로 연구하고 특정 기술 주제에 대한 협업을 통해 자신의 기술 능력을 향상시키는 데 하루를 보냅니다. 대부분의 경우 그들은 특정 프로젝트와 전혀 관련이 없으며 팀 구성원이 가벼운 주제에 대해 생각할 수 있습니다.

---

번 아웃에 관한 Wikipedia에서 : "번 아웃은 주로 오랜 시간, 약간의 다운 타임, 지속적인 동료, 고객 및 우수한 감시로 인해 발생하는 조직의 문제입니다."

번 아웃 정의 옆에 스크럼 아이콘 이미지가있을 수도 있습니다.

번 아웃을 고치기 위해 잠시 다른 사람을 보낼 수 있다고 생각한다면 분명히 생각하지 않은 것입니다. 지친 후 휴가를 가다가 다시 일하러 가라, 와우! 이제 나는 마침내 다시 휴식을 취할 때 까지이 고문의 6 개월 더 준비되어 있습니다. 아니, 무슨 일이 일어나고 있니, 와우! 내 직업이 안좋아. 이제 나는 어리석은 관리자의 미세 관리, 개발 프로세스가 얼마나 적은 비용으로 더 많은 것을 얻을 수있는 또 다른 방법이고 인생이 너무 짧다는 것을 알 수 있습니다 ... 나는 할 일을 찾거나 스트레스가 덜한 일로 직업을 바꿔야합니다. .

IMHO, 짧은 2 주 스크럼은 연속적으로 4-8 개 이하의 소량을 제외하고는 금지되어야합니다. 지속적이지 않고 예외적이거나 중요한 일을위한 도구로 사용하십시오. 상식을 사용하십시오.

---

36 주 동안 열심히 일하다가 지쳐 가고 있습니다. 그것은 스크럼이 아니라 인간의 본성입니다! 스크럼은 더 열심히 일하도록 만드는 것이 아니라 더 일관되고 더 큰 예측 가능성으로 일할 수 있도록 도와줍니다. 나는 종종 사람들이 일반적인 프로젝트 관리의 증상을 애자일 방법론의 증상으로 인식하는 것과 혼동하는 것을 봅니다 (예 : "고객이 요구 사항을 계속 변경합니다. 이는 스크럼의 잘못이 틀림 없습니다!"). 원인을 밝히지 않으면 증상을 치료할 수 없기 때문에 중요한 차이입니다. 개인적으로 스트레스 관리 기술과 같은 번 아웃을 줄이는 방법을 찾고 있습니다. 스트레스가 많은 환경에서 성공하는 방법에 대한 많은 정보가 있습니다.

---

스프린트는 100 야드 대시가 아닙니다. 마라톤에서 1 마일 (무작위), 즉 무한정 지속 할 수있는 페이스입니다.

팀이 각 스프린트가 끝날 때마다 회고전을 실시하고 있습니까? 이것이 팀의 프로세스를 "검사하고 적응"할 수있는 기회입니까? 스크럼 마스터로서 저는 정기적으로 팀에게 팀이 '느낌'과 재미를 느끼는지 평가 해달라고 요청합니다. 그 이유와 이유를 탐색하고 조정 및 대안을 실험합니다.

제 경험상 팀원들은 Sprint 타임 박스가 제한하는 '압력'을 (최대한도까지) 즐깁니다. 핵심은 그 영역에 접근하지만 초과하지 않는 것입니다. 필요에 따라 해당 영역을 보정하는 것이 회고전의 주요 체크 포인트입니다.

"... 몇 가지 사소한 작업을 수행하고 머리를 비우기 위해 할당되지 않은 / 추적되지 않은 스크럼 환경에서의 시간"에 관해서는 팀 약속을 사용 가능한 용량의 x %로 유지합니다 (포인트, 가급적이면 시간을 사용할 수 있음). 필요한 경우; 두 경우 모두 60-70 % 범위의 무언가가 표준 인 것처럼 보임) Sprint 내부의 지속 가능성의 핵심이며 때때로 '무료 코드 데이'는 외부 Sprints에 적합합니다.

---

어떤 개발 프로세스를 사용하든 팀이 소진되면 뭔가 잘못된 것입니다. 사람들이 필요한 휴가 시간을 가지지 않는 것처럼 간단 할 수도 있고 스크럼을 처리하는 방법에 대한 세부 사항 일 수도 있습니다. 모든 사람이 필요한 나머지를 얻는 과정에서 팀은 장기적으로 효과적입니다.

---

제가 현재 작업하고있는 팀은이 문제를 정말 훌륭하게 해결합니다. 세 번의 스프린트 후에 우리는 각 개발자가 자신이 원하는 것을 작업 할 수있는 일주일이 있습니다. 이러한 부수적 인 프로젝트는 비즈니스 가치와 연결되어야하지만이를 완료해야하는 부담은 없습니다. 개발자가 새로운 기술을 탐색 할 수 있도록하는 척도이지만 한 주 동안 더 편안하고 재미있는 작업을 제공합니다.

이것은 확실히 내가 화상을 입지 않도록 도와줍니다.

---

한 가지 해결책은 하루 중 스프린트에 소요되는 시간을 줄이는 것입니다.

나는 근무일이 단 2 시간 30 분의 스프린트로 구성된 일부 사람들을 알고 있으며, 나머지 시간은 지원, 기술 부채 경감, 연구 등 다양한 기타 활동에 초점을 맞추고 있습니다. 그에 따라 개발 속도가 설정되었습니다.

그것은 약간 극단적 인 것처럼 보일지 모르지만, 최근에 만연한 경제 충격이 닥칠 때까지는 수익성있는 회사였습니다.

---

I fully understand what you are saying. For those of you that say "your pace is too fast," I'm not sure I agree that pace is always the problem when people get burned out by this process. Even though keeping track of all your progress IS a good thing, it can also be a stress factor itself (and not keeping track can be as well), not just because your boss/PM will be on you if they see something is not going according to plan, but for yourself. Just having this logged info is something that WILL make most people work just that little bit harder than you normally would ALL THE TIME and I'm not sure putting more time on your time estimates will fix this for everyone. I don't think a motivator (like your burn down chart) is always positive.

Some people won't feel this way, others will. There is not ONE way of work that WILL fit all. Never will be, in my opinion.

Also, if you say that these agile methods and sprints are not becoming more effective/productive, why are you using it at all? Why do you think companies want to use these methods at all? It's not because they are fun....

Effectiveness/productivity always comes at some type of price, in my opinion. It doesn't pop up from nowhere just by using the magic methods (if you get my point).

The only way for you to become more effective (work and pressure-wise) and do less work is make someone else do the work or by automating it.

In my opinion, one should always review ones processes and see what can be automated and spend time on automating your processes instead. Automation comes at the price of doing extra work instead of doing "the real work" but no matter how small the automated task you will always profit in the long run. ALWAYS! If not one day, in two. Not one month, two. Not one year, in two years. You get the idea.

However, I like the idea of having time off to work on personal projects. Most companies will never allow this though. But perhaps you can persuade your employer to get this time to automate your processes and this work could be "outside of sprint control" to allow the time you are talking about to "rest" and get energy back for a new sprint.

Those were just my 2 cents. I get a bit frightened when people say these methods aren't here to make us more effective and work harder. Of course they are! When you have no trace of what you are doing you will rest when your body tells you to. When "everything" you do is traced, you will push yourself. Or I correct myself, most people work this way, some will rest anyway.

---

You are in your 18th sprint!?

Considering 2 weeks per sprint, that means 36 weeks nonstop working on the same project. You also comment that work around 6 hours each day. That sounds like a lot!

I don't know that much about agile methodologies (although we're actually using Scrum in our current project), but there's a principle about your working hours (I mean, the amount of time you spend doing a task) should be 60%~70%. Now, doing numbers again, if your labor day is 8 hours long, and you spend 6 hours working, you're really spending around 75% of your labor time. This could be a little deviation that has finally make you have that feeling.

OTOH, I believe that if your project will take long time to be done, sprints should be larger, not 2 weeks, but not a month. Consider a downward curve on your burnout chart: Start your sprint with a regular task burn, and reduce your activity on the last 2 or 3 days before the sprint ends.

Agile is not a stone with the engraving:"work faster/stronger/better/harder", it's more like a blue sky with white clouds that read:"work nice, beautiful more productive". (a little lol at the end courtesy of daft punk + radiohead).

---

I think you are missing something, but you are not the only one. As Jim Highsmith says: “Velocity is increasingly being used as a productivity measure (not the capacity calibration measure that it was intended to be) that focuses too much attention on the volume of story points delivered.”

I’d guess that is what is happening to your team. I recommend reading this Highsmith’s IMHO seminal post: Velocity is Killing Agility!

---

Sustainable pace is a key tenet of agile. When doing the management (SCRUM) practices along with the engineering (XP) practices, a team can deliver sprint after sprint indefinitely. However, because one can does not mean one should.

It sounds like you need a change against the endless string of sprints you see ahead of you. A number of options can be offered. Every X number of sprints, a team member (or pair) can rotate off of a team. During your rotation, you can support the run team, take a class, focus on a set of spikes, take vacation etc.

If the team has 5 pairs, and you rotate a person off the line, A person could take an off rotation every 10th sprint (if a single person) or every 5th iteration (if a pair). Issues of budget and return on investment for your activities will need to be addressed by your leadership and or business partner. But clearly, having some time to "sharpen the saw" would bring benefit to the team thus the project. Keeping the team fresh and focused is a very good thing. But we must remember, we are getting paid and we need to bring value for the dollars we earn.

참고URL : https://stackoverflow.com/questions/1047112/can-burnout-happen-when-doing-scrum-sprints-continuously