On March 7th I attended some sessions at the Dutch Developer Days 2006. A session I attended was: Dynamics of Microsoft Solution Framework and Visual Studio Team System by Anko Duizer from A-Class.
He told about how he always worked with and liked MSF. He had the opportunity to see how Microsoft uses MSF in real life and told us how much he would like to share this knowledge. The reason why he wanted to talk about MSF and Team System was:

  • Software development is more than just good programming
  • Microsoft Solutions Framework is the result of many years of experience
  • Visual Studio Team System is a great enabler for the use of MSF 

There are a few methodologies that MSF supports: MSF for Agile Software development, MSF for CMMI process improvement.
Team System ofcourse is all about team development. Anko said he learnt a lot from reading a book written by Jim McCarthy called Dynamics of Software Development.
He claimed it opened his eyes and he thinks it still is a book that everybody in software development should read.
A few rules from this book where highlighted, because they are real important. In the book there should be much more. The rules I saw made sense and I think I will pick up this book one of these days. I must say Anko had a software problem, so I think a lot of the demonstation he had planned could not be shown, which in my opinoion was a shame. So I will  write down some rules from which I think they make sense (although some are really obvious):

  • Establish a shared vision (Make everybody aware of what they are doing and why)
  • Create a multi-release technology plan (Make  plans for the future, if you can not get features in this release, you can get them in future ones)
  • Don’t flip the bozo bit (Every department has got one, an employee from who nobody really knows what he is doing, we do'nt want 'bozo's' on our team, or become one)
  • Use feature teams (Use teams for small parts of an application)
  • Use program managers (but it is important to make the distinction that he is servant not master! He supports the team, not tells what to do)
  • Design time at design time
  • Remember the triangle: Features, Resources, Time (You can not get features, if you have not got the time and/or resources)
  • Don’t know what you don’t know (If you can not know something, aknowledge this)
  • Don't go dark (Don't let people get away with doing things without anybody specifically knowing what they do)
  • If you build it, it will ship (Make sure code will built!)
  • Get to a known state and stay there (It is better to release something, than trying to built new features that are late)
  • Don’t trade a bad date for an equally bad date (If you do not make a deadline, don't say we release a week later, but will include the new feature you need!)
  • Triage ruthlessly (Like the war movies, only in software development)

Henry Cordes
My thoughts exactly...

Add comment

  Country flag
  • Comment
  • Preview