At one of my clients, we were very frequently confronted with "Crunch" times, sometimes due to business deadlines, and sometimes due to delay caused by dependent teams.
There was a need to come up with an approach to track the progress of the work, and at the same time, ensure that the team was productive and not working under pressure.
I followed few strategies that helped us achieve the required high quality deliverables within the pre-determined timelines. Some of them are:
Daily Morning Team Meetings
Every morning, I would hold a quick 10-15 minutes meeting with all my team members and list down the tasks that the individual team member would be working on. I used the white board in my office to list down their names and write the task(s) next to their name. If a task spanned multiple days, I would try to assess the status of that task in that meeting. If there were any pain points, I would try to understand them as well.
I also used that meeting to list down any action items for me to assist the team (ping business users, give a heads-up to Change Management group; get DBAs, QA personnel, and bring other stake holders on board, etc.).
Each team member was asked to cross out the task from the white board when they were done.
This helped me to keep track of what tasks each of my team members were working on and also helped me plan ahead for the remaining tasks on the project.
I ensured that the meeting stayed within the 15 minute limit. If any point needed further discussion, I would do that outside this meeting with the concerned team member(s).
Plan Out And Complete My Action Items
I would review my notes from the "Daily Morning Team Meetings" and quickly act upon each of the action items. This helped me clear up my plate and make myself available for other tasks.
Give Immediate Attention to requests from Team Members
During the day, if any of my team member faced technical challenges, or had a concerns / questions, I tried to address them immediately.
Effective Design Documents
The design documents were structured in such a way that they were easy to create by the developers. The best part of the document was a visual representation of the Informatica mappings that helped the developer to think ahead as to how the required functionality would be achieved within the code (what transformations would be used, etc.). This helped in better planning of the distribution of functionality among mappings. This also accelerated the development and facilitated in creating effective test cases.
Code Review Checklist
In order to ensure all our Informatica Objects and Unix shell scripts followed the coding standards, I created a Code Review Checklist (which later on became a best practice at the Client location). This checklist over time evolved and helped us greatly in reviewing the code and keeping the commonly occurring defects away from the code.
Active Information Sharing with QA Personnel
In the past, we had realized that no matter how productive our development team is, the success of the project is highly dependent on the success and productivity of the Quality Assurance Team. We actively started sharing our development team's test cases, test data, etc. with the QA personnel in addition to the design documents. This helped the QA team to stay ahead and be ready for testing as soon as the development team was done. At times, I had to also task the developers to assist the QA Team in creating the test data for complex functionalities and scenarios. Overall, this approach helped us greatly and the two teams collectively gave us the desired results within the expected timelines. From time to time, I used to have meetings with the QA Team Lead to set expectations and ensure things were moving as planned.
Weekly Project Status Reporting
Like most of the status reports, my status report was in the form of PowerPoint presentation that had slides about what was accomplished in the prior week, what work was planned for the following week, issues, etc. There were two slides that helped us the most and are worth mentioning. One contained a graphical representation of where our objects were (in Design phase, Development, Code Review, QA, User Acceptance Testing, Production, etc.) for each of our interfaces. Color Codes helped visually understand the progress. My prior manager used to call that slide - Slide with "Swim Lanes". The other slide contained a graphical representation of the project timeline (planned and actual). These slides helped our QA personnel, Change Management team, Business Owners, and other stake holders to understand where we were on each interface and when they should expect their involvement in the individual interfaces. These slides also helped our Program Manager understand our project's status in the overall program.
I hope you can use some of the above mentioned strategies and combine them with your own working style, Project Management and Agile Development principles to create High Performing Teams during your project's "Crunch" times!
