An Good Agile Team is a Disciplined Team

Since last year I have been at two different development shops that were in various stages of adopting Scrum. At the first I was the development manager and initial Scrum Master for a medium sized team that was moving from a waterfall/cowboy process to Scrum. Most recently I have been consulting with a smaller company that had previously loosely adopted Scrum, but has been bought by a larger company that has a more structured methodology. It has been a very educational experience.

One thing that I have learned is that a development team that wishes to get the most out of adopting Scrum must be a very disciplined team. It is sometime a misconception that agile methodologies are basically "the inmates running the asylum", but agile (and Scrum in my experience) requires a more mature and self-reliant team than waterfall. Scrum team are "self organizing" and are given almost total freedom to get their job done during each Sprint. They are left to determine what needs to be done, who works on what task, the approach for each item, etc. often with little to no outside influence.

This is quite a big responsibility and I have seen many people (and I include myself) struggle with it. Less mature developers may dive into a technical task and be oblivious to how their task relates to the project as a whole. Often they do not take advantage of the Daily Scrum meetings to get a good sense of how the team is progressing towards the current Sprint goal. These developers will often under estimate tasks and their deliverables will tend to be less on target.

Scrum Masters can fall into old habits also. As a Scrum Master I tended to want to "lead" the team rather than facilitate the team leading itself. Sometimes this was "muscle memory", but often I had to provide a more hands on approach when my team would start to drift away from the goals of a Sprint. I had to make a concentrated effort to let go and allow my team to run itself. I also am guilty of getting off track in the sacred Daily Scrum meetings. My team takes great joy in using my own phrase "Don't tell me about the pregnancy, show me the baby." when I do this.

I think that most every developer really knows what must be done to create a solid software solution, but what we struggle with is the discipline to execute in our daily activities. It is often easy at the beginning and then gets decidedly harder as the pressure increases. I personally struggle with this and am trying to make a real effort to make myself adhere to the principals that I believe make me a better developer.

Just this last Sprint I found myself continuing on a task that we had time boxed to a few days. At the end of the time period I was very close to wrapping it up and decided to extend the time period. Each time I got "close to finishing" another issue arose and I extended the time period again. I did finish the task and the result will greatly benefit the team, but other tasks were sacrificed. I also had to admit to myself that if another member of the team had done something similar, as the Scrum Master I would have probably called them out on it. It was another lesson it how to be more disciplined in my approach.

My hope is that each day I gain a little more experience and a little more practical approach to how I adopt (and sometimes DON'T adopt) agile/Scrum philosophies. That way the next day I become a more disciplined developer.

VSTS2008, TFS2005 MSBuild Woes

This last week I have been working with a client to create MSBuild scripts for build automation. We ran into various issues and after various web searches and blog mining we got everything working today. Although I am not a big fan of posting links to items that have been blogged about rather frequently, I decided to provide a rundown of our issues and the blog posts that helped us fix them because of the large amount of sites that had wrong or misleading information.

Our first issue was the fact that our applications were built using Visual Studio Team System 2008 targeting both the 3.0 and 3.5 versions of the framework, but our Team Foundation Server was still 2005. There were several posts about creating custom tasks or using Powershell, but the simplest resolution was to simply use the FileUpdate task in the MSBuild script to modify the solution file. This was not actually in a blog post, but in the comments to this one. I would add to this approach that you change it back somewhere after the CoreCompile target fires. I opened the solution on the TFS server itself a few times to troubleshoot some other errors and without changing the file you get the conversion wizard when you try to open the modified solution file.

This worked for our 3.0 projects for our WCF services, but our web application needed the 3.5 version of the compiler due to our use of C# 3.0 syntax such as automatic properties and object initializers. Again there were several posts with various resolutions (some involving create another build server with a modified MSBuild.exe) but most were not acceptable to the client. We eventually called the DEVENV for VSTS2008 directly from the command line to build the web application solution. This worked better than I expected and even itemized build errors in the build log just as if it were part of the core compile. Calling the DEVENV was outlined in several blog posts also, but a fair amount of these had incorrect or incomplete syntax. Finally we found this post that provided the correct syntax and a very clear explanation of why it works. This resolution also helped us overcome the glaring omission of MSBuild support for setup projects.

So after many, many failed builds we finished our build scripts today that compile all of our solutions, build the setup projects, copy the MSI files to a network share, and then use PSEXEC to install the application on our development server. We have a separate batch of build scripts for the different branches in the code so within a few minutes I can deploy any branch of the code to our development server (or local machine) for testing. Even with a few days to figure it out the overhead of doing that manually will save us much more time in the long run.

New VPC Image for TFS 2008 VSTS 2008

When I presented at teh Chattanooga user group the otehr night I spun up my VPC image with TFS 2008 and VSTS 2008 on it to run thru my demos before I started. It was then I rememberd that the image expired last week. I set back my system date to get thru the presentation with only one demo (the CI Build creation) bombing out due to the change. Looks like there is a new image out there that expires Dec. 31, 2008.

Chattanooga .NET User Group Presentation

Presented at the Chattanooga .NET User Group last night. I did my Scrum in TFS talk and the audience was very engaged. It was a good balance of using TFS to automate common, time consuming development tasks and pragmattic ideas on how to implement Scrum. Chattanooga has a great group and the facility was top notch. Thanks to Anthony Bowman for inviting me down!