When I was young and didn’t have any profession yet, I was interested in various project-management methodologies and methods. I wanted to be a great project manager! I still remember those thick, bright-red Microsoft Solutions Framework books. Or the gigantic IBM Rational Unified Process website with a hundred different document templates. Or its simplified and open version, OpenUP. Back then it seemed like — this is happiness: do everything according to the templates and any project will succeed.
Then I was lucky enough to work as a project manager for a whole year and try it all in practice. We stepped on every rake there was: we made half the team out of friends, underestimated the scope, and took on unfamiliar technologies. All of that turned into missed deadlines, 80-hour workweeks (6 days at 12 hours, and 8 hours on Sunday — well, come on, you do need to rest, it’s a day off!), and a product with a pile of bugs and nonworking features. Since then I’ve sworn off being a manager. Better to do something with your hands, like programmers, for example.
Many years passed, and I got a little smarter. There’s no avoiding project management. Even experienced programmers, without the right method, won’t be able to bring a project to success.
The other day I finished an interesting book by Jeff Sutherland, “Scrum: The Art of Doing Twice the Work in Half the Time” (375 UAH on balka).
The main idea of the book is very simple: “Who are you trying to fool when you plan more than one week ahead”? Raise your hands, whose week’s plan gets done 100%? A forest of hands. The second idea is that the most important thing should be done first. The third idea is to regularly analyze the workflow, identify weak spots and obstacles, and remove them.
You’d think: obvious stuff, but it’s nice that all of it is described in one book.
Among the interesting bits:
— Scrum guarantees that the project will be completed within a fixed timeframe and a fixed budget;
— the author reports a 4x increase in the productivity of Scrum teams as work on the project progresses.
Among the uninteresting bits: the author regularly gets sidetracked into stories about how, as a pilot in Vietnam, he shot down Soviet fighters. You can safely skip these passages; they add no value to the Scrum method.
If we turn to the metaphor “Do you want the checkers, or do you want to go?”, then all those thick MSF and RUP methods are the “checkers,” and Scrum is the “go.” You can use Scrum not only for software projects but for any others too, for example, renovating a house, a rocket engine, a term project, a thesis.
I recommend the book.