It has been about a month now since this happened and I am only now getting to it which is a shame. We were fortunate enough to have Randy Miller come down to our Intel Aloha campus in the Hillsboro, OR area and talk about Agile development principles, MSF, and Visual Studio Team System. We had about 50 developers from different software development groups at Intel attend. I worked with a fellow Inteler on putting it together and being my first time doing something like that I wanted it to go off well for all involved. I was pleased with how it turned out. The feedback I got back was also overwhelmingly positive. The little “negative” feedback I got also turned out good because it gave me a chance to ask why and understand expectations and have a discussion about the various concepts that Randy presented on.
I won’t attempt to document all that Randy talked on – I just wanted to hit the points that stuck out to me
Cadence/Flow
Randy showed how the reports in Team System are set up for you to understand the Flow or Cadence that your project has (Remaining Work report and Project Velocity are two examples of TFS reports that portray this). Sam Guckenheimer speaks to the importance of Flow in his book “Software Engineering with Microsoft Visual Studio Team System”. As you reach the sweet spot on your agile projects with iterations, automated builds, etc… you get into a flow and establish a cadence. This starts to work for you – the whole momentum concept of objects in motion tend to stay in motion.
I found myself feeling that way with the project that I am currently working on. Obviously there is variance in our project’s progress, but we are in the habit of producing value regularly at a fairly steady rate. I find that regular cadence helps me to stay focused and lack of focus is one of the natural variances that comes into play in any software project. High Quality is implied in Flow since having to go back and rework stuff that was previously believed completed disrupts the Flow.
Processes can also be major Flow disrupters. While varying degrees of processes are required depending on the type of business you develop software for - the goal should be to make them as transparent as possible – as much of the process as possible should be automated and happen as granularly as possible.
That is why I believe in Pair Programming – big code reviews don’t work – they just don’t. Does that mean though that I want developers to just be able to check in changes without another pair of eyes looking at them – no – so Pair Programming among other things helps in this process – you are code reviewing all the time. It also forces you to overcome those attitude/personality conflicts because you have to deal with them daily. I think most of us have had the experience of being in a review meeting where someone takes the stand that it is my way or the highway right at the end of a long and arduous release – you sit there thinking – “is this for real! Why didn’t this get brought up weeks ago?” At that point consider your Flow gone (and perhaps your hair too!).
Well – that is long enough for today – tomorrow I’ll try to cover my thoughts on Personas which was another topic that Randy covered.
