I, too, like getting stuff done. The way I get the most stuff done is meeting with the rest of my team every two weeks to: - Look at what stuff needs to be do

I, too, like getting stuff done. The way I get the most stuff done is meeting with the rest of my team every two weeks to: - Look at what stuff needs to be done next, based on the stuff we want to do, stuff that other people want us to do, and stuff we don't want to do but need to do anyway - Figure out between us how much work is involved in doing that stuff - Review how much stuff we did in the last two weeks to see if we did what we expected to - Use that information to agree between us how much of that stuff we think we can do in the next two weeks - Make sure that we have all of the information and prerequisites to do that stuff - Based on all that, to estimate how long all the stuff will take, pick which stuff that we expect to be able to reasonably do, and prioritise what's most important Then every day, we check in for 10 minutes to see if there are any problems doing the stuff, if unexpected stuff needs to be done urgently, or if we want to show the stuff to anyone else. Once every two weeks, we show everyone else what stuff we did and answer any questions about it; once every couple of months, we all sit down together with other people, look at our list of stuff that we want to do over the next six months, make sure we all agree on what the plans are over that timeframe, and make any adjustments we think we need to. Someone is in charge of making sure that all those things happen, that everyone has what they need to do their stuff, and that everyone outside the team knows what stuff is being done. This is just Scrum using words that don't piss engineers off to the same extent. Scrum is nothing particularly special or magic – it just provides a basic set of tools and terms to describe a bunch of interactions and help keep them on track, and they are for the most part pretty reasonably tools. And here's the reason this is not a good article – it makes the same basic mistake as many others do and assumes that a development framework is somehow supposed to magically fix your broken team. A bad manager is a bad manager, regardless of whether you call them a "scrum master" or something else.