Friday, April 28, 2006 11:43 AM
youngjoo
How can Visual Studio, Office or Windows teams adopt Agile?
Scoble ponders about how Agile methodologies such as Scrum can be applied to Visual Studio, Office or Windows teams in his Another test of "is Microsoft listening" post. Scrum is everywhere now. Even Scoble talks about it.
I do firmly believe that Agile methodologies can be adopted by ANY development team as long as people understand what benefits Agile brings and plan carefully. Scoble mentions the deployment issue as one of the reasons why Office or Windows teams won't benefit from Scrum. Although he has a point, that isn't true. It's a very common misunderstanding people have about Agile methodologies. Sure, "ship every two weeks" sounds very attractive. And it's one of the reasons why people are so excited about Agile methodologies. However, it's not about ship every x weeks. It's about building shippable software every x weeks. People often do not realize that Agile teams have iteration planning and separate release planning. Iteration planning is about committing to what will be done during a particular iteration. Release planning is taking what's been done in one or more iterations and actually shipping.
Why focus on creating working software (shippable software) at the end of each iteration when you are not sure whether it will actually ship or not? A couple of reasons.
Since team members have to make sure that whatever stories (features) they commit to need to be fully spec'd, implemented and tested, they do not sign up for unrealistic goals which is very typical of waterfall teams. Instead, they use real data collected from previous iterations to choose what they are going to work on. This is Yesterday's Weather concept which tells you that the best way to predict what you can do during next iteration is to look at what you've done in previous iteration. No more, no less.
Another reason for striving to create working software at the end of each iteration is to encourage highest level of collaboration between team members. Since the length of each iteration is very short, if you are not talking to each other and help each other from day 1 till the end of the iteration, you won't be able to finish your committed features. No more dev doing their work while QA is waiting.
Being able to actually ship at the end of each iteration is probably added bonus some extremely mature teams can enjoy. But what Agile development want you to do is to set realistic goal and work together to create working software. Deployment is a separate story.
By the way, please don't think that you actually have to have your iteration set as 4 weeks long (what Scrum people recommends). It's completely up to you as long as you don't go too low (less than 1 week) or too long (more than 4 weeks).