NFSJ(TDD, DDT, and other practices of Agile Folk)

I went to a couple of talks by John Carnell on Leadership and the Lean process. The lean practices sounded kind of interesting but I never really figured out exactly what was going on through out the talks. The one part of the lean process that I picked up was making Value Stream Maps to help figure out where your process was wasteful. I don't know that I would ever do that because I think everybody here already recognized where we are wasteful, now the trick is figuring out how to make parts of the process better where they are wasteful. The part that is really good, and I think I will start using is his estimation stuff. He showed a spreadsheet where tasks were estimated as ether 20,40, or 80 hour tasks, and then there was some percentages for prototyping, design, testing, and some different risk factors that would help to generate a low..assume all risk factors were 0% and a high which was calculated given the risk factor percentages that you entered. He offered the spreadsheet to anyone that wanted a copy so I emailed him to get a copy that I can start playing around with. If I come up with something different after I start playing around with it I will post it here.

The last day I spent all day at Jared Richardson's talks on Agile Process type topics. All the talks and topics kinda blended together. One of the big things he kept going over and over was that nothing works if you don't have CI ( continuous integration ) and test automation. That was one thing that really gave me a good feeling about where we are at today in the company. We use Cruise Control and have all of our projects building there and unit tests running when they exist, so at least we have the foundation built. Tracer Bullets was a really neat idea too. Basically set up an API at each layer ( DB, DAO, computation, display, etc. ) that returns hard coded data. Then you can verify before any implementation happens that your protocols work and the communication is there. As far as myself I took a lot of Integration level testing ideas from these talks. Basically I neglect integration, and if there is one thing I took from all of his talks is that integration tests are just as important as unit tests. I liked his idea of writing a very high level integration test first, then implementing the lower level code, writing unit tests as you write code, with the goal of getting the integration tests to pass by completing the units. In the past when I have written integration tests its always been the other way around...write all the units, then as I build up to the integration level I write the integration tests. Another cool testing idea was DDT, defect driven testing. Maybe this can get people on board with Automated Testing in that if something is broken you write a unit test for it. Then as everybody gets better at it, start moving towards TDD. I will continue to say that we should enforce at least unit tests be written on all code checked in. Otherwise we are just going to continue to generate more and more code that is not covered and keep building up the Technical Debt. I have already, unintentionally, done a Blitzkrieg of sorts. As we wanted developers to start writing more tests ( we encourage it, but rarely does it get done ) we went through most of our projects and added a few unit tests to each so that there was examples and the framework set in most every project. Peer Code Reviews are another thing that I think we should start doing. Today I think that my manager is reviewing my code, but generally speaking this is done when we do a QA release, and at the point it is hard to go back and change things. I liked the idea of forcing a code review before checking anything in, and enforcing that you cannot have the same person do 2 code reviews for you. We are a pretty divided department, one team works on one set of code and the other works on another set of code, we are slowly breaking down the barriers between code and everybody is working more on everything. But I liked this idea that somebody on the other team could review your code too, thereby helping them understand what's going on with the other team in the process.

A topic that came up in a lot of talks, not just Jared's, was time boxing iterations. I really liked this idea of breaking down tasks smaller building lists of what you want to get done. I think a lot of us were already close to doing this using SharePoint and/or Xplanner, but listening to all the different ideas I think I feel better about knowing how to do it. On of the keys that I never really thought about is that every task should take between ½ day and 3 days to complete. Along those lines the idea of a daily meeting that is really a stand up couple of minutes to answer 3 questions: What did you do yesterday? What are you going to do today? What problems do you have? Then if you have a visible list everybody knows whats going on all the time. All of these talks and information about lists, daily meetings, etc. lead me to think that we might be better off working in a more team orientated environment. We all work together very well, but maybe instead of each developer getting assigned to a project we assign a project to a group of 2-4 developers. Everybody can work together to come up with a good design and everybody can grab random tasks for code, which would lead to a bit more diversity. I am terrible when it comes to writing a design for everything that needs to get done, and often I think it would be useful to have a second person working on the design with me to bounce ideas off of.