Software development can make so much fun! One of the big idea behind scrum, is to enforce a face to face communication in the team. To get the power of the community, through the whole development lifecycle. For me it was one of the main arguments to start working with scrum. A really good team works much more efficient, produces much better code and of course software quality too. And by the way, it does make much more fun to work this way.
However, i find that the team should not be hierarchically organized. Every developer in the team should be equal (not the way our old Orwell meant it: "ALL ANIMALS ARE EQUAL, BUT SOME ANIMALS ARE MORE EQUAL THAN OTHERS." ;) we all know how the story ended up!). Of course there are seniors and more advanced members, but they will be forming the team, and other team members will respect them without any hierarchy.
The power of scrum is that it enforces the individual, and at the same time reinforces teams. It gives one the feeling of freedom. The developer is not a resource any more that can be assigned to one or another team, for 10% of a week and just do some job for the manager that got him from his boss. His performance can not even measured. The smallest unit is the TEAM! At least concerning controlling!
For the old fashioned manager, who manages his resources and got his weekly reports about the progress on this and that project, this seems to be a pretty inconvenient situation, if suddenly, that particular excel rubric can not be rewritten, or moved to another project, or even can not be evaluated/measured on its own.
Who cares, which developer had made it. It was the team! And may be one or another developer is not so good, but we all have our strengths and weaknesses. And you can be sure, if a team keeps somebody, than he/she's worth to be kept.
However, scrum does not mean the loss of control. If you look at it, it gives much more control for the management, since it delivers real value! It's not about working hours spent on this or that, it's just about functionality, you've got integrated into the project. It's about transparency, you got by the product backlog and by the story board. It's about risk mitigation you can get by the short iterations. The main problem with scrum is that it is different! It is not the old school, and chaps of the old school need some time to change (could ask Galileo he knows it well! ). I see pretty the same situation with scrum. You can prove it by doing. You should just start dong it! But the old school won't start with it, since we all know: the Earth is the center of the Universe.
Another big advantage of scrum comes with effort estimation. Planning is a hard stuff. As the old good Churchill said once: "It is difficult to make prediction, especially about the future".
So, what to do (the ultimate recipe of planning):
1) Get an experienced developer, and let him/her be a leader or manager. You can be sure, that with the time she got away from the code.
2) Let him the one who is authorized to make effort estimation (give him a star ;) )
3) Discuss the requirements and wait for the magic number: 42
4) Ok. if you have a good project manager she would still multiply it by two! Just to be sure ;)
It sound so cool, since we know, the chap who made the prediction was a really good software developer... but forget it. It fails in most of the cases completely. The chap with the star will communicate less and less with the poor developers! He is better now. He is authorized! The effort estimation is his responsibility, so he doesn't need to consult with the developers! He might do it, but it won't be enough, and it gonna be even less and less. I'm pretty sure about it (unfortunately).
But wait, just call your team together for a game. Just meet a room for a day and play poker with them! The development team has the most adequate information to make a good effort estimation. If they are not influenced by some lead or boss or manager or whatsoever, and are supported by a qualified scrum master and product owner, the result of the planning will be impressive!
In my team we have made many mistakes, and did not apply the process the way scrum suggests, but still we achieved much better results on effort estimation by introducing user stories, and start using story points.
But again. You can call it ideal day, or story point, or potato, it doesn't matter what the unit of estimation is. The real matter is, how to get to the result!
"The plan is nothing but planning is everything"
No comments:
Post a Comment