You will probably never see an Xbox Fit because Microsoft would never get away with things like Nintendo does with the Wii Fit. You have maybe seen this comic before and if you don't own a Wii Fit you may just laugh at it. But there is a lot of truth in that comic. I know because I own a Wii Fit. Let me tell you what I've experienced...
Sometimes (about once every month) I get a question when I start Wii Fit: Have you noticed anything about X's body recently? "X" is the name of my wife who also uses the Wii Fit. And I have to choose one of four answers: "No change", "Gained weight", "Loosed weight", "Better posture". This is a loose-loose situation for me. Because if I answer "no change" or otherwise wrong I'll get a "maybe you're not paying attention to X". If I choose the "correct" response the Wii will tell me: "you should say that directly to X". So either way, regardless of my answer, the Wii Fit will make me feel guilty...
My wife get another kind of questions... I tend to use the Wii Fit pretty late in the evening and then play some games. When that happens it gets close to (if not passed) midnight before I turn the Wii off and go to bed. In the morning (around 6am) I get on my Wii Fit to get the daily weight. I do this in the morning because it kept telling me, doing the fitness test at different times each day makes them less accurate. So I do it in the morning. Somehow it checks my user profile and sees that I was up late so it pretends it's sleepy. And then my wife get messages like: "You should tell Y to sleep more". Y being my name.
Think about that for a moment... The game uses my profile to harass me and my family about my sleeping habits... The intention is good but isn't this an invasion of privacy? Now think what would happen if Microsoft released a product that tracked your habits and started to tell you (and your loved ones) that you should change... That's why I think we'll never see Xbox Fit.
Talking about the Wii. There are however a few other cool things you can do with the Wii that I'd love to see on the Xbox too...
Here is one example of what you can do with System Center Cross Platform Extensions. Just wanted to let you know...
Military combat is not the only military concept where software development can learn. One thing we used in my unit was "positive reporting". Positive reporting means that we should report in to our commander often and not only when things go wrong. This helps the commander knowing what's happening.
The positive report concept also includes adding suggestions on what can be done. This is important since the commander is typically not there and is not able to see all opportunities the terrain and situation offers.
Bad example: Hotel-Alpha at check-point 42.Good example: Hotel-Alpha at check-point 42. We have clear view of check-point 4711 and I think we can take it without support.
In software development we can benefit from using the concept of positive reporting. The first part, keeping the "commander" (product owner) updated can be done with daily scrums, burn-downs, task board etc. Things we typically do. The second part however is one thing many software developers don't do very well. Instead of just bringing problems to the surface, take a few moments and try to think of a way to solve the problem (as in combat acting is better than reacting). Even though the suggested solution may not be the best one, it will quickly get you back toward the goal. And the suggestion it self will trigger others to think of better ways to solve the problem.
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.