[IpV8]

I think you're on to something here. I certainly value a lot of freedom and need the challenge of solving big problems myself. I get demoralized when some scrum master is breaking everything down into tiny tickets and only doling me pre-thought out bits of implementation work.

Lets assume for a second that you're right and focusing on sprint targets is bad. How else can we solve the issues that Scrum solves well? Management knowing what their team is working on, Management being able to prioritize features, Not losing developers to time sinks only to surface weeks later without any significant value add. etc. etc.

I've found some success with setting 2-week goals as large items. Give a good engineer clear requirements for an entire business goal that will take roughly 2 weeks to solve, and then give them huge liberties of how to implement. Though do the same for bad engineers and you'll get comically disastrous results...

[marcosdumay]

> Though do the same for bad engineers and you'll get comically disastrous results...

Is there any way to manage bad engineers that does not end in comically disastrous results?

[IpV8]

Hah, too true.

I find giving them smaller, well defined tasks and checking in frequently helps erk some productivity out of them. Also having lots of check-ins and pair-debugging sessions opens the door for a lot of mentoring opportunities. If their still bad, send 'em to tech support or QA! (only kind-of kidding)