News

Robert C. Martin on Real-World Agile for .NET Developers

• By Kathleen Richards
• August 15, 2006

Agile adoption is on the rise in large enterprises. Robert C. Martin and his son Micah Martin are the co-authors of a new book that puts Agile practices to work in a .NET environment. Senior Editor Kathleen Richards talked to Robert C. Martin, one of the 17 Agile proponents who created the Manifesto for Agile Software Development in 2001, about his latest book, Agile Principles, Patterns and Practices in C#. He is also the author, or co-author, of several other books: Agile Software Development: Principles, Patterns, and Practices; UML for Java Programmers; and Designing Object-Oriented C++ Applications Using the Booch Method.

ADT: A lot of people have a loose definition of Agile software development. What is your definition?

Martin: The definition of Agile as stated by the manifesto, there are four statements there:

• Individuals and interactions over processes and tools;
• Working software over comprehensive documentation;
• Customer collaboration over contract negotiation; and
• Responding to change over following a plan.

I would add that Agile software development is development in very short cycles, something less than a month and perhaps greater than a week, augmented by a lot of feedback. That feedback comes from software executes at least every week or so as well as a body of automated tests.

ADT: Your book is focused on C# and .NET development. Is it applicable to all implementations or just Microsoft Visual C#?

Martin: The book uses C# as the example language, but the book is not particular to C# other than that. It is a book about general software development with examples in C#.  

ADT: How will Agile development methodologies change the day-to-day existence of a programming team and its members?

Martin: In using Agile development, a .NET programming team will be focused on very short-term deliverables; something that they need to get working in the next week or two. They will be focused on writing tests to create extremely high code coverage numbers, something on the order of 80 to 90+ percent and they will be focused on delivering business value. They will want to demonstrate their software on a regular basis to the business stakeholders and then be willing to accept change.

ADT: In your co-author Micah Martin's introduction, he says that Agile .NET programmers are almost unheard of, do you agree, and why is that the case?

Martin: I think that was the case a year-and-a-half to two years ago, I think it is less so now. There have been a number of companies that have adopted .NET as well as Agile development. I think this is partially due to Microsoft's interest in Agile development, which has shown up over the last several years and partially I think it is the general trend of the industry to go Agile no matter what platform you have chosen.

Visual Studio has also begun to show up with some features along the lines of refactoring and testing.

ADT: Although a large part of Agile is about collaboration and responding to change, what elements of the design are still critical to nail down upfront?

Martin: In a very small project, very little needs to be nailed down, the team will figure that out as they go along. For a much longer project, some very basic architectural decisions need to be made upfront, 'What database are we going to use?,' very fundamental architectural issues like that.

ADT: eXtreme Programming and Scrum are the most popular Agile processes. Isn't it easier to start with Scrum?

Martin: Many folks do in fact start with Scrum, and then continue on to eXtreme Programming. eXtreme Programming is the best defined of the Agile methods and it has the most discipline. It covers the gamut from business practices to team practices to technical practices, whereas a method like Scrum focuses mostly on management practices and not so much on technical and team practices. If you start with Scrum, it is very easy thereafter to move on into the more technical practices, which would qualify you as doing eXtreme Programming.

The terms have become much less meaningful nowadays. The Agile teams generally have some of the attributes of eXtreme Programming and some of the attributes of Scrum and almost none of the teams have all of them. So, I won't quite say it's a pick-and-choose mentality but certainly there is a high degree of variability among the Agile teams.

ADT: How are the Agile methods—refactoring, pair programming, and test-driven development— best applied in the .NET environment?

Martin: There is really nothing special about the .NET environment that alters these practices in any way. The tools for doing test-driven development are fungible and now available in the .NET framework. The ability to do pair programming is trivial in .NET—there is no real problem there. Refactoring tool support is not quite as good as it is in the Java environment, but it is pretty good. There are some third-party refactoring tools that are very effective and Visual Studio is gaining ground in that regard as well.

ADT: Why is it that the .NET crowd has been slow to adopt Agile development processes?

Martin: The Microsoft community is a somewhat insular. If you are a Microsoft developer, it is not very likely that you know what is going on outside of the Microsoft sphere. The same is not true for the non-Microsoft community, which does track Microsoft pretty closely. So what we find is that the Microsoft community tends to be a little bit behind what's going on in the industry at large and Microsoft tends to play a catch-up role.

ADT: Corporate types get nervous when planning, requirements and documentation aren't a big part of the process, how can developers calm these fears?

Martin: The notion that documentation is not done in these projects is a myth. Certainly documentation and planning are done, but they are done as one of the tasks within the process, not as part of the process itself. With Agile projects, there will be a set of tasks laid out, some of those tasks will involve documentation, will involve project planning, all those standard things that a management team needs, but it is not laid out in the process itself. The process itself is a way of managing all the tasks that have to be done. What that means is that there is no fixed ordering. We don't necessarily do the documents first. We don't do the documents last. We do it when it becomes important to do it so it becomes scheduled like any other task.

ADT: How is Agile development best applied in large corporations? Certain pockets are doing Agile processes but large companies typically aren't standardizing on this type of development.

Martin: Large corporations, more and more are beginning to use Agile development, there have been quite a few now that have made significant adoption. What we have found to be the best approach to this is a bottom-up training and mentoring approach where the teams themselves are trained and mentored as teams, not as roles, and that management is given a broad base of support for this kind of training and mentoring. It takes about three, four, five months, depending on the size of the organization to make this transition well.

ADT: When is Agile not a good solution?

Martin: As far as the kind of projects that should not go Agile, it is really a matter of company culture as opposed to project type. Very heavy command control cultures probably do not respond very well to Agile development. On the hand, very collaborative environments do. 

ADT: What do you think is most important for .NET developers to consider with regard to Agile development?

Martin: The biggest challenge I think the .NET developer is going to face in learning Agile development is test-driven development—the intense kind of unit testing and automated acceptance testing that Agile development requires. This is a discipline that is sweeping the industry whether it is Microsoft or not and it has become a significant force.