I have been banging on about users being savvied up on UX and Usability for years now. I am a firm believer that as a developer you should have at least some basic knowledge/experience in this area.
This article sums those points up nicely.
I also like this bit: "But sometimes you just need to cut the middleman and talk directly to the source" and I think Agile takes care of a lot of that.
Showing posts with label Agile. Show all posts
Showing posts with label Agile. Show all posts
Friday, 24 December 2010
Tuesday, 25 May 2010
How to Be Un-Agile
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!
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!
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
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, 18 December 2009
Daily Update Meeting - remotely
As Wadz is ill I facilitated the GIMS daily progress meeting. This was a good experience as it is crucial to ensure that order is maintained and everyone sticks to the 3 questions and answers as concisely as possible, otherwise chaos will ensue.
Also, due to being close to Christmas a lot of the guys are off, so the rightshore guys who were on site moved the tasks along and calculated burn down and burn up. This is also very good exposure and experience for them as they will have to take these skills back home with them and ensure that we work in this manner when the project moves into the next phase.
So all in all it was pretty good. It would be so much better if we had a web cam though.
Also, due to being close to Christmas a lot of the guys are off, so the rightshore guys who were on site moved the tasks along and calculated burn down and burn up. This is also very good exposure and experience for them as they will have to take these skills back home with them and ensure that we work in this manner when the project moves into the next phase.
So all in all it was pretty good. It would be so much better if we had a web cam though.
Thursday, 17 December 2009
Retrospective
So we had our retrospective today, which was pretty good (I even got to facilitate). Four actions were determined and although we didn't meet our target the general consensus was that this way of working was definitely very good. People felt that they gelled better with the team and had a better understanding of where everyone fits in.
Tomorrow is our last virtual progress meeting then the new iteration begins in the new year. Bring on the new year :D
Tomorrow is our last virtual progress meeting then the new iteration begins in the new year. Bring on the new year :D
Friday, 11 December 2009
Virtual Progress Meeting Over GIMS
So since a lot of us work from our home/base location on the Friday and every day we have a 15 minute progress meeting to highlight what we have been doing and any issues we decided to use GIMS (Group Instant Messaging Service, essentially a work MSN).
So this includes a 9 people conversation, obviously this can pose issues and can get very 'messy' so we had a chair who posed 3 questions:
1) What work did you do yesterday?
2) What are you working on today?
3) Any blockers.
Each person was asked in turn, type the answer, move onto the next person.
We had intended to broadcast the board via webcam (the locals in the office would have done this) but unfortunately our work's network has blocked the webcam functionality which is a shame.
The meeting worked pretty well albeit a techy glitch at the beginning and if we can use VOIP and webcams it will be even better. I think using this approach today and hence forth on Friday's will be a good way of demonstrating that we can do this over a distributed environment (especially if we are to send work offshore).
The only disadvantages are if there are technical problems, the fact that we cannot at the moment use webcams and the meeting takes longer than 15 minutes as people are typing. Other than that it has worked pretty well as a pilot.
Since the webcam option is blocked, I have requested that the local guys take a pic of the board and the burn down chart and send it across to us so we can see the progress based on today's meeting.
It's been a lot better than I had anticipated.
So this includes a 9 people conversation, obviously this can pose issues and can get very 'messy' so we had a chair who posed 3 questions:
1) What work did you do yesterday?
2) What are you working on today?
3) Any blockers.
Each person was asked in turn, type the answer, move onto the next person.
We had intended to broadcast the board via webcam (the locals in the office would have done this) but unfortunately our work's network has blocked the webcam functionality which is a shame.
The meeting worked pretty well albeit a techy glitch at the beginning and if we can use VOIP and webcams it will be even better. I think using this approach today and hence forth on Friday's will be a good way of demonstrating that we can do this over a distributed environment (especially if we are to send work offshore).
The only disadvantages are if there are technical problems, the fact that we cannot at the moment use webcams and the meeting takes longer than 15 minutes as people are typing. Other than that it has worked pretty well as a pilot.
Since the webcam option is blocked, I have requested that the local guys take a pic of the board and the burn down chart and send it across to us so we can see the progress based on today's meeting.
It's been a lot better than I had anticipated.
Thursday, 10 December 2009
Daily Progress Meeting
So we have just had our daily progress meeting and (as it's the first week) we seem to be burning up. It turns out that we hadn't identified all the tasks on Monday so they have accumulated over the course of the week. This isn't necessarily a bad thing and it is the first week using an Agile approach on a RUP project for plumbing tasks.
Although we burnt up and at this stage that isn't necessarily a bad thing, we are much more focussed and the people new to the process are both getting into and enjoying it.
Tomorrow (as us non-locals are travelling home tonight) we will be attempting a progress meeting via GIMS. This will be a good test to see whether this approach is sustainable over a distributed project environment.
Tuesday, 8 December 2009
New Project - Agile Approach
We have started introducing Agile working practices on our project as of yesterday. A step in the right direction :D This is the Agile task 'board' (brown paper) in our 'War Room' :D First stand up meeting today, those not familiar with the concept seem to be ok with it so far :) Let's just hope we can make this as successful as possible :-)
Friday, 3 April 2009
Wednesday, 1 April 2009
End of Sprint
So we have finished the sprint for this release. The code freeze was last night and the demo this morning. The client were satisfied and the demo was short and sweet. This sprint hasn't been very heavy going, as there hasn't been any new functionality introduced just enhancements of exisiting functionality.
Two recurring issues in this sprint have been:
1) The client constantly chopping and changing what they want and leaving it to the last minute to request these changes.
2) Dev's digressing from the requirements set out in the story and trying to do 'clever' things.
Although 1) might seem like the changes are minor, the issues are more around the bigger picture and the impact that it will have on making the change. This includes amending test scripts, deploying to the sprint test environment, re-testing, fixing any bugs that may arise and assessing any impacts on existing fucntionality. Now, at the beginning of a sprint it's easier to be a little flexible, after all we are Agile but there's a huge difference between flexibility and completely bending over backwards and becoming a bunch of yes people. It should never be the latter!
For 2) Although it is nice to have innovation, when you are working for a client who has specified what they want, if you don't meet that then the innovation means nothing. I witnessed the client actually tell a dev so you've done x, y and z, that's great but not what I wanted. I wanted you to make a minor change to a and that's it. Please can you roll back x,y and z to what it was doing previously! Now this reflects badly on the dev and the sprint team. I've noticed in this sprint, the dev getting rather carried away and digressing away from what they were asked to do without assessing and considering the impact to the rest of the team and the functionality just built! This is very risky and should not really be happening, especially on the day before the demo or even after the demo!
We should be having our retrospective at some point at the end of this week or early next week. I will be raising these issues then!
Two recurring issues in this sprint have been:
1) The client constantly chopping and changing what they want and leaving it to the last minute to request these changes.
2) Dev's digressing from the requirements set out in the story and trying to do 'clever' things.
Although 1) might seem like the changes are minor, the issues are more around the bigger picture and the impact that it will have on making the change. This includes amending test scripts, deploying to the sprint test environment, re-testing, fixing any bugs that may arise and assessing any impacts on existing fucntionality. Now, at the beginning of a sprint it's easier to be a little flexible, after all we are Agile but there's a huge difference between flexibility and completely bending over backwards and becoming a bunch of yes people. It should never be the latter!
For 2) Although it is nice to have innovation, when you are working for a client who has specified what they want, if you don't meet that then the innovation means nothing. I witnessed the client actually tell a dev so you've done x, y and z, that's great but not what I wanted. I wanted you to make a minor change to a and that's it. Please can you roll back x,y and z to what it was doing previously! Now this reflects badly on the dev and the sprint team. I've noticed in this sprint, the dev getting rather carried away and digressing away from what they were asked to do without assessing and considering the impact to the rest of the team and the functionality just built! This is very risky and should not really be happening, especially on the day before the demo or even after the demo!
We should be having our retrospective at some point at the end of this week or early next week. I will be raising these issues then!
Sunday, 22 March 2009
Sprinting Again
So, once again we are sprinting once again for the next release. This sprint will hopefully not be too taxing, however already we have encountered some frustrating problems.
First of all a defect raised in UAT 6 weeks after the release went in, meant that our planning session was held up until Thursday.
Once in the planning session, there were people in our team's session who weren't part of our team having an input on our stories. I found this rather unnecessary and frustrating.
It would be better that only the team and other required people are present in the planning session and not just anyone and everyone!
Hopefully the sprint will go well :) On the plus side, I managed to put 2 stories into sprint test before I left on Friday. Yay :)
First of all a defect raised in UAT 6 weeks after the release went in, meant that our planning session was held up until Thursday.
Once in the planning session, there were people in our team's session who weren't part of our team having an input on our stories. I found this rather unnecessary and frustrating.
It would be better that only the team and other required people are present in the planning session and not just anyone and everyone!
Hopefully the sprint will go well :) On the plus side, I managed to put 2 stories into sprint test before I left on Friday. Yay :)
Friday, 20 February 2009
Demo & Retrospective
Demo
Even though it was a late night on Wednesday, we managed to get all our stories 'done' ready for the demo the next day. I was told by the scrum masters that the demo with the client went very well. The only disappointing thing is that apart from the Scrum masters and the BAs and other management types outside of the sprint teams.
I raised this during the last retrospective and an item was actioned for this. However, nothing came about of this. The scrum masters decided that the team members should go to the dry run prior to the sprint demo. I was one of those who went along, it was nice to see our work up there and as one of the client is a part of our sprint team, it was re-assuring to see him presenting and selling the end product so well.
The only issue is that the sprint teams should have the option of going to a client demo whether they choose to or not is up to them. Ultimately it is the sprint team who have produced the work and the client should have exposure to this, it feels a bit like they're being shielded from the sprint team. I know that management have their reasons and that 'rooms are too small' etc, even if the sprint team were there as observers it would be a good learning experience for the team too, especially those that have not been involved in agile development before.
Lastly, it is one of the practices of Agile, that team members should be present at demos! I mean after all, we only did the work!!!
Retrospective
So we had our 2 hour retrospective meeting (which went over the 2 hours) and a lot of discussion came about.
The approach that was taken was that prior to the meeting our team (on flipchart paper) wrote down the positive and negative elements of the sprint.
In the meeting we created an agenda which was:
1) What went well
2) Could do better
3) Like to start doing
4)Actions
5) AOB
We went through the flipchart list, discussed them and then came up with an action list.
What has happened in the past is that action has not been taken on the action list (see what I did there). That was another point that was raised, so let's hope this time round that something comes of the actions.
Even though it was a late night on Wednesday, we managed to get all our stories 'done' ready for the demo the next day. I was told by the scrum masters that the demo with the client went very well. The only disappointing thing is that apart from the Scrum masters and the BAs and other management types outside of the sprint teams.
I raised this during the last retrospective and an item was actioned for this. However, nothing came about of this. The scrum masters decided that the team members should go to the dry run prior to the sprint demo. I was one of those who went along, it was nice to see our work up there and as one of the client is a part of our sprint team, it was re-assuring to see him presenting and selling the end product so well.
The only issue is that the sprint teams should have the option of going to a client demo whether they choose to or not is up to them. Ultimately it is the sprint team who have produced the work and the client should have exposure to this, it feels a bit like they're being shielded from the sprint team. I know that management have their reasons and that 'rooms are too small' etc, even if the sprint team were there as observers it would be a good learning experience for the team too, especially those that have not been involved in agile development before.
Lastly, it is one of the practices of Agile, that team members should be present at demos! I mean after all, we only did the work!!!
Retrospective
So we had our 2 hour retrospective meeting (which went over the 2 hours) and a lot of discussion came about.
The approach that was taken was that prior to the meeting our team (on flipchart paper) wrote down the positive and negative elements of the sprint.
In the meeting we created an agenda which was:
1) What went well
2) Could do better
3) Like to start doing
4)Actions
5) AOB
We went through the flipchart list, discussed them and then came up with an action list.
What has happened in the past is that action has not been taken on the action list (see what I did there). That was another point that was raised, so let's hope this time round that something comes of the actions.
Thursday, 19 February 2009
This is what happens when the system goes down...
...between 5.30-8.30 pm on a Wednesday night (the day before the demo and one last script to System Test).
(Artists: Femz & Wadz)
(Artists: Femz & Wadz)
Tuesday, 17 February 2009
Multi-Functional Teams
As mentioned in one of my previous posts, sprint teams are meant to consist of team members who are multi functional. Although, we tend to have defined roles (i.e I'm a developer and person x is a tester, person y a business analyst etc) the whole multi-functional teams has been put to the test this week.
In the past BAs have taken on testing roles especially towards the end of a sprint, however this time round we've managed to finish all the development and the bottle neck is at the testing end. So myself, and the rest of the developers have put on our testing hats and started testing (obviously not code that we have written and the test conditions have been written by the testers).
It's not so bad as long as the test conditions are written well and it's a case of executing them and raising any defects. At the end of the day, the ultimate goal is to get the stories into 'done' and points on the board, so it's much more beneficial to help out in this way then to sit there twiddling our thumbs.
In the past BAs have taken on testing roles especially towards the end of a sprint, however this time round we've managed to finish all the development and the bottle neck is at the testing end. So myself, and the rest of the developers have put on our testing hats and started testing (obviously not code that we have written and the test conditions have been written by the testers).
It's not so bad as long as the test conditions are written well and it's a case of executing them and raising any defects. At the end of the day, the ultimate goal is to get the stories into 'done' and points on the board, so it's much more beneficial to help out in this way then to sit there twiddling our thumbs.
Running a Stand Up Meeting
So yesterday, I was given the opportunity to run a stand up meeting which was pretty cool. I jokingly suggested it to the scrum master that if he 'wanted me to run it' and he agreed.
It was an interesting experience, a little bit daunting being up there however the fact that it was an informal environment and we have done many stand ups in the past few weeks meant it wasn't as bad as I thought it would be.
Being up there put me out of my comfort zone which was a good learning experience. I think it's a good idea to rotate around the team to run the stand up meetings.
It was an interesting experience, a little bit daunting being up there however the fact that it was an informal environment and we have done many stand ups in the past few weeks meant it wasn't as bad as I thought it would be.
Being up there put me out of my comfort zone which was a good learning experience. I think it's a good idea to rotate around the team to run the stand up meetings.
Tuesday, 10 February 2009
Stand Up Meetings
During our stand up meetings we have been 'mixing it up' a little. Initially it started out with going round the team members and each one stating what they have been working on yesterday, what they are working on today and providing estimates of tasks allocated to them.
Lately we have started doing our stand up meetings based upon the story, so we go through each story and discuss the progress. I find this a far more effective stand up as a) everyone should be working on a task and therefore everyone gets a chance to speak b) the progress of each story is much more obvious c) there is less digression during the meeting and d) it re-aligns focus.
I think the latter process works very well, that's not to discard the former though as there are times when the former is more effective (especially at the beginning of a sprint).
Lately we have started doing our stand up meetings based upon the story, so we go through each story and discuss the progress. I find this a far more effective stand up as a) everyone should be working on a task and therefore everyone gets a chance to speak b) the progress of each story is much more obvious c) there is less digression during the meeting and d) it re-aligns focus.
I think the latter process works very well, that's not to discard the former though as there are times when the former is more effective (especially at the beginning of a sprint).
Sunday, 8 February 2009
Agile Methodology
The first time I heard about the Agile Methodology was when I was working on my previous project. We were using RUP, however being a large scale project things weren't quite going according to plan.
A few of our senior software engineers got together and decided to take the Agile approach. It worked very well for us and we pulled ourselves out of the rut and delivered on time, which the client were very happy about.
The basic gist of Agile is collaborative working. The following exist in Agile development:
Generally there is a business problem that needs to be solved through the development of software and the person responsible for this problem is the product owner, who has a product backlog of business problems.
A team or multiple teams known as sprint teams are formed for this purpose. They generally consist of developers, testers, business analysts and a scrum master. Sometimes (but not commonly the product owner or the product owner proxy). The team is a self organising, multi tasking team. The team will work on the software in sprints. A sprint is a fixed amount of time (between 2-6 weeks).
At the beginning of each sprint the team is involved in a planning session where they determine the velocity that they will work at. During the planning session, the team take the backlog and prioritise what needs to go into that sprint. They then divide these up into stories and assign points based upon the velocity. The points are assigned using planning poker, and team members have to estimate individually, then once every team member has indicated their estimate a consensus is reached based upon discussion.
After the planning session the team work on the tasks (these are the stories broken down into smaller components) in the sprint and every day a 15 minute daily meeting occurs where they discuss their progress amongst other team members.
There is no outside interference when a sprint team is working. At the end of the sprint there is generally a demo to demonstrate what was achieved and a retrospective meeting held for lessons learnt.
This is the basic gist of Agile development. For details please visit the link above or read Scrum and XP from the Trenches.
On my previous project I worked alongside a sprint team, mostly working on support work for the teams so I wasn't really involved in the core development for the sprint team.
When I joined my current project, we were encountering similar problems to those of my last project. There were a few of us from our previous project who joined the current project. Once again a couple of the senior guys suggested Agile development.
Once again this worked very well and we were able to deliver Release 1. For Release 1 our business analysts were the product owners. Once again, I wasn't involved in the core development within a sprint team.
My first real experience with Agile development was about a month ago when we started Release 2. I had expressed an interest in being involved with core development work and was finally provided with this opportunity.
This time round the product owner was the client, and their proxies are actually a apart of our sprint teams. I hadn't really been to a planning session before and it was a very interesting experience. During my first planning session, I found it very hard to determine how to allocate points to the stories as I'd never worked on a story (or core development before). We had time boxed the planning session to 3 hours, however it overran due to lengthy discussion about the stories.
We started the sprint and I must say, I found Scrum to be a very effective way of working. The teams work very closely together and having all the developers, testers, business analysts and the client(as the proxy) together meant that the team was very productive. I found that having stories and allocated time for tasks meant that I focussed much more on achieving my goal. Also with everyone sitting together the communication and turn around was excellent.
Including a client member on the team also means that we get a much quicker response back from the business and that they are more sold into the process and ensuring the success of the team as they are also liable.
The retrospective was very interesting also, we were given sheets of paper to write issues we encountered during the sprint and how we could resolve them for the next sprint. The scrum masters then went through the common themes and discussed them. Recurring themes were given higher priorities to over come for the next sprint. Basically, everyone got to have a say.
Our second (and final) sprint for this release started on Monday. I was better equipped for the planning session and able to make sound judgements on point allocations. So far the week has gone well and we seem to be on track.
I will keep posting our progress as the weeks progress :)
A few of our senior software engineers got together and decided to take the Agile approach. It worked very well for us and we pulled ourselves out of the rut and delivered on time, which the client were very happy about.
The basic gist of Agile is collaborative working. The following exist in Agile development:
- Product Owner
- Product backlog
- Sprint team
- Backlog
- Stories
- Points
- Tasks
- Burn down chart
- Velocity
- Planning Session
- Stand up meetings
- Retrospective
Generally there is a business problem that needs to be solved through the development of software and the person responsible for this problem is the product owner, who has a product backlog of business problems.
A team or multiple teams known as sprint teams are formed for this purpose. They generally consist of developers, testers, business analysts and a scrum master. Sometimes (but not commonly the product owner or the product owner proxy). The team is a self organising, multi tasking team. The team will work on the software in sprints. A sprint is a fixed amount of time (between 2-6 weeks).
At the beginning of each sprint the team is involved in a planning session where they determine the velocity that they will work at. During the planning session, the team take the backlog and prioritise what needs to go into that sprint. They then divide these up into stories and assign points based upon the velocity. The points are assigned using planning poker, and team members have to estimate individually, then once every team member has indicated their estimate a consensus is reached based upon discussion.
After the planning session the team work on the tasks (these are the stories broken down into smaller components) in the sprint and every day a 15 minute daily meeting occurs where they discuss their progress amongst other team members.
There is no outside interference when a sprint team is working. At the end of the sprint there is generally a demo to demonstrate what was achieved and a retrospective meeting held for lessons learnt.
This is the basic gist of Agile development. For details please visit the link above or read Scrum and XP from the Trenches.
On my previous project I worked alongside a sprint team, mostly working on support work for the teams so I wasn't really involved in the core development for the sprint team.
When I joined my current project, we were encountering similar problems to those of my last project. There were a few of us from our previous project who joined the current project. Once again a couple of the senior guys suggested Agile development.
Once again this worked very well and we were able to deliver Release 1. For Release 1 our business analysts were the product owners. Once again, I wasn't involved in the core development within a sprint team.
My first real experience with Agile development was about a month ago when we started Release 2. I had expressed an interest in being involved with core development work and was finally provided with this opportunity.
This time round the product owner was the client, and their proxies are actually a apart of our sprint teams. I hadn't really been to a planning session before and it was a very interesting experience. During my first planning session, I found it very hard to determine how to allocate points to the stories as I'd never worked on a story (or core development before). We had time boxed the planning session to 3 hours, however it overran due to lengthy discussion about the stories.
We started the sprint and I must say, I found Scrum to be a very effective way of working. The teams work very closely together and having all the developers, testers, business analysts and the client(as the proxy) together meant that the team was very productive. I found that having stories and allocated time for tasks meant that I focussed much more on achieving my goal. Also with everyone sitting together the communication and turn around was excellent.
Including a client member on the team also means that we get a much quicker response back from the business and that they are more sold into the process and ensuring the success of the team as they are also liable.
The retrospective was very interesting also, we were given sheets of paper to write issues we encountered during the sprint and how we could resolve them for the next sprint. The scrum masters then went through the common themes and discussed them. Recurring themes were given higher priorities to over come for the next sprint. Basically, everyone got to have a say.
Our second (and final) sprint for this release started on Monday. I was better equipped for the planning session and able to make sound judgements on point allocations. So far the week has gone well and we seem to be on track.
I will keep posting our progress as the weeks progress :)
Subscribe to:
Posts (Atom)