If I would have written an article two years ago (wait a minute, I did!) it would have been a cold enumeration of rules and my outsider opinion about it.
If I would have written an article about Scrum two months ago, it would have probably been an insider rant, explaining how just following the rules of Scrum leads to blind bureaucracy and to a lot of waste of time.
Well, now I am writing about Scrum as I understood it from a personal viewpoint, because I've had this epiphany: Scrum (or any other development process) is a personal process first and foremost. To use a metaphor, so that I can move it out of the way and talk shop, it is like driving a car on a straight road. You are the engine (strong and reliable, hopefully), the road is the development process and your speed is your development speed. It is so easy to do everything fast and furious, it's a straight road after all, but what if there is a fog? Then you would have to slow down, for danger that you wouldn't see a sudden obstacle.
To get real now, the fog is the lack of foreknowledge about what you are going to do. And I don't mean project vision, or strategic planning, I am talking about your personal schedule, of how well you know what you are going to do. Scrum is trying to achieve this by enforcing a time table (the sprints) and a schedule (the sprint planning) and a recurrent update mechanism (the daily meetings), but it is only the beginning. If you plan your sprint superficially, it is like adding fog to the road in front of you. If you (and I mean YOU!) do not update your schedule as you go, including documentation, estimated time, time spent and all useful metrics, you add fog to the road behind you. If you are surrounded by uncertainty, you cannot plan anything. You don't know where you are, where you are going and how fast you are going to get there.
After 6 months of badly implemented Scrum, I've experimented with using a simple text file to mark when I start a job and when I finish it and any breaks in between, updating the actual work time and estimated time in the Scrum tool. We are using a clearly defined specification document for each feature, including requirements, acceptance tests, implementation details, code reviews, definition of done, test plan, updated as we go. I've discovered that all this huge amount of information, instead of slowing me down, lifts the fog and allows me to push the pedal to the metal and go as fast as I can. I know when I am doing something, why, and who is doing everything else and why. At the end of the day I don't have to rack my brains to remember what I did, I just cut and paste the task names and times from my text file to an email and the Scrum master just goes over the list and we are free to talk about what really mattered in those tasks: new issues, dependencies, implementation details. The result is visibility of what we are doing and not less important, I get to go home early.
Of course, I am writing this enthusiastic post after a single day of well done and 6 months of poorly done, but I have a great feeling about this, something akin to fog being lifted from my eyes.