Agile 2010 Conference Location Move

Due to the damage caused to the Opryland Hotel from Nashville’s severe flooding this month, the location for the Agile Alliance’s Agile 2010 conference has been moved to The Walt Disney World Dolphin Hotel in Orlando, Florida. The dates will remain the same (August 9 - 13th). You can find more details about the move here.

Since I live in Nashville, it is doubly sad for me since I will most likely not be able to attend this year and I hate to see the economic impact of a large conference like that leaving the city especially now. I understand that there were no venues in Nashville for the same dates available, but I wish they could have stayed.

Good luck to Jim Newkirk and the conference staff in organizing the move and I am sure it will be another great conference this year.

Nashville Agile User Group: Getting Our Act Together

I became involved with the Nashville Agile User Group a few years ago, first as an attendee and then helping out as an organizer. As with most groups with volunteer leadership, the group’s activity rises and falls with the free time of those organizing it. Both my self and Jeff Mikres have tried to keep things consistent, but its been hard in the last year to get the group back to a regular meeting schedule and drum up more attendance.

With the Agile Alliance’s annual conference, Agile 2010, being held here in Nashville this year, I think this is a golden opportunity to grow the group as well as our local Agile community. We had a reception in March with several of the Agile Alliance board members to help kick things off and I am hoping that leading up to August we can keep up the momentum.

Here’s an overview of what going on:

Monthly Meetings

Our monthly meetings are held the 2nd Monday of each month. We moved them to 12 PM per the requests of those who regularly attended. We are currently hosted at the Vaco offices, but have opened up the possibility of rotating meeting locations every 3 months to different parts of town so everyone does not always have to drive out to Brentwood.

These meetings are run in an open space style with topics suggested and voted on in the meeting held previously. And even though we always start with that topic in mind, if the majority of those in attendance want to talk about something else, then so be it!

We do have plans to take advantage of our affiliation with the Agile Alliance to have some nationally renown thought leaders in the Agile community take part in meetings in the future. They provide funds for expenses for bringing in speakers that we can use.

Our Website (AgileNashville.com)

Our old website was a fairly active Google forum that eventually died out. We then moved to a site hosted on Ning.com that offered a bit more features. The Agile Alliance is experimenting with their own social networking site for user groups to use and while we have a site up there now, until that becomes official and supports all the features we need, we will still use our Ning site as our main website.

I encourage everyone to participate in the forums and online polls on the site because that really helps us gauge interest and preferences of our members.

Another Agile Alliance Reception

We are looking into having another (albeit somewhat smaller reception) with the conference planning committee from the Agile Alliance later in April. They will only be here over the weekend and we hope to host something on a Monday near the airport so they can participate. Check for updates for this on the website events page.

We Need a New Logo

I am asking for helping creating a new logo for the user group. We would like to incorporate something about Nashville. I ham-fisted one out, but it really is only there until someone with better artistic capabilities and create us one. You can post those to the website as well.

All in all I think this is going to be a great year for the Nashville Agile community and we would love more people to get involved with the user group. Please sign up on the website and spread the word around!

“Don’t Read the Architecture Documentation, It is Not Up To Date Anymore.”

You can replace “Architecture Documentation” with any kind of artifact used to describe the design or implementation of your application. This can also apply to requirements, but for this article we’ll stick with technical documents. This happens quite a bit in shops that have a heavy waterfall or big design up front process. The architects work feverishly at the beginning of a development effort to think up an application architecture that will meet every expected need for the entire solution for the duration of the project. They will then painstakingly record this technical wonder in various forms of documentation including lots of UML diagrams because if it’s documented in UML, it has to be right. And much like the architect in the second Matrix movie, they believe that their design is “ a work of art, flawless, sublime.”

And most often when you get into the trenches of actually developing the software, ideas that sounded good on paper often fall apart in implementation and have to be modified to varying degrees. And like good little developers we immediately run back to the now out of date documentation and correct it. Right? Of course, and we deliver the updated documentation to Bigfoot on magical unicorns.

So why does this happen?

