1) Insist your team provide you with a weekly update/report/metrics even though all the metrics are readily available and easily accessible.
2) Insist on using a vast array of tools, the more electronic the better
3) Constantly insist on eradicating the board without really using it or giving it a chance.
4) Don't relate your daily update to any of the tasks on the board
5) Don't discuss any of the burn down or update your burn down after the meeting
6) Do your own thing without putting an unplanned task on the board
7) Keep the virtual standups 3 minutes long only specifying what you did without having any kind of virtual representation of the board where you have your stories/tasks in front of you that you can discuss.
8) Add random ad-hoc people to the team mid sprint without re-jigging velocity
9) Don't concern yourself with story points they are useless anyway
10) Try and equate story points to man days
11) Don't concern yourself with velocity etc at the end of the sprint either!
Tuesday, 25 May 2010
Saturday, 1 May 2010
New Project, Another Agile Approach
So I've started another project and once again we will have an Agile approach encompassed within our software development approach. I really like working on Agile projects, so hopefully there will be more fun to had.
Significance of the Board
One of the great things about having a physical white board is that it provides social interaction. Everyone gathers around the board and because they are standing up the meetings are likely to be prompt and to the point as opposed to where everyone is sitting and gathered around a screen.
The looming presence of the board, located by the team ensures that stand up meetings are held every day and times adhered too. The fact that it is there, highly visible will prompt at least one or two team members to ensure these take place.
High visibility of the board means that anyone (management, client, other colleagues, other sprint teams etc) should be able to walk up to the board and track the progress of the team without interrupting the team or scheduling lengthy stand up meetings. High visibility means that accountability is more obvious as the stories and tasks are up there along with the owner of the tasks. This means team members are more likely to ensure the success of the sprint as they wouldn't want to let the team down.
Distributed Approach
As feature teams will be located across various locations it is imperative that stand up meetings continue on the days where the teams cannot be situated together. An approach needs to be taken to ensure that an environment as similar as being on site is created. There needs to be a board in some way, shape or form. This could be an electronic board or a real board with a web cam being projected at the board. If the board is electronic then the simplicty of the physical board needs to be retained. It is even more essential that this happens in the distirbuted approach because team members will be a) dialling in b) providing an update c) trying to update post its etc based on their update d) calculating the burn down. This will prove even more complex over a virtual meeting and as multi tasking is required the process needs to be as simple as possible. Even if that means having a basic representation (i.e powerpoint, paint) to capture the teams progress and then added to the 'official' system later.
So why are story points so significant in agile? A lot of the time people tend to misunderstand the purpose of story points. Story points are there to determine the complexity of a story. For instance everyone knows that building a shed is easier than building a house and that building Westminster is much more complex than building a house. We cannot indicate how long each would take to build without breaking it down into smaller tasks. Story points serve the same purpose, the are there to determine the complexity and then tasks relating to the story can then be equated to man days.
As humans we all like to quantify. In general our entire lives are quantified by numbers (how old are you, how much do you weight, how big is the engine in your car). Story points are another way of quantifying the complexity of functionality. Why do we need to do this? The reason behind this is that it doesn't matter how much experience you have, or what grade you are a story size is (for example) 5 regardless. Story points also help determine the velocity of the team and a sustainable pace that they are able to work at. Velocity for future sprints is determined by the story points they have been able to complete in prior sprints.
Finally there is a psychological element behind having story points. There is a great feeling of satisfaction when a story is 'done' and can be marked off on the burn down chart. Story points and getting them into 'done' can also instill healthy competition amongst a project with multiple sprint teams.
Conclusion
Working on Agile projects is great fun. The hard part is getting everyone on board and changing the mindset of those who have not worked in this way before. Traditional methods at a work place (whether that is in IT or other areas) are very hierarchial. The decisions are made by management or higher ups and then filtered down. Those on the ground 'do as they are told'. That's not to say anyone is at fault here, it's just the way it has been and still is. Even society operates in a hierarchial manner.
The key message that needs to be absorbed by those working on Agile projects, for the team is that you are in control and you need to take that control and embrace it. You are the people making the decisions and determining the success of the sprint and in the bigger picture the project. With that comes responisbility, the onus is on you to make it work. If the standup meeting aren't happening, speak up. If something is going wrong or troubling you, share it with the team, do something about it and move on. The key is to take the control and be pro-active. Many people are afraid of this because they are not used to being responsible.
On the other hand, management are afraid of relinquishing control (which is sort of understandable). You need to trust your team, when you trust others without micro managing them and constantly badgering them they are more likely to do a good job because they don't want to let you down. All the metrics you need are up on the board and if you have questions or are feeling troubled you can discuss it with the team. Once you reap the benefits of Agile you will realise how powerful it can be.
Finally, I always see Agile as a form of (Software Development) communism. Everyone pitching in and doing their share for a common goal and every team member pitches in with the decision making.
Significance of the Board
One of the great things about having a physical white board is that it provides social interaction. Everyone gathers around the board and because they are standing up the meetings are likely to be prompt and to the point as opposed to where everyone is sitting and gathered around a screen.
The looming presence of the board, located by the team ensures that stand up meetings are held every day and times adhered too. The fact that it is there, highly visible will prompt at least one or two team members to ensure these take place.
High visibility of the board means that anyone (management, client, other colleagues, other sprint teams etc) should be able to walk up to the board and track the progress of the team without interrupting the team or scheduling lengthy stand up meetings. High visibility means that accountability is more obvious as the stories and tasks are up there along with the owner of the tasks. This means team members are more likely to ensure the success of the sprint as they wouldn't want to let the team down.
Distributed Approach
As feature teams will be located across various locations it is imperative that stand up meetings continue on the days where the teams cannot be situated together. An approach needs to be taken to ensure that an environment as similar as being on site is created. There needs to be a board in some way, shape or form. This could be an electronic board or a real board with a web cam being projected at the board. If the board is electronic then the simplicty of the physical board needs to be retained. It is even more essential that this happens in the distirbuted approach because team members will be a) dialling in b) providing an update c) trying to update post its etc based on their update d) calculating the burn down. This will prove even more complex over a virtual meeting and as multi tasking is required the process needs to be as simple as possible. Even if that means having a basic representation (i.e powerpoint, paint) to capture the teams progress and then added to the 'official' system later.
So why are story points so significant in agile? A lot of the time people tend to misunderstand the purpose of story points. Story points are there to determine the complexity of a story. For instance everyone knows that building a shed is easier than building a house and that building Westminster is much more complex than building a house. We cannot indicate how long each would take to build without breaking it down into smaller tasks. Story points serve the same purpose, the are there to determine the complexity and then tasks relating to the story can then be equated to man days.
As humans we all like to quantify. In general our entire lives are quantified by numbers (how old are you, how much do you weight, how big is the engine in your car). Story points are another way of quantifying the complexity of functionality. Why do we need to do this? The reason behind this is that it doesn't matter how much experience you have, or what grade you are a story size is (for example) 5 regardless. Story points also help determine the velocity of the team and a sustainable pace that they are able to work at. Velocity for future sprints is determined by the story points they have been able to complete in prior sprints.
Finally there is a psychological element behind having story points. There is a great feeling of satisfaction when a story is 'done' and can be marked off on the burn down chart. Story points and getting them into 'done' can also instill healthy competition amongst a project with multiple sprint teams.
Conclusion
Working on Agile projects is great fun. The hard part is getting everyone on board and changing the mindset of those who have not worked in this way before. Traditional methods at a work place (whether that is in IT or other areas) are very hierarchial. The decisions are made by management or higher ups and then filtered down. Those on the ground 'do as they are told'. That's not to say anyone is at fault here, it's just the way it has been and still is. Even society operates in a hierarchial manner.
The key message that needs to be absorbed by those working on Agile projects, for the team is that you are in control and you need to take that control and embrace it. You are the people making the decisions and determining the success of the sprint and in the bigger picture the project. With that comes responisbility, the onus is on you to make it work. If the standup meeting aren't happening, speak up. If something is going wrong or troubling you, share it with the team, do something about it and move on. The key is to take the control and be pro-active. Many people are afraid of this because they are not used to being responsible.
On the other hand, management are afraid of relinquishing control (which is sort of understandable). You need to trust your team, when you trust others without micro managing them and constantly badgering them they are more likely to do a good job because they don't want to let you down. All the metrics you need are up on the board and if you have questions or are feeling troubled you can discuss it with the team. Once you reap the benefits of Agile you will realise how powerful it can be.
Finally, I always see Agile as a form of (Software Development) communism. Everyone pitching in and doing their share for a common goal and every team member pitches in with the decision making.
Wednesday, 27 January 2010
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:
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
Monday, 25 January 2010
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!
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.
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.
Friday, 1 January 2010
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.
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).
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).
Subscribe to:
Posts (Atom)