This week's book giveaway is in the OCPJP forum. We're giving away four copies of OCA/OCP Java SE 7 Programmer I & II Study Guide and have Kathy Sierra & Bert Bates on-line! See this thread for details.
First, it really requires a mind shift of everyone involved. If management, for example, isn't willing to trust the team, to foster crossfunctional collaboration and self-organization (including close collaboration with the customer), and to invest in coaching and training for everyone to learn about their new roles and required skills, you'll have a hard time trying to do Scrum. It will more likely result in what is often called "Scrum-but".
Second, Scrum doesn't really tell you how to develop software. All it gives you is a framework that makes problems very transparent very quickly, and ask the team to experiment with solutions. For a team that isn't used to Agile way of working, good solutions that are in line with the values and principles of Scrum might be far from obvious. For such a team, it might be more effective to use a process as starting point that gives more guidance on the technical aspects of software development, like for example Extreme Programming.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Joined: Sep 16, 2002
Thanks Ilja for the detailed explanation. But ain't those two 'cons' not enough for people not to adapt to it? Why is this Scrum fever everywhere then?
Joined: Jul 11, 2001
Well, I can see several reasons:
* good marketing by the Scrum Alliance
* Scrum *looks* deceptively simple. You can learn all about Scrum in two days. But that doesn't mean that it's simple to understand and apply. That takes a lot of experience.
* If you really take it seriously and take the time and investement to do it right, it can give you a huge competitive advantage. It's also a style of working that a lot of people really enjoy.
having self orgnize team is not just about trust, and it also depend on the skill set and experience of the developers in the team. instead of fully adopt scrum or extreme programing or rup, my experience is to take some of the concept and apply them to your project in orgnization.
for example, from scrum, collobration of key people cross function early on and a demo at end of each iteration are very useful.
from extreme programing, the continue building and intergration and automation of functional test, and team ownership of code base are very useful. from rup, the concept visual modelling and design, risk analysis, tackle of high risk and high value item at the early phase of the release, and the 4 concrete phases (inception, elaboration, construction, and transition) are very useful.
one of the most critical point to build software fast, cheap, and good is to have a lot of automated unit test, intergrated test, and system test. this doesn't mean that you will take out the qa process. it will help provide a decent baseline for your development release.