Continuing from my previous post where I discussed the approach we used during my first experience working on a distributed delivery project, I shall now discuss some of the tools that helped us with the same.
Tools used
Firebug plug-in for Firefox - This tool helped me immensely, especially when I was analyzing the re-design of the user interface (UI) design for the application. Since the analysis involved having new logos, contrasting color backgrounds, navigation & menu bars, tabs etc., I needed a tool which could help me do minor modifications to the application and demonstrate it to the client before we could finalize a design. Though I had created many prototypes for the same, we still needed to try various options with colors, spacing between tabs and placement of links/buttons amongst others. Considering the distributed nature of the project, I basically needed a tool which was simple enough for me to use and also do some minor modifications to the code and not having to rely always on the developers who were in Melbourne (it would have also delayed the analysis). I organized a workshop and invited all major stakeholders to discuss the new UI design for the application. Using the prototypes that I had created, we finalized the design layout and then using firebug, we could finalize more accurate details like the actual color codes to be used and the number of pixels between tabs (for spacing) etc.. This was of great help to the developers as it removed any ambiguity (which is of major concern when you are developing user interfaces). Thus the development and the actual sign-off process went ahead very smoothly. The client was very pleased with the final outcome.
Mingle – Used to capture all project related information within one single location which could then be accessed & updated by anyone involved with the project (including the clients). It was our virtual story wall which helped us to track the progress of the stories in real time. It was also used to record the environment details, team contact details, progress reporting, meeting minutes etc.
Another unique use of Mingle was using it for doing our iteration and project retrospectives. We set-up a project within Mingle just for Retrospectives and the team (both from Melbourne and Perth) used it to record their feedback within the various categories set-up within Mingle. We then discussed individual feedbacks over the phone (using a teleconference facility).
Video Conferencing – We used this facility mainly during showcases (at the end of each iteration) and important analysis sessions when we needed the involvement of the Melbourne staff (both client and TW). This is a very handy communication tool to use for distributed projects.
Tuesday, May 12, 2009
My first distributed delivery gig!
I just rolled off from my first distributed delivery gig with Thought works. I had a great time working with the team and it was also a great learning experience for me.
The client had its head quarters in Perth (they also had another office in Melbourne as well) and thus I was sent there to help out with some analysis work. The delivery team consisted of a total of 7 members of which a team of 5 (4 developers and one tester) were based in our TW’s Melbourne office and 2 of us (I and another Thought Worker who played the role of an Iteration Manager) based in Perth.
In this blog, I shall mainly discuss the approach that we followed to successfully deliver the first phase of the project.
Our approach
Daily stand-up meetings – We had 2 stand-ups every day. The first one (held every morning) was an internal stand-up meeting and then one in the afternoon involving the whole team (through a teleconference facility between Perth & Melbourne)
Analysis sessions – Almost every day, I used to organize at least 2 analysis sessions. The morning session was used mainly for story analysis and I had a story sign-off session in the afternoon.
Workshops - I used to conduct a workshop's only when I had to get a broad consensus from the clients. I faced such a situation when finalizing the new design for the application. For this, I could not just rely on the Subject Matter Expert assigned for that Iteration as it affected all the users. Thus, I had to get all the main stakeholders into the same room and conduct a workshop using 'hi-fi' design prototypes and demonstrations of the application(using firebug plug-in to modify the code on the go). This helped me to gain consensus amongst all users and also finalize the design.
Story kick-offs & hand-over – Before the developers picked up any story for development, we used to have a kick-off meeting where the developers would call me up to discuss the same. Apart from the implicit benefit of gaining more knowledge of the requirement, it also used to provide me with a chance to check if the developers had picked the right story according to the priority.
Triage – We used to have a weekly story prioritization session (which we called as Triage). Being an Agile project, this is a key mechanism to deliver value to the customer. Re-prioritization on a regular basis helps provide the best value for money to the clients.
Iteration kick-offs – We had a 2 week iteration and at the beginning of each iteration, we used to have a kick-off session in which we discussed the stories which were currently being developed and then the analysts would discuss details for those stories which were prioritized highest within the backlog and thus ready to be picked up for that particular iteration.
Showcases & Walk throughs – At the end of each iteration, we used to conduct a showcase where we demonstrated the latest version of the application being developed (usually the Subject Matter Expert from the client demonstrated most of the functionality which were developed within that iteration – this gave them a feeling of ownership). Each iteration, we also conducted walkthroughs which was a more hands on approach for the users to test the latest additions to the application. This involved the users actually logging into the application and trying out individual functionalities. I think that this approach is a fantastic ‘Change Management’ initiative and helps get an acceptance from the actual users even before the application has been deployed.
In my next blog, I shall discuss some of the tools that helped me dealing with the distributed nature of the project.
The client had its head quarters in Perth (they also had another office in Melbourne as well) and thus I was sent there to help out with some analysis work. The delivery team consisted of a total of 7 members of which a team of 5 (4 developers and one tester) were based in our TW’s Melbourne office and 2 of us (I and another Thought Worker who played the role of an Iteration Manager) based in Perth.
In this blog, I shall mainly discuss the approach that we followed to successfully deliver the first phase of the project.
Our approach
Daily stand-up meetings – We had 2 stand-ups every day. The first one (held every morning) was an internal stand-up meeting and then one in the afternoon involving the whole team (through a teleconference facility between Perth & Melbourne)
Analysis sessions – Almost every day, I used to organize at least 2 analysis sessions. The morning session was used mainly for story analysis and I had a story sign-off session in the afternoon.
Workshops - I used to conduct a workshop's only when I had to get a broad consensus from the clients. I faced such a situation when finalizing the new design for the application. For this, I could not just rely on the Subject Matter Expert assigned for that Iteration as it affected all the users. Thus, I had to get all the main stakeholders into the same room and conduct a workshop using 'hi-fi' design prototypes and demonstrations of the application(using firebug plug-in to modify the code on the go). This helped me to gain consensus amongst all users and also finalize the design.
Story kick-offs & hand-over – Before the developers picked up any story for development, we used to have a kick-off meeting where the developers would call me up to discuss the same. Apart from the implicit benefit of gaining more knowledge of the requirement, it also used to provide me with a chance to check if the developers had picked the right story according to the priority.
Triage – We used to have a weekly story prioritization session (which we called as Triage). Being an Agile project, this is a key mechanism to deliver value to the customer. Re-prioritization on a regular basis helps provide the best value for money to the clients.
Iteration kick-offs – We had a 2 week iteration and at the beginning of each iteration, we used to have a kick-off session in which we discussed the stories which were currently being developed and then the analysts would discuss details for those stories which were prioritized highest within the backlog and thus ready to be picked up for that particular iteration.
Showcases & Walk throughs – At the end of each iteration, we used to conduct a showcase where we demonstrated the latest version of the application being developed (usually the Subject Matter Expert from the client demonstrated most of the functionality which were developed within that iteration – this gave them a feeling of ownership). Each iteration, we also conducted walkthroughs which was a more hands on approach for the users to test the latest additions to the application. This involved the users actually logging into the application and trying out individual functionalities. I think that this approach is a fantastic ‘Change Management’ initiative and helps get an acceptance from the actual users even before the application has been deployed.
In my next blog, I shall discuss some of the tools that helped me dealing with the distributed nature of the project.
Subscribe to:
Posts (Atom)
Posts
