Almost two months ago Michael Feathers wrote a thing on zero length iterations. The post is very similar to the one that inspired me to write this but he also brings up an important point; the intention of iterations is to force a decision, force the team to make trade-offs and keep moving towards a goal. That is exactly what military decision making is all about; keep the initiative by making sure you make a decision that is as informed as possible before it is too late. I guess that is yet another example of things software developers can learn from the military.
I recently heard of somebody who moved away from using MSTest and started to use NUnit because NUnit called the class setup method, then all tests and last the class tear-down before moving on to the next test class while MSTest more or less interleaved everything. I'm not a big fan of MSTest so I'm absolutely not defending MSTest but I think the team that made this decision moved to NUnit for the wrong reason. First of all I want to make it clear that the problem was not with a set of unit tests, it was with an integration test suite that was implemented using a unit test framework. And being an integration test it neaded to setup a lot of things so it wanted to do the setup only once for each test class (i.e. suite). The problem was that several suites worked on the same data and hence could not run concurrently. I think that was the real problem. Each test fixture, regardless of if it is setup for a single test or a test suite must be isolated in it's context. This means that if you setup a database you should have different suites working on different parts of the data so that they can coexist. This is a good idea to avoid weird test failures because a cleanup method is not correctly implemented. If you're testing a network service you need to start it using different entry points (i.e. listening to different network ports) so that they don't interfere with other services being tested at the same time. Because if you design your tests in that way you will not be limited by the framework, it will just be a tool for you and you can change the tool more easily if you need for another more valid reason.
There was recently a discussion on an internal distribution list that caught my eye. The initial question was; when should you add more to a sprint instead of ending early? At first glance I think it is safe to assume that while the person asking the question claimed to be doing scrum he had missed a few points. One being; you keep the sprint length for a very long time. IMHO there is no ending sprint earlyin scrum. You keep your sprint length fixed since you want to measure the number of user stories (or story points) the team can complete in one sprint to make a release plan and estimate what will get into a certain release. So far I don't think there was a lot of discussion to happen but the question had some more information that made the question more interesting. Turned out that the team consisted of 8 people and they planned 4 user stories in the sprint. This meant two people was working on each user story for the duration of the sprint. And the question was more about what to do when one user story was completed. Do you bring in a 5th user story or do something else?
Basically there are two options; Either you bring in a 5th user story or you have the "free pair" helping the rest completing the planned user stories. This is when it gets really interesting since I don't think there is a simple answer. Or actually there are two simple answers; It depends and you decide. The important thing is that the teammakes the decision and that they make an informed decision. There are also a few traps an inexperienced team (i.e. a team learning Scrum) can walk into so the Scrum Master may want to prevent the team from making some decisions in some situations. These are a few things the team and Scrum master should consider:
In my opinion the situation described in the question is wrong from the start. Starting all 4 user stories at once and having pairs more or less working in silos on "their" user story for the duration of the sprint does not sound agile to me. It sounds like old fashioned silo/code ownership practice that is a bad investment for the future of the team. I think the majority of the team should swarm on the most important user story and then a few can start on the second most important one. By working on all 4 at once the team is risking to complete none. Top priority is to complete at least one user story, then two and so on.
After reading this which jokingly tells us that the Viking laws will replace the agile manifesto I started to think about manifestos and "agile". The agile manifesto well describes how you need a change in your mindset to become agile. And some try to refine it even further. But the Viking laws are brilliant. And I find it intriguing how they describe the right mind set for an agile software developer. Reminds me of my own observations on similarities with the military. Let me elaborate a little on the Viking laws and how I interpret them into a software development context.
Today was my last day on the System Center Cross Platform team. On Monday I'll be working on the Robotics team.
i got an email a while ago from somebody who had read this. The person was trying to implement a snake game and the question was about sleep times since the person used sleep to define difficulty levels. The higher level, the faster the snake should move. the problem was that he used a small sleep in a very tight loop and the snake did not really move any faster once you completed a few levels. He experimented and figured out that the sleep always slept between 10 and 15 milliseconds even though he tried to do a sleep for just 5 milliseconds. The problem was that he forgot this fact; Sleep does not sleep for a specified time. And interestingly enough; on Windows the resolution of a sleep call is between 10 and 15 milliseconds.
So how do you solve this problem? Since we're talking about a game we can safely assume it will be played by humans. And the human eye/brain combination can be happy with as low as 30 updates per second, but 60 should be a safe bet under most circumstances. Hence updating the snake position more often than 60 times per second (note that a sleep of 15 milliseconds gives you 66.666... updates per second) is not really necessary. So in order to move the snake faster at higher levels, all you need to do is to move it further each time you move it but always move it at the same interval.