Up until recently I was a platoon commander in the Swedish national guard. Since all peace time activities in the Swedish national guard are based on work done voluntarily I applied a number of agile principles when running the platoon. I used a task board to visualize all activities needed to plan future exercises. I had at least monthly meetings with all squad leaders to keep us all updated. At these meetings we also discussed how the platoon activities could be improved and planned for the next few weeks. So we definitely used the concepts of retrospects and task board. Not very militaristic but when working with volunteer weekend warriors I think it worked out pretty well.
The Swedish armed forces enforces mission type tactics. This leadership philosophy was used successfully by the Germans during the second world war and have since been used in most special forces units. The basic concept is that each commander gives his subordinates the mandate to solve a task given the best way they see fit. The commander must also make sure the subordinates have enough resources to complete any task given. This sounds very agile to me. Maybe not what you expect an organization that is extremely hierarchical.
This made me think that there are maybe more military situations where we can see typical agile properties. And maybe even we can learn from the military to improve how we develop software in an agile way. The first thing I thought of was combat. Military combat means chaos. Agile software development is a try to control the chaos of software development. When I look at how I have prepared my previous platoon for and then engaged in combat have a lot of resemblance with how agile development projects are (or should be) run.
Almost all projects start with some kind of planning and so does military combat. There is also a military saying: "No battle plan survives the first shot fired". So how do I create a good battle plan for a platoon? Well, the bottom line is to provide as much information as I can about the situation and what I want to happen but without being too detailed. The first thing to do is to gather the platoon. The best plan is one heard by everybody and not just the squad leaders since when squad leaders tell their squad some information may be lost or accidentally changed. Once the platoon is gathered I start with giving them information about what's known about the enemy and what's known about other friendly forces. I also tell them what the task of the company is and what's our platoon's task.
When the situation is known I tell the platoon what the goal is. If our task is to assault a hill, I tell them where our squads should end up when the assault is completed. This is very important since during combat it will sometimes be hard to get all the needed orders out to each squad. But since everybody knowns what the goal is everybody can work toward that goal without explicit orders.
After I have told the platoon what our goal is I give quick overview of how I plan to get to the goal. Still without being specific. If there are any situations I can predict I would also tell the platoon what these are and how we should handle them by default.
Example: If we're ambushed from the right. The default action is to suppress with engaged squads and outflank with Hotel-Alpha (Hotel-Alpha being the call-sign of one of the squads).
Now that everybody knows the big picture, our goal and my intentions on how to get there it is time for orders. Exactly how these orders look like obviously depend on the situation. But I have always tried to give an order for what the squad leader can see. And one prepared order. A prepared order is most often what I intend for the squad to do once the order is executed but it can also be a reaction to one of the predicted alternatives we have. Example: Hotel-Alpha, advance as last squad toward target. Be prepared to outflank.
The reason to give an order which only includes one thing that the squad leader can see and one (or maybe two) prepared order is that I want leave as little room as possible for misinterpretation and not force the squad leader to think to much about what comes next. Also if something happens and the orders must be changed my experience is that no orders but a clear goal is better than a lot of orders with a clear goal because people tend to stick to the orders if they still apply.
A little comparison: The goal is to advance to and cross a road and then assault a house. Think about these two alternatives (where everybody knows we are to assault the house):
The second alternative (B) is much easier to do right. Also we don't know what will happen at the road.
Also the order includes important information like where wounded soldiers should be transported, where we should retreat to if the enemy turns out to be too strong and where the platoon commander will be during the assault.
Finally every order is ended with me asking each squad leader and then the platoon if there are any questions. Questions are answered and then each squad commander is asked to repeat his orders. This way I know they know what to do. Even with simple orders you'll be surprised how much can be misunderstood. Especially if you start trying to give orders for several steps of the assault.
So, no battle plan survives the first shot fired. So what do we do to control the chaos of a combat? Information is important. Observations by individual soldiers are shouted and repeated by all others so everybody knows what's happening and can adapt to the evolving situation. The same applies to orders and information from the commander. Also the goal (given previously during the order phase) helps pushing everybody in the right direction. Another important thing to win a fire fight is keeping the initiative. It is always better to act then react. Doing something is better than doing nothing.
So now we've won the battle and achieved our goal. What do we do now? The first thing that typically happens is that the squad leader gathers information from the squad regarding ammunition and injuries. This information is transformed into a summary to the platoon commander indicating what resources are needed (if any) in order to proceed.
I'd like to compare a military assault with an iteration. Giving the team the overall goal as well as the iteration goal will help the developers make the right decisions during the iteration.
If we compare the military order with the user stories in the iteration I think we can still learn something from the military. We should only have user stories the team can understand immediately (i.e. "see") and we should keep the number of options (prepared orders) to a minimum. Also make sure that important information such as where the product owner will be during the iteration is available to the team from the beginning of the iteration.
In the day to day work ("combat") it is important that everybody knows what's happening. Especially when something important happens I think the team would benefit from adopting the military way of shouting out critical events and having everybody repeating them.
There is no way anybody in the team would miss something if everybody shouted stuff like that out.
When the iteration is over we should naturally have a retrospect but there is one thing we can learn from the military. That is how we present the result of the retrospect. If the suggested improvements from the team are presented in terms of "what we need to complete the next iteration" I think it is more likely to be taken seriously than if it's just "we want to do this since it will be better". Also it focuses on what's needed to improve the process now. Stuff that will improve the process later can also be handled later.
I recently had a chance to really sink my teeth into xUnit.net. Since I've been stuck with CPPUnit for quite some time and working with xUnit.net was a relief. Compared to NUnit I find xUnit much easier and convenient to work with (and compared with CPPUnit it's in a class of it own).
I feel I must give you four good reasons (no particular order) for why I prefer xUnit.net:
So earlier I suggested you to take a look at xUnit. Now I'm telling you. You won't be disappointed!
I recently described how you can create your own usleep method when there isn't one to use. one thing that people however tend to forget is that the sleep methods (sleep, usleep, nanosleep) only guarantees that the calling thread will be suspended for at least the given time. There is absolutely no guarantee that the thread will resume its execution immediately after that time. On most platforms you don't really see the difference but there are exceptions. HPUX for example, even on an otherwise almost idle system I typically experience a delay of a few milliseconds even though I sleep for only a single microsecond.
So if you want your thread to sleep for an exact amount of time you have use a different approach than sleep. Even if you use some sort of synchronize mechanism (an event) and a timer (to trigger the event) there is no guarantee that the blocked thread will execute immediately when the event is triggered. This approach is more likely to work as expected than the use of sleep, but it is not fool proof since you never know what other processes execute on the system affecting your process' execution.
The closest thing you can come to exact sleep times is also the ugliest solution. You can always have a busy loop checking if enough time has passed over and over again. This will however change the behavior of the sleep into a busy loop which is rarely a good solution to a problem.
Since only a minimum time can ever be guaranteed with a sleep method, regardless of implementation you should not write your code so that it depends on an exact sleep method. I think you're actually addressing the wrong problem if you try getting an exact sleep. Instead try figuring out why you need an exact sleep and remove that reason because you'll never be able to get it to work exactly right. Maybe good enough for now but you never know what will happen in the future so it's just a bad design choice.
I didn't have the opportunity to attend the recent Agile 2008 conference in Toronto but I attended a summary presentation a few weeks ago. These are the key points that excited me.
People typically feel bad when they fail at something. But if nobody knows you've failed you don't feel so bad. But if nobody knows you're hiding something and that is not good for your agile project. But what if you celebrated every failure? Then you wouldn't feel so bad about it. And a failure is really something you should celebrate because a failure revealed means you can learn from it and improve. And improvement is definitely something to celebrate.
This reminds me of a story Tobias Fors told. In order to make people understand that it is OK to throw an index card/post-it away he sometimes let everybody on the team write something on an index card. And then without revealing it to anybody they must tear it apart and throw it away. Apparently some people refuse... I guess that is related to fear of failure in some way...
Dan North a.k.a. the inventor of BDD had a session where he showed how you develop behavior driven with a regular unit test framework. I think this is extremely interesting since I have always been convinced that BDD is just another name for TDD done right. Exactly how this is done will have to be a future article.
When you think about an agile project a lot of people think of an iterative process. But there are an increasing group of people who start looking at methods where the agile principles are used but without iterations. Kanban boards is one way of doing this that I mentioned earlier. I think this is a very interesting development.
I was also introduced to a new way of prioritizing items that was both fun, fast and effective even in large groups. I don't know under what name this was first described but I like the name trading game that was used during the summary. This is how it works:
On windows you have a problem you typically never encounter on Unix. That is how to get a thread to sleep for less than one millisecond. On Unix you typically have a number of choices (sleep, usleep and nanosleep) to fit your needs. On windows however there is only Sleep with millisecond granularity. You can however use the select system call to create a microsecond sleep. On Unix this is pretty straight forward:
int usleep(long usec)
struct timeval tv;
tv.tv_sec = usec/1000000L;
tv.tv_usec = usec%1000000L;
return select(0, 0, 0, 0, &tv);
On windows however, the use of select forces you to include the winsock library which has to be initialized like this in your application:
WORD wVersionRequested = MAKEWORD(1,0);
And then the select won't allow you to be called without any socket so you have to do a little more to create a microsleep method:
int usleep(long usec)
struct timeval tv;
SOCKET s = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP);
tv.tv_sec = usec/1000000L;
tv.tv_usec = usec%1000000L;
return select(0, 0, 0, &dummy, &tv);
All these created usleep methods return zero when successful and non-zero for errors.
There seems to be a lot of myths around the interview procedure at Microsoft. I had my interview a little more than a year ago and coming from Sweden it was a big difference to have the interview in the US. The interview is (as described in the myths) basically two parts. First half is number of people asking you to solve a number of programming problems on a white board. Since I flew in the day before and was severely jet-lagged this was a tough start. If the first guys thinks you're good enough you'll spend the second half of the day talking to different managers. At least this is what happens when you're interviewed for a software engineering position.
Another nice thing is that you're pretty good prepared for the interview by the recruiter. And there is no dress code. Actually they stress that since it is a long day of several hard interviews you should come wearing something you feel comfortable in. They're hiring you for your brain, not for what you're wearing.
So what kind of problems do they make you solve? Personally I prepared going over this list but don't expect to get any of those questions. I did not get a single question on that list. I have also (inspired by that list) added a few personal favorites that I use whenever I have to interview somebody.
Actually there is not much more to be said about the interviewing process I think. You have to experience it to know what's it like. And it is different for every person. Microsoft really tries to give you a challenge during your interview (at least my division does). So one thing I can tell you is that you feel pretty pleased with your self once you pass and get an offer.
So why is this filed under relocate? Well, I thought this would be a good start on a series of stories about my experiences relocating from Sweden to the US...
I was recently involved in a discussion where a company was developing an intra-net site using Apache and PHP on a Windows server. All clients were windows and they wanted to know who was connecting to the intra-net site (only accessible inside the company firewall). And they wanted a SSO (single sign-on) experience for the users. They refused to switch to IIS and using integrated windows authentication.
Since they did not really wanted to authenticate users, just get a hint of who was connecting. So faking a NTLM authentication request and then parsing the data would be enough. And the script for doing so is pretty easy too. Here is one script I copied from here.
Note that this is nothing you can use to authenticate users since there is no authentication taking place. And the user will, with a standard installed browser be prompted for user name and password and can write anything. The script just prints whatever is sent by the user. And there is also no SSO feel to this. In order to get the SSO feel you have to do one of two things. Either the user must add the site using this script to his "Trusted Intra-net sites" in IE. This is done via Tools-Internet Options-Security. Or the company can add a group policy in the Active Directory enforcing this. For a situation as the described intra-net site, the latter is obviously the best solution.
Recently oldnewthing wrote a series av articles on C# iterators. Especially part four is interesting since it describes how iterators can be used to simplify asynchronous code. I'm not a big fan of this kind of exploit of a programming language since there is a risk the code is harder to understand for new developers looking at the code but it is never the less intriguing to read about.
Now you should not skip ahead and read part four first. Read them all in order: one two three four
Sometimes I come across a team saying; "We can't use Scrum because there is no project. We just do what needs to be done on a daily basis." These are typically support teams, teams with a large support responsibility or teams with a lot of small projects running in parallel. On a rare occasion it is a marketing team who have seen the benefits in the development teams and want to be as successful but can't see how they can use Scrum. Well text-book scrum is not a good place to start. A better place to start is my previous guide. Having daily stand-ups are typically no problem in these teams. That is a good start but without the retrospects there is no obvious way to improve the process.
Most teams tackle this by having retrospects at regular intervals even though there is no iteration. And this typically works well. Recently I however heard of a team doing it a bit differently. They had a piece of size A3 paper on the wall and as soon as somebody thought there was something they could improve they'd put a post-it note on the A3-paper. Once the A3-paper was full, they had their retrospect. So instead of having regular retrospects they had them when there was a significant amount of things to discuss. This makes the retrospects "polled" when needed which is a very much along the lines of the kanban-philosophy I discussed earlier.
Actually using a kanban-board is another thing I would recommend these teams to use. The only practical alternative is to have iterations of one day length and we have to be a little bit pragmatic here. But the use of a kanban-board very well mimics the typical work of these teams. They typically have a short backlog of things to do for the next few days and as new things come in, it is prioritized and queued. Limiting the number of things that are worked on in parallel (as the kanban-board helps you to do) will help the team focus and also give outsiders a better view of what is going on in the team.
Most teams I worked with have at some point had a lot of work in progress. Sometimes virtually the complete sprint back log have been in progress. This is definitely a bad sign. The reasons for this situation to arise are many. It can be bad break down of tasks meaning several tasks need to be worked on simultaneously to get progress. Or it can be that tasks are blocked because of some external factor. It can even be because the team are not focused and works a little bit here and there instead of completing tasks. When the iteration end comes closer it is not probable all tasks will be completed since even if each task only need a small effort to be completed there are too many in the end.
So having too much work in progress at any given time makes it hard for an external observer to see progress and it makes the team unfocused. All teams I worked with have quickly seen this problem and addressed it at a retrospective. And I think the only solution I've ever seen is that the team commits to be more disciplined and completing tasks before taking on a new one and make sure the tasks are things that can be completed by it self. And this is often enough. However there is another thing you can do that also solves other potential problems.
You can use a kanban. A very good description on how to use a kanban with Scrum is available here. What the kanban approach is basically about is to limit the number of items that can be in progress. The Scrum-ban article also adds a few new columns not used in text-book-scrum in order to get more kanban feeling and a sense of pulling in the process. So this is a little more formal than just saying "we'll be more disciplined" and it is also measurable. So what other potential problem does the kanban solve? Well, even though the backlog is prioritized there are times when the team, for efficiency reasons, might change the order they want to work on tasks. Having a ready column between to do and in progress (once again I must refer to the Scrum-ban article) is a very good way of visualizing the difference between the team's decision "what to do next" and each team member's "what to do next". Also having a small preparation queue like this will more likely identify blocking issues even before a team member actually tries to start working on an item. I think this helps the team identify these potential blockers early.