One of the facets of the Agile methodology I appreciate is the emphasis on transparency.  Rather than ignoring the proverbial elephant-in-the-room, Agile helps us to quickly identify (and hopefully address!) the real issues that affect our teams.  This aids the continuous learning process as we must constantly face hard realities and find creative ways to address them.

A vital part of the Agile process is the retrospective.  In this process, the team members identify the events which have occurred during a previous time-period.  They then seek to discover patterns in these events.  Finally, the culmination comes as the team identifies ways they can continue doing what is working, improve on what is working, and avoid doing what has not been working.

It is important to enter the retrospective process with a dispassionate view as to the events which have occurred prior to the retrospective.  It is non-productive to place blame on individuals or circumstances.  Instead, we must work together to face reality in the form of hard facts. As we reflect on these factual events, we work collaboratively to identify possible solutions that enable the team to reach for ever more productive heights.

This isn't to say there is no room for feelings in a retrospective.  Certainly the team members may experience a range of emotions as they reflect on the events of the previous time-period.  But the idea is to avoid any form of us-them mentality, or to blame circumstances for the outcomes.

Retrospectives can be an exhilarating and enlightening experience.  They are a great tool for improving the continuous learning of your teams.

Version 1 of Microsoft's ASP.NET MVC framework has shipped.  Find out more about the framework or go download it.

In my previous post on Patterns & Practices, I discussed the fact that in order to learn P&P, you have to be willing to make mistakes.  In the early stages, it is beneficial to look for opportunities to apply patterns to your development so that you can begin to see how they take shape.  You may not understand their benefit in the early stages, but this is a vital step, akin to the experience of the "Karate Kid" as he was told to "wax on / wax off".  He spent weeks practicing the same moves over and over again, not really understanding the purpose of such repetitive tasks.  What he failed to realize was that he was developing muscle memory and creating well worn neural pathways that would prove vital in his development process.  This holds true for us as software developers as well. [For this early development stage, a key resource is a book such as Head First Design Patterns].

Eventually you gain some proficiency with the repetitive tasks.  You begin to realize that certain patterns work better than others in certain circumstances.  You might discover that some patterns can paint you into a difficult corner (Singleton is of course the prime example, though Static Gateway has its pitfalls as well). At this stage you are beginning to deconstruct the value and utility of particular patterns for certain situations and contexts.  You awaken to the realization that code can have a "smell" that communicates whether a design is fitting or not.  While you cannot necessarily name the "smell" it is clearly there.  [At this stage, you're ready to tackle Refactoring to Patterns].

Take time to identify patterns that fit well for addressing particular smells.  Look for examples in code written by others (you are taking time to read code written by others, right?).  And start looking for ways that improper use of patterns can introduce smells of their own.

In my next post in this series, I will switch gears and discuss the relationship between Patterns and Practices and why you ultimately want to emphasize the Practices over the Patterns.  Stay tuned!

When you first create a solution using Visual Studio 2008, your projects sort nicely in alphabetical order.  But then as your project grows, you begin using solution folders to organize your projects.  It is at this point that your projects no longer sort alphabetically within their solution folders. 

Of course I've heard of the trick where you just choose one of the projects in a folder, press "F2" (rename) and then leave the project name as it was previously.  But this is 1) a pain, and 2) only sorts projects in that one solution folder.

So I created a tool that will modify your Visual Studio solution file (.sln) and make the projects sort properly within the solution folders.  Check it out at CodePlex:  Visual Studio Solution Sorter (http://solutionsorter.codeplex.com/).