epoch: 1268858580
Lets call it the ham-or-pig-paradox. What was first? If, in Scrum, I promise to do an innovation until the end of the sprint and I write that innovation down to the card for the task board, isn’t it that I already made the innovation I just commit to do during the sprint? And if not, don’t I make a promise I cannot commit to keep? Commitements have to be based on experience but innovations can only be based on hope.
Scrum is good to do tasks you ever did again and again. Today that web shop tomorrow this. It is Fordism in software development. You can clock the work of one or several teams and group them due to their velocity. But if you try to do something you, or the team, or anyone never ever did you will probably fail. Velocity is no longer a valid measure. You are in the all-or-nothing-territory. And if you do not have the courage to expect literally nothing you will never get anything new.
Saying this I should add that I have good experience with Scrum. I did it for years in a number of projects and I am a certified scrummaster. Eventually I quitted to play that part and now I work as a developer again. Simply, because I want to do something creative.
Scrum, probably, was invented to controll a process. Nowadays it is mostly used to control people. But if you try to control people they will never be creative. Most of Scrum are best practices each experienced developer will already have adopted. It is, sorry, a framework of platitudes. You have to look back and check what you’ve done to see if you’re on track? Oh, really!
Don’t believe any of the usual promises of some moron Scrum coaches. You will not have significant more output than before. You will not have lesser bugs. Not because you do Scrum. Maybe because you do good engineering but you do not need a project management religion to do that, you just need good engineers. Often Scrum destroys good engineering because some CXO has believed in the 500%-more-output-nonsense and swings the whip and the good engineers either quit their job or quit good engineering. Anyway, in that situation the agile zoo has already be turned into a pig farm and it smells badly at each corner.
There is only one real benefit possible with Scrum: It enables a team of developers to bound their customers. They are bound into time boxes and payed with transparency. That’s it. Still they will never get anything innovative. They will probably get their product or the 80% they need but nothing more. Why? Because they do not trust. They get what they deserve.
The only way to get something creative and new out of a team of (good) software developers - or talented people in general - is to trust. They already know how to do it and they know what is possible beyond everything ever done. Innovation comes out of the temple not the galley. If you trust, you end up with something you could never imagine to work. If you don’t - you’re lost.
Powered by Tumblr; designed by Adam Lloyd and Ingo Schramm.
