I was involved in a discussion on what it means when a team commits to something. In this particular case one person thought that it meant the team will do what it takes to deliver this. I on the other hand I meant the team thinks it can deliver all this and will try to do it. A big difference. Yesterday I read an interesting post on this topic. I like how he talks about soft and hard commitments and this was exactly what I think the difference was in the argument I was involved in. I was thinking soft commitments, the other person hard commitments. And I must agree that in my ears commitment by default sounds hard.
One thing I don't quite agree with in that blog post however is that Kanban a no-commitment framework. It may look like that on the surface but I doubt a team doing Kanban where there is no real team spirit will do a very good job. So even though Kanban does not prescribe any kind of commitments it self, the kind of soft commitments that are mentioned, i.e. an emotional commitment to the team is essential to be successful in my opinion.
And the same kind of argument goes for Scrum I guess. I do not think scrum prescribes any kind of hard commitments. Only bad implementations of Scrum have a PO that demands hard commitments and teams working with hard commitments will also not be very successful over time. This is also mentioned in the blog post linked above so I'm not really disagreeing. I just think that well implemented Scrum is already in the "soft commitment only area" of the graph.
So I guess the conclusion you can draw from all this is that you'll get better results with only soft commitments. And that is hardly any news. Teams that work well together can perform well under most conditions. And teams with no cooperation will probably fail under all circumstances. So getting the team to work well together should be your absolute top priority. And also the use of words are important. Choose your words carefully and make sure that everybody has the same understanding of what a certain word means.
So yesterday I wrote about being proud about what you do, but also improving yourself. It made me think about a pretty scary thing that happened to me a few months ago. I was attending this training where we were divided into four teams and worked together for a few days to create an application. At the end of the class at the retrospect I suggested that in future classes each team could present some part of their solution they were proud of and wanted to show to the rest of the class. I said this because I thought my team had learned something and had done a few smart things that I wanted to share. We had some time to spare so the trainer suggested I show what I was thinking about and then the other teams could do the same thing.
So I showed our stuff and then no other team wanted to show anything. Maybe I'm a little extreme in my search for improvements and maybe I'm over confident in the excellence of our solution but in a room of 25 people I would assume at least somebody felt the same way about something. I don't believe they were all shy. Instead the class went silent and everybody went home. The thing that really scares me is that I think that there is a good chance that the reason for not wanting to show anything actually was that the other teams didn't feel proud about their solution as a whole. Because there was an element of competition there and it's easy to get carried away because it's not real code in the class room...
Finally I must point out that I do not think you have to do the ultimate solution each time to be proud of your work. I'm sure a master chef sometimes throws together something fast when at home. But I think the mast chef quick lunch probably tastes better than my quick lunch. So the effort needed to be proud might be different for different situations but that hunger for improvements is definitely something I think differentiates the good from the great. So if you do not take pride in anything else, at least take pride in striving to be better and be proud of each improvement.
A former colleague once said that there are only two types of people; those who want to do a good job and those who want to go home. And it has nothing to do with working over time. The statement is obviously provocative but you should not interpret it literally I think. What it means is that some people go to work, do what they're asked and then go home without necessarily having a passion for what they do. Others are very passionate about what they do and go to work because they love what they do there.
This to me is just another way of describing software craftsmanship which is being more and more popular lately. And think there are two important aspects of craftsmanship to consider. One is the integrity of being a craftsman. If you want to do a good job you should refuse to do something that you think is a poor solution. Compare yourself with a great chef. A great chef would never serve you something that is not prepared and presented in an excellent way. If you on the other hand just want to go home, just do whatever you need to get home early.
The other aspect is being proud of what you do. It doesn't mean you have to be proud of code you wrote a year ago or even a few months ago. I've written code I wasn't proud of even a few weeks later. The important part is that you're proud of what you do at least when you write the code. I'd even say that it's a good thing that you're not proud of old things you've done because it means you've improved yourself and that is important. If you however just want to go home, then you're probably not always feel proud about stuff you just did and you're probably proud over things you did ages ago. Because if you just strive to go home then you're probably not improving yourself very fast.
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.
So I have another comparison between the military and agile and in this case it's lean specifically. Lean prescribes making decisions as late as possible but sometimes it's hard to know when it's time to make a decision. In the military my last company commander taught me a rule he thought work well. It was the one third rule. The rule is that each commander have a third of the time available to prepare and give orders. The rest of the time is needed by the subordinates to execute the order. This means that if there is something that has to be done in one hour the company commander can use 20 minutes of that. Each platoon then have 40 minutes of which the platoon commander should use 13 minutes. Of the remaining 27 minutes the squad leader should use nine minutes to prepare the squad leaving 18 minutes to execute the order.
So this to me sounds very much like a waterfall because of the different levels involved and the 18 minute execution time out of one hour does not sound that efficient. The rule is not really a rule but more of a rule of thumb. I think the important lesson from this is that you should not make a hasty decision just because you're pressed for time. Instead set a time limit, gather as much information s you can and then make your decision. Another important lesson is that you must allow enough time to complete the order. So consider the thing that needs to be done in one hour. Assume you, as a company commander, knows that it takes 40 minutes to complete. So there is only 20 minutes of preparation and the company commander can only use one third of it. That's about seven minutes. The platoon commander get four minutes (one third of 13). The squad leader get three minutes to give orders and the squad get six minutes to prepare.
So far this is hardly revolutionary. Essentially the military decision making process states that you should gather as much intelligence as possible before making a decision (same as lean) and make sure there is enough time to complete whatever decision you make. Also if there is no hard deadline, set a deadline and make a decision.
Another important part about military decision making is that it's important to make a decision. Because acting is better that reacting. In the military you want to keep the initiative because the one who has the initiative will win. The essence is that it's better to make a decision now than the perfect decision later. And you must also know that you're making a decision that you may have to change later when you have more information. So you're essentially improving your decision iteratively. All this is sounds very lean in my ears.
I think good decisions makers make informed decisions. But they do not try to make the perfect decision and are prepared to change their decision when new facts are available. And they make sure there is enough time to complete what needs to be done. And I think being a great decision maker is really hard since it involves balancing between waiting and not waiting for more information.
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...
This time we diverted from what I think is a basic dojo rule; you start over each time. So we continued with our BankOCR variant from last time and actually finished it including extending the number of digits and having three different checksum variants. This time we made one mistake. Or maybe I did since I maybe should moderate the session harder. And that was that we got a little carried away to get things done rather than refactoring at certain times. In the end the code turned out pretty OK but the way there was shaky with pretty complex implementations at some times.
In the end it sounded like the participants were pretty happy with the session and we decided to actually continue the next dojo session with the same kata and code base but next time focusing on refactoring the code into something more object orientated using the nine Object Calisthenics rules.
The interoperability connectors for System Center have now been released:
I find this interesting since this was done by one of the other teams under the system center cross platform umbrella.
When I first started using xUnit.net the only feasible way to run the tests for me was to use the console test runner as a post build event in visual studio. The only annoying thing about the default settings in visual studio with this setup however is that whenever there was a test failure visual studio switches to the error window which doesn't tell me more than the number of failed tests (since the return code is the number of failing tests). But there is a way to tweak your environment to always show the output window where all the interesting things about the tests are printed.
Take a look at the options dialog showed to the right. By disabling the "Always show Error List if build finishes with errors" and also checking "Show Output window when build starts" you'll make sure you'll have the console output handy if the build fails with unit tests. The drawback however is that for all compilation errors (and warnings) you'll have to switch to the error list window. But personally I see more test failures than actual build failures when I develop code so all in all it's a win for me with these changes.