Iteration Planning for E 2.1

Today we had our iteration planning session for Elaboration 2 Iteration 1. We have also acquired some new members to the team and project in general. The session went very well, we started using planning poker cards. As many of the members are new to the process it will take a while for a few key concepts to sink in, such as points not equating to man days, trying to understand that the point estimation is an independent process and team members should not concur or reveal their points before everyone does it as a group as this can influence other people's decision. I guess with more practice these things will become second nature.

In the session we managed to estimate points for and discuss the stories and then futher break those stories into tasks assigning effort in terms of time and associating owners. 

Generally the morale of the project has gone up, people are understanding and participating in the process and will start to see the fun side to it the more we do it.

I do need to find a good analogy for the points not equating to man days problem. 

Here are some statistics from the session:

• 9 Members & 121.5 man days
• 34 points
• 47.25 days to burn
• 45% focus factor
• 7 stories to complete

Mental Models

A colleague of mine was in a bit of a predicament earlier and asked for my opinion on mental models. He is currently in the process of designing screens for our project and wanted to know whether he should a) go with his belief that positive action button should be on the right and the negative/neutral on the left (like Apple's dialogs) or b) follow the Windows convention of positive on the left and negative on the right (ok and cancel buttons).

Like many of us he has a fundamental belief that the Windows model is wrong. As much as I wanted to advise to use the 'correct' approach the problem with this is that the majority of users are Windows users and yes people can unlearn and re-train but when we are dealing with a client who may be adverse to such matters it is best to provide them with a screen that depicts *their* mental model as opposed to the correct mental model.

The best approach by far, in this matter would be to mock up both versions and get them to pick so that the onus and ownership belongs to them rather than us. However, this may not be possible with the time constraints. The impression that he has given me is that he is likely to bit the bullet on this particular issue and go with the Windows approach! 

End of 2nd Iteration E1

The whole point of iterative development is that it a continuous cycle of progress, both in terms of work and skill development so as expected this iteration has been a lot better than the last and we have improved based on the outcome of the last meeting and actions taken. Having a RUP methodology with an Agile flavour means that  the teams are working much more closely and collaboratively. Even though this is the case sometimes disparity can still be a problem where everyone is working on their own little patch. I’ve found the best way to remedy this is to keep a continuous dialog open until the knowledge sharing reaches an equilibrium and you are both on the same page. Pair programming/working also helps with this. Sometimes this approach can be a bit intimidating as it might be perceived that you are disturbing said persons or that you don’t have a full grasp of your tasks but the outcome of completing your task competently far outweighs any hesitancy around communication/asking.
For last week's retrospective meeting I have put the comments from the 3 points:
1)  What we did well?
2) What we could do better?
3) What we would like to start doing?
up on the white board.

Although we did not manage to get all the stories that we had anticipated into the done column, this iteration was much better in terms of burn down and everyone managed to account their time as you can see from the chart.

One of the big obstacles that we have had is in terms of abstraction and detail, so the leads came up with an idea of ‘brown papering’  starting off at the higher abstract level and drilling down into the detail. This was started mid last week so is pretty much ongoing.

TriBot Test Code

I've writtten some test code for the Tribot (uploaded to the repository). It's just basic test code in a class with a main method, nothing special at the moment.

For the Ultrasonic sensor we have an output to the screen based on readings taken from the surrounding environment.

For the Touch sensor, whilst the sensor is pressed again an output to the screen and same for the colour sensor whilst a reading can be detected an output is displayed to the LCD screen on the brick.

For the motors, the results are physically visible so it's a combination of forward and backwards movement with output to the screen.

The touch, light and motors work fine but I'm a bit worried as the Ultrasonic sensor doesn't seem to be doing much. Maybe it's a coding or LeJos problem. I might use the mindstorms software to test it. I hope it's not faulty  :( I don't want to fork out £22 for a new one.

Tribot

I spent 5 hours yesterday building the tribot (picture below). It was pretty fiddly to do, there are 2 wheels at the front and 1 small one at the back. As well as that this robot has 3 sensors on it too. The touch sensor, which has a mechanism build around it and a colour sensor on top both of which can be used for object detection. I have also put a sonar sensor on top (looks a bit Johnny 5ish ;-)).

It looks pretty cool, but I'm not entirely convinced about the stability of this bot. I liked the robustness of the old 4 wheel chassis I made (but that was very basic and lacking functionality other than movement) however I haven't programmed the robot as of yet nor tested it so we shall see (I will keep you posted).