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.
Subscribe to:
Posts (Atom)