• Too Much Design Detail Up Front – Unless the application you are building is exactly like that of those you have built many times before with the exact same team, on the exact same infrastructure, with the exact same technology, and you have at your disposal the ability to manipulate the world to be the exact same as when you developed each of those previous applications, your lovely design will most likely have to be modified during implementation. Often we try to mitigate this fact by documenting even more as if the sheer onslaught of technical details will negate this age old truth.
• Concentrating on Building Frameworks and Not Features – As developers we love to solve the world’s problems whether it asked us to or not. The wasteland of shelfware is littered with the bodies of “flavor of the month” frameworks well intended developers created in hopes of alleviating all foreseeable issues in the future. This also tends to make the design more complex (although most who do it argue the opposite), and requires a certain level of documentation up front just so the developers who work on it can get their heads around how to implement and use it.
  
  This can also result in bloated software that is hard for others to maintain. While a solid architecture often leverages industry proven frameworks like Entity Framework, nHibernate, etc., it is important to weigh each framework you adopt (or write yourself) with the justification of the cost it will incur. We must also look at many of the non-technical implications that can have a large part in the decision like the level of expertise of the people implementing and supporting the application.

Here are some practices and principles I think help:

• Emergent Design – Some think Agile prescribes no design and just slinging code from the start of a project. This is a common misconception. The practice of emergent design is more about designing at a high level initially to clarify the big technical questions, but using tests and developing in iterations to validate design choices as you make them. It is a counter to the so called “ivory tower” architects who stop writing production code and work in more theoretical matters. There are times when this type of work is very much warranted but some detailed specs along with a reference application cannot be deemed as technical gospel until it is proven with production ready implementations. How much design you do up front and how much you allow to evolve along the way is a very contextual decision that should be evaluated for each project.
• Design as a Team – When you design the application as a team, then there is less need to document up front since everyone will be on the same page. It also tends to ensure developers stick to the architecture and design approaches, since they had a hand in crafting them. Another benefit is that junior developers are exposed to elements of the solution and the process for creating it that they might not have had a chance to experience if the application is designed only by the senior team members and then handed to them to implement later.
• The YAGNI Principle – This stands for “You Ain’t Gonna Need It” (I’m southern so we use ain’t instead of aren’t) which is a mantra used by Agile programmers to resist the urge to gold plate software. The more bells and whistles we try to add, the more moving parts it adds and the more points of possible failure we add. I have definitely seen this taken way too literally but stopping and really thinking about whether some extra technical detail is truly needed to meet the business need is always a good practice. The more well known and less controversial version of this is KISS (keep it simple stupid).
• Self Documenting Code – Agile does not mean you do not document. If someone tells you that, then you have my permission to punch them in the ear. Read the Agile Manifesto and you will see it says comprehensive documentation. So there is a certain level of up front design and documentation, but treat that documentation as perishable the second you implement it in code. Once the code is written then the “Code is the truth.” Writing the code in a way that its intent is obvious, even to those not extremely technical, is a great way to preserve the truth of the design. Aside form the code, there are many applications out there that can pull information out of the code into more formal documentation and diagrams so that the intent can be expressed outside of code such as nDoc, Visual Studio 2010’s Architecture Explorer features, and many more.
  • A Side Note on Code Comments – I have attended quite a few sessions/presentations over the years that say comments are evil. Well you can shut your cake holes because I like comments. I am not talking about silly, obvious comments like this:
    
    //Declare new Customer.
    Customer newCustomer = new Customer();
    
    I am talking about things like XML comments in C# for all public members of a class, and sparingly used comments that sometimes explain why something was implemented the way it was. I also follow the practice of using comments as the stubs for the code I am about to write (something I picked up years ago from Code Complete), but I normally replace those comments with the actual code.
    
    But do understand that when I say “self documenting code”, that does not refer to comments, but rather the formatting and naming of those code structures. If I have to read your comments to understand the intent of your code then I do take issue with that.

The Agile Alliance Visits Nashville

On March 10th, the board of the Agile Alliance held a reception here in downtown Nashville at B.B. King’s Blues Club. They were in town to tour the Gaylord Opryland Hotel where they will be hosting the Agile 2010 conference in August.

The reception gave local Agile enthusiasts the chance to sit down with these thought leaders and have some great conversations. Benny Baggott, from Ingram Book, told me how great it was to chat with Henrik Kniberg since his book “Scrum and XP from the Tranches” was very influential in his organization's adoption of Agile practices. I talked at length with Laurent Bossavit  about Agile adoption, certifications, and more. It was a real treat.

