I've recently presented an RDN session around the country focused on agile development, and what it means for developers.

In each session I've been asking people for questions.  Here are a few of the most common questions, and some (short) answers for them.

1. How do you convince management that you should use an agile methodology?

Convincing anyone of anything can be difficult at times, especially if they have a deep grained bias against your proposition.  Without knowing your relationship with management the best advice I can give is to try and educate them.  Give them examples of success stories, show them studies and research, talk about Microsoft adopting the process, the rise of agile in the industry, etc.  Hopefully with enough education you can then convince them to let you try it on a small project.  Use that project to learn your mistakes, figure out what works for your organisation and then grow from there.

2. How do you convince developers to do Test Driven Development (TDD)?

Once again doing the convincing can be hard.  If you're team doesn't do unit testing at all, then don't even think about this for now.  Get them started on TAD (Test After Development) - let them write their code and then add unit tests and try and build up a good code coverage number.  Once they're comfortable with unit testing, interface driven programming, mocking, etc then you can think about moving to a TDD situation.

If your team is comfortable with unit testing convincing them to to TDD can still be hard and is something best shown by example and done by agreement.  Talk about it,  explain how weird it feels at the start, do some lunch time workshops with mini-scenarios to get the team used to the feeling of writing tests first.  Once that's done then try moving to TDD for a fixed period to help ensure that people get over the uncomfortableness (maybe a week or two) and then assess where the team is after that, and see if they're willing to continue or not.

3. When wouldn't you use agile?

Some projects deal with high risk environments or exist in a very controlled environment.  These projects usually have a massive amount of oversight & double checking that goes into each step of development to try and ensure things are done to spec and done right.  In these situations an agile process is unlikely to succeed.  Some of the principles of agile and the practices (TDD, Pair programming) may be applied, but in general because of the culture the project is much more suited to a waterfall style of development.

I also wouldn't recommend the use of agile in a large project (more than 20 people) _if_ the company has never performed any agile development in the past.  Doing agile on a large project with lots of inexperienced people is a high risk move and extremely likely to fail.

I should also mention something that Robert C. Martin said in a recent interview:  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.  

4. How do you deal with tenders?

I've touched on this previously (Fixed Price Contracts and Agile Delivery). In essence a tender is all about fixing time, price and scope.  However, if you consider the iron triangle (scope, resources, time & quality) you will quickly realise that if a tender is limiting scope, price and time then the only give you have will be in the quality of the product, or by supplying extending the costs through funding it yourself (ie provision of extra resources if required).

How do you then win a tender and still make a profit?  The same way as companies always have over the years - whack a hunking great margin of error on top of your estimates and start praying that your estimates are accurate and that you're assumptions around the requirements are correct.

In any tender based project the methodology you use to implement the solution is not going to change the fact that there are limits on 3 sides of the iron triangle. Both waterfall and agile implementations are going to be hamstrung by this from day one and only a big fudge factor will help bring the project in correctly.  That said, if I had a choice, I would choose to use an agile methodology each and every time because it will help establish a good collaborative relationship with the customer and having a good relationship with your customer means that you are much more likely to successfully navigate any difficulties in the project and avoid getting into contractual nastiness.

5. How do you convince management and developers that pair programming is better?

Once again, it's a mix of education and experience.

For Management: Yes, a pair of programmers will probably produce more lines of code individually than if they were to work paired, however the quality of that code will be of a lower standard than the code written by a pair.  This means that the business has a choice when it comes to pairing - they can either invest the extra time up front to get better quality the first time around, or they can invest cost into greater bug fixing effort (which also has a lost productivity cost associated with it).  There is a third option of course; they can absorb the bugs and accrue a large code and quality debt for the project.  Explaining it as an economic issue where pairing is the cheapest cost option is the easiest sell.

For Developers: Everyone has done pairing at some point.  They just might not have realised it.  Any time you get another developer to come sit beside you and help you out with a problem you are pairing.  Ask those same developers if they enjoy solving a problem with someone else or by doing it by themselves?  Most will answer that programming with someone else is more enjoyable.  This alone is usually a good enough reason to try it.  What you need to overcome are the initial objections like "I'll never get to work alone!", "it'll only work with the right people", "I won't get credit for my work", "I work faster alone!", "Do I have to sit next to someone else ALL day!", etc.  How you overcome these objections is up to you, but most teams that do pairing have a limit on the number of paired hours, or the types of work that people pair up on.  It really is up to you how you and your team to figure out the best way to make it work and the best way to do that is to try it out.  Much in the same way that a team might experiment with TDD they can experiment with Pairing.

 

As a note you might want to have a look at Pragmatic Programmers book Practices of an Agile Developer or Laurie Williams' & Robert Kessler's Pair Programming Illuminated.

I hope this is of value to you and for those who were at the RDN sessions, thank you for coming :-)