I've lately been thinking about more things that the military do that is either something agile teams typically do or something agile teams can learn from. So one thing I've been missing in my day to day work lately is how I, as a platoon commander, worked with my platoon sergeant (i.e. the person second in command in the platoon). As platoon commander I gave orders for some activity and the platoon sergeant then lead the work and sorted out all the details while I planed our next activity. When in combat me and my platoon sergeant worked a little different. In combat the platoon commander leads the main force focusing on the most important target. The platoon sergeant leads any supporting missions such as outflanks or suppressive fire to support the main force. This type of cooperation is not seen at platoon level only. The same type of cooperation between the two commanders are seen from squad level all the way up to the supreme commander.
The same type of cooperation I experienced in the military is what I see when I do pair programming. The only difference is that there is no commander. The commander role switches all the time. There is two ways to see this. Either the person at the keyboard is the platoon sergeant carrying out the last order (i.e. making a failing test pass or refactoring). In the mean time the person not at the keyboard is thinking about the next step. Or the person at the keyboard is leading the most important part of the mission (making a failing test pass or refactoring) while the platoon sergeant next to him do supportive tasks.
Either way you look at it the way a squad, platoon or company is lead by its commanders is very similar to how pair programming works. And if that is very similar then we should be able to compare how things work when you're not doing pair programming. If I lost my platoon sergeant and did not appoint a new one my work as a platoon commander became much more cumbersome and less fun. Also I tended to make more mistakes and wrong decisions when I did not have my platoon sergeant to help me out with practical things nor having him as somebody to discuss possible solutions with. And I think the same applies to not doing pair programming. You tend to make worse design decisions and more mistakes if you sit by your self all day. Naturally you can get some of the synergies without pair programming if you make sure you discuss all design decisions with somebody. But pair programming will give it to you auto-magically in both big and small decisions.
I've never been a big fan of triggers in a database since the existence of triggers is easily overlooked. I've also seen the use of triggers in situations where they where used to fix a bad database design. Specifically trigger were used to enforce constraints on other tables. I've also seen triggers used to move data to another table to keep history of records. I think that use is debatable since a stored procedure can be used to do that and the application should use the stored procedure and not do delete and updates directly. So in this case the trigger was used to protect the system from developers not following the application design. This should not really be needed but...
Anyway, since I've not been working with triggers for quite a while I've never really thought about the options available but today I saw this video (requires free registration) which covers instead of triggers. I think it's a nice feature which simplifies the implementation of protect-from-developers type triggers since you can basically redefine a delete to not do an delete at all and vice versa (if you have the urge to delete data instead of updating it).
But in my opinion triggers is not the best way to handle things in your application. Use a stored procedure since a trigger easily is forgotten but a used stored procedure is not. Also it is easier to follow the flow in a stored procedure over trigger execution. And if you have a nice stored procedure everybody should use but your developer keep screwing things up by using inserts, updates and deletes directly in the database then I would consider adding a trigger preventing direct use. This can be hard since the stored procedure it self will cause the trigger to execute but in my experience the stored procedure typically updates only one record at the time so an easy way to try to find developer "abuse" is to prevent updates of more than one row at the time. That has been enough for me so far.
Preemptive comment response: I know instead of triggers is nothing new and has been available for some time but I've just not been interested in triggers for the last 9 years so please forgive me...
Third MSFTCorpDojo today and MineSweeper and MicroPairing again. We did almost no design this time and started with only end-to-end tests. In my opinion the purest way of executing a kata. We had very good progress in the first hour but started refactoring our tests quite hard, something I've never seen to this extent before in any dojo session I've ever attended. The result was that we did not complete the kata but we ended up with eleven really nice tests with a few nice helper methods. And if we've spent another 20 or 30 minutes we would probably have seen classes (or at least one) emerge from the code all by them selfs, just as I expect it to be. All in all a great session.
I especially like the fact that one of the participants did not do any coding in his daily work and had never tried TDD at all before the session. And he felt he really learned something and that he felt he could contribute and participate as any other person in the room. I guess that proofs how well the dojo format works for all kinds of skill levels.
I only really experienced one big setback today and that was when we did a 10+minute refactoring that involved more than one person to complete. The refactoring was in the test code and created a very general method to generate input and output data for our tests. I'm personally not sure that refactoring really added value in terms of readability. I would personally have sticked with a much less generic and simple way of implementing my tests even though it would have left me with a few more hard coded strings. But I think that is OK in the test code if it increases readability. On the other hand we got a really nice generic method to use in future tests so I guess it's a trade off as usual and you should do what you think is best in each situation.
Dan North recently wrote about a situation I regretfully recognize too well. Imagine you're asked to take a number of user stories and estimate them using story points. You spend some time breaking the stories up and start estimating and then you get the question; so how much can be done in one year? You respond it is impossible to know since you don't know your velocity yet. And so everybody is frustrated. The customer have no idea and thinks story points is stupid because it doesn't help him. And you feel frustrated because the customer didn't tell you in the first place that he wanted to know how much could be done in one year.
I believe the use of story points is good since people don't estimate in time very well. The relative nature of story points and velocity is in my opinion a better way of updating release plans over time. So the effort is not wasted. And after a few iterations the customer will be happy about story points. But you have to do something else in the beginning. I favor making really rough estimates in man-months or man-iterations and using that as an indicator to the customer about the release plan for the next year. But I also tell the customer that this is just a rough estimate and as soon as we have our velocity we will have better prediction of the actual content of the release. Personally I also throw the initial estimates (using time) as soon as they have been presented. And I try to make the customer do the same thing.
When talking about Scrum you often hear that the sprint backlog should be broken down into tasks no greater than 16 hours in size. The reasoning behind this, in my opinion is to force the team to breakdown things. I know of several teams that decide on even lower limits. And even if you do not estimate the size in hours because you only burn down the number of tasks in the sprint it is still common to have some kind of guideline for a maximum task size. And there are at least three good reasons to break things down into small things.
There a certainly more reasons for why you should break things down into small tasks and probably a few why you should not do it. Even though I think the key when looking at when not to make small tasks is more of a when thing. Breaking things down into one day tasks and then saving it for half a year and then start working with them is not a good idea.