Phil Brock gave us a sneak peak the new community section of the Agile Alliance website and invited the Nashville Agile User Group to be a test group for the site. If you are interested, please sign up on the site and provide us your feedback. The hope is that more groups will use this site which will provide a cohesive community.

Jim Newkirk gave us an overview of the upcoming conference in August and opened the door for anyone in Nashville who would like to volunteer. If you are interested hit me on Twitter and I will get you in touch with Jim.

It was a great night and there were many new faces in the crowd and I really hope this will translate into surge in activity in the local Agile community. So sign up on our new website and we will see you at our next meeting!

MVP Summit 2010

Last week was Microsoft’s MVP Summit in Redmond, WA and this was my first year to attend. The week was packed with tons of content and events and it was hard to decide what to go to at times. The Team System MVPs (now known as the Visual Studio ALM MVPs) basically sequestered ourselves in a room on Microsoft campus with members from the Visual Studio and Team Foundation Server product teams rotating through to get our input on the upcoming RTM for Visual Studio 2010 as well as what we would like to see in the next version (or service pack). It was great to have such immediate access to the very people who write the software we use everyday. 

It was amazing how many smart people were in those rooms and I got to finally meet many of the people I interact with online regularly in person including JB Brown, Mickey Goussett, Jeff Hunsaker, Chris Tullier (who was nice enough to show me around Seattle on my last day), and more.

Neno Loje organized a great gift for Brian Harry of a Chuck Norris style T-Shirt with sayings such as “Brian Harry’s planning poker deck has only the zero card.” You can get your very own here.

I have to say to all those people who bash Microsoft for not supporting the developer community, they could not be more wrong. Not only is the MVP program and the summit a great way to recognize thought leaders in the community, but it’s a valuable opportunity for us to provide them with feedback. Their evangelist program is also very active in supporting the local communities.

I just hope I get to go back next year!

“It Works on My Box!” And Other Common Phrases That Indicate Smells That Agile Practices Can Fix (Part One)

You hear them all the time in software development shops, these common phrases that always get a laugh in my presentations because people are so familiar with them. And while we hear them and maybe even say them ourselves, we seldom take a closer look at the underlying issues with our software development principles and practices that cause us to hear and say them so often. Let’s take a look at some of the more common phrases and see what issues they often reveal and what Agile practices might help alleviate them.

“It Works on My Box.”

This is by far my favorite because I hear it (and I admit that I say it) quite a bit. It is most often uttered by a developer who is told some feature they authored is not working on the server or another developer’s machine. It is so common that there are t-shirts and even a song. Very funny but it can be indicative of several issues:

• Developer Apathy – Often the phrase is accompanied with a shrug as the developer walks away. Not a very good team effort to drop the ball like that and leave someone else to pick it up and try to figure out what is wrong.
• A Poor Definition of Done – If your process allows developers to simply get something built and tested on their personal machine, then you will hear this phrase more than you would like.
• Siloed Development and Late Integration – Often teams split up tasks and go away for long periods of time to write code in a vacuum, coming together late in the process to start seeing if what they have written separately will work when integrated together. Which it rarely does right off the bat.

So what Agile principles and practices can help prevent you from hearing this phrase over and over?

• Continuous Integration - Since CI builds (and tests hopefully) software that is checked in on a separate environment, these types of issues are caught earlier. If you implement more robust stop gap measures such as TFS 2010’s new gated check in feature, you can proactively prevent bugs of this type from even getting into the source on the server. I personally think this is one of the low hanging fruits of Agile (more specifically XP) since you have to build, integrate, and deploy the solution sometime anyway, this just makes you do it sooner and more often. There are many good solutions out there besides TFS such as Team City and Cruise.
• Clear Definition of Done – Even though there is an implicit definition of done most developers have in their heads, you should sit down with your team and clarify what everyone expects to have been completed when someone claims a certain coding task is “done”. I suggest writing in down on a big sheet of paper and posting on the wall in the team room. So when someone says “Oh yeah, that’s done.” you can point to it and ask “Really?”. This can also help remove another common developer phrase from your teams vocabulary: “Done done.”

Stay tuned for our next entry: “Don’t Read the Architecture Documentation, It is Not Up To Date Anymore.”