Thursday, July 23, 2009

VersionOne's State of Agile Survey 2009 Open

For the past four years VersionOne has run a survey for Agile adoption and published the results to the community. While it tends to lean towards people already adopting Agile practices, it is nice to see some numbers on other people's adoptions. I always take surveys like this with a grain of salt since questions that gauge the success of different Agile practices are very subjective. A developer answering the survey may have a different view of Agile's "success" in the organization than management. But all in all it's a decent survey and I encourage you to take it to help make the results that much more meaningful. Go here to participate in the survey.

Thursday, July 09, 2009

Evolution of an Agile .NET Developer in Books

I've been re-reading a few books lately and in the process it made me start to think of how differently I approach software development than when I first started. It seemed that each time I reach another plateau of understanding one or more books helped me get started on the next level. So in this post I wanted to chronicle my growth (which is still happening!) as a developer using .NET along with the key books that helped me. While I did development before .NET (VB & some Java) I am going to only stick to .NET for brevity.

Phase One: Programmer
When you first learn how to write software you learn the syntax of the language (C# in my case) and how to construct programs using that language. I myself did not go to school to be a developer (I was actually on my way to being a professional pilot) so I had very little pretense on theory or approaches. So I wrote code in a very functional way usually.

When I first started in C# I bought Programming C# from Oreilly. This link is to the fifth edition which covers C# 3.0, but I started with the first edition on 1.0 which is now out of print. I always loved the Oreilly books because they were very direct and to the point. This book was a great help in getting started with the language.

As I started to do more with .NET I bought C# in a Nutshell also by Oreilly. This is not a "how to" book but rather a reference for the C# language and the .NET framework. I turned to this book over and over again to figure out which class to use and how to use it. It was a great companion to the Programming C# book.

Phase Two: Developer
Eventually I was more sure of my abilities that I did not have to concentrate so hard on the coding part of developing software. I had a decent grasp of the language and the framework so I started wanting to write software in a more consistent and productive way. Another consultant told me to pick up Code Complete and it started me on my way to adopting some best practices that I still adhere to today. While it had nothing to do with C#, its content was applicable to any development language.

Also during this time I read (or skimmed sometime) quite a few books from WROX on several areas of programming in .NET which all helped me start to address specific problems in my applications.

Phase Three: Architect (or so I thought)
As I started to get better a writing applications using C#, I was being asked more and more to help design these applications then systems of multiple applications. I was lucky to work with many people who were much smarter than I was and they turned me on to quite a few good resources.

During one design session I was complaining about finding a solution to a particular problem and a colleague shook his head at me and asked, "Haven't you read the gang of four Design Patterns book?" I had to sheepishly admit I have never heard of it and then immediately went out and read it that week. After which I realized I had been describing a picture perfect scenario for an Abstract Factory pattern. I then bought two books on design patterns for C#: Design Patterns in C# and C# Design Patterns: A Tutorial . Using all three books I really started to delve into learning how to write more solid, reusable software.

Phase Four: Team Lead
Once I had been the architect or lead developer on a few projects I was being asked to lead development teams on bigger projects and that when I started to dabble in the project management and business analysis side of the software development lifecycle more. Either I was frustrated by the people in these positions or the project was small enough where the development team took on these duties. Either way I felt there were better ways to do both.

One of the project managers I worked with who was very good at his job loaned me a copy of the Mythical Man Month and it helped me start to think about projects in a wider scope than just the development effort. I was a big help in understanding how to interface with customers and managers and understand how to measure the progress of a project.

I was also given a copy of Software Requirements which gave me a new perspective on gathering requirements and mapping features to coding efforts. At this time I was also introduced to Rational's RequisitePro product which implemented a good deal of the concepts behind the book.

Phase Five: The Reluctant Agilist
By this time I had been leading software development projects for a few years with a good degree of success. I will admit I thought I had it all pretty under control and then a project that went bad started me rethinking how I developed software. Methods that had been tried and true for so long had failed and I was looking for some new ideas. At a new company I was re-introduced to the Scrum process for Agile development. I had heard of this before but to be honest I had dismissed it as the inmates running the asylum. Some of the engineering practices were appealing but overall I was fairly skeptical.

We did a pretty good job of adopting Scrum in all the wrong ways so I turned to Ken Schwaber's two definitive books on the topic: Agile Project Management with Scrum and The Enterprise and Scrum. To be honest I did not come away with much. Not that these are not good books but I tend to learn backwards in that I sometimes need the mechanics of something before I can relate it to the underlying concept. I then downloaded Henrik Kniberg's Scrum and XP From the Trenches and this book helped tie the concepts and mechanics together for me.

Phase Six: Agile Developer
On my next project I took all the things I had learned from our previous rough adoption of Scrum and applied it to our approach. I was lucky in that the management of my new client was very Agile friendly. I now really saw Scrum working and I started to concentrate on how to write my software in a more Agile way.

I attend a local Agile user group and won Practices of an Agile Developer. It was great in two ways because it not introduced some new concepts to me, it reaffirmed some of the lessons I had learned of the past few projects. It was a very easy to read book that provided a lot of information. At the next meeting I won the Art of Agile Development, which built upon everything I had just learned. Both these books made me want to learn Test Driven Development (TDD) better so I then grabbed Test Driven Development in Microsoft .NET.

I recently went back and reread Agile Principles, Patterns, and Practices in C# because when I was first given the book I was still not convinced about Agile and I really only skimmed the material. Going over it now had a much greater impact and there is so much great content that can be applied even outside of Agile that I suggest it to any developer regardless of their approach.

Phase Seven: The Empty Vessel
As I write this I have to say I am a little ashamed at how at some of these levels I thought I really knew everything I needed to know. It has made me really open myself up to learning as much as I can and figuring out the best way to apply that knowledge in my day to day activities. It was humbling to look at the publication dates on some of the books and think, "This has been around for awhile and I am just now learning it!"

There were more books along the way but I wanted to point out the ones that really pushed me to the next level of my development career and I hope to be constantly adding to this list for as long as I write software.

Thought Leadership is Good for Business

I have been lucky to work for some great consulting companies over the years who recognize the importance of their consultants actively participating in thought leadership and IT community activities. I was a technical trainer for a large part of my career and really enjoyed teaching. When I went into consulting it was great to practice what I had preached for so long but I began to miss being in front of a class. When .NET first appeared on the horizon, I along with several of my colleagues jumped on it and before long we were asked to start presenting what we had done at various technical organization in my area. At my very first presentation an attendee later contacted my company to bring us in to help them with their .NET adoption. The value was immediately obvious.

Since then I have strived to be as active a I can in local, regional, and national technology organizations as a participant, speaker, and organizer and I have seen first hand how this has helped my respective companies. Here are a few of the ways these activities have helped with our business:

  • Attracting New Employees: I've often had people come up and ask me about working with some cool technology. I always make it a point to only present on technology I have actually worked with and I've been lucky to see a wide range of solutions. When other developers hear about the projects I have worked on they too get excited and interested in being involved.
  • Advertising Your Solutions: Sometimes your company may have expertise in a certain technology and it is not widely known in your area. Presenting for multiple organizations helps get the word out that you have value to offer in a certain space.
  • Positioning Yourself as an Expert: It is easy to look like an expert for 60 minutes when you have plenty of time up front to plan, but when you really know the material it is obvious to your attendees. This does well to market your own abilities and thereby your company's abilities. While there may be other people with the same skill set in a certain technology, effectively being able to communicate and explain it is just as valuable.
  • Improving Employee's Communication Skills: Some developers are great at developing, but not so great at communicating. As a consultant, communication is a skill that is almost as valuable as your coding skills. Companies that encourage their employees to present are helping them grow these skills also.
  • Differentiates You from Your Competitors: There may be many companies that offer the same services are you do, but being seen as a thought leader in a certain space can really set you apart from your competition.

As you can see, there are some very real benefits to participating in IT communities as a Thought Leader. Companies who encourage the employees to pursue these activities and invest in them can see some very tangible gains. Even attending and supporting local IT groups can help with your business so get out there and be active!