Agile 40-hour week [closed]

Question

Have you ever worked on a (full-time) project where using Agile methodologies actually allowed you to accomplish a 40-hour work-week? If so, what were the most valuable agile practices?

Answer 1

Yes, I'm on a 40 hour (actually it's 37.5 hours or so, that's what my contract says) on a project that was run with SCRUM from the beginning. That was about 2 years ago and the first time we implemented SCRUM. It's the project with the least amount of overtime for me personally, and it's also a PC game we're developing. I'm not even in "crunch" mode right now even though we're shipping an open beta on Friday.

We have learned a lot since then about SCRUM and agile. The single most valuable lesson from my point of view is: pod sizes must be reasonable ... we started out with pods with 12-20 members, that didn't work out well at all. A maximum of 10 should not be exceeded. It's too easy to agree on "flaky" and "vague" tasks because otherwise the standup & task planning meetings would take too long. So keep the pod size small and the tasks specific and get the product owner or sign-off's together with those who will work on the task.

Also, with a bi-weekly task planning schedule you have to get every Product Owner to agree on the task list and priorities for the current sprint, and new task requests should be issued before that planning meeting or else it will be ignored for the current sprint. This forced us to improve on inter-pod communication.

Answer 2

Scrum and management that is willing to buy into it.

Fair sprint planning. When you negotiate your own sprint you can choose what your team can accomplish rather than have tasks being handed down from above. Having your sprint commitment locked in (management can't change it mid-sprint) gives freedom from the every changing whims of people.

A well maintained, prioritized backlog that is maintained cooperatively by the product owner and upper management is very useful. It forces them to sit down and think about the features they want, when they want them and the costs involved. They will often say they need a feature now, but when they realized they have to give up something else to get what they want their expectations become more realistic.

Time boxing. if you are running into major problems start removing features from the sprint rather than working extra hours.

You need managerial support for you process without it agile is just a word.

Did I mentioned enlightened management?

Answer 3

Not being able to complete the tasks in a 40 hour week could be due to several things.

I see that this could happen in the early sprints of a Scrum project because the team wasn't sure of:

1. the amount of work they can do in the sprint and might bite off more than they can chew, and
2. their ability to estimate accurately the amount of points to award to blocks of work, or
3. the amount of effort required to perform "a point's worth" of work.

They may also be overly optimistic in what they can accomplish in the time alloted.

After that we get into several of the bad smells of Scrum, specifically:

1. a team isn't allowed to own its own workload, and maybe
2. management overrides decisions on what should be in a sprint

If any of these cut in then you are:

1. doing Scrum in name only, and
2. "up the creek without a paddle."

There's nothing much you can do apart from correct any problems in the first list, but this will only come with experience.

Correcting the two points in the second list will require a major rethink of how the company is strangling, not employing, Scrum best practises.

HTH

regards,

Rob