Retrospectives are fantastic opportunities where the team can discuss any issues regarding the project at the end of a sprint. I aim to share some of the experiences and findings written from the viewpoint of different roles in a software project. Together, it highlights the difficulties of outsourcing.
The Architect
Open source tools and API used in the project should be well documented and maintained.
This point is often neglected as architects pick high performance API, with little or no documentation. Remember that it is the team that has to live with the daily struggle of using the API. With poor documentation, the team loses focus on coding instead of squandering about on Stackoverflow, looking for a possible solution to their problems. The team needs to be comfortable with the packages, and poor documentation will always negatively impact the velocity.
Examples and clear documentation of a vertical slice of the system, a prototype, will help the team scale out horizontally. Having a clear structure and well defined interactions between components will help the team burn down faster.
Quality of code should be constantly scrutinised. Static code analysis tools will help.
Knowledge sharing and training is encouraged. Pairing up the architect with other developers in pair-programming will help share the knowledge and gives the architect an opportunity to set the coding standards.
Write interfaces and couple them with test cases. This is a great way to ensure that the code that is checked in will actually perform as it should as it would be independent from the development cycle. There are a few mock APIs that will help this approach. Naturally test-driven development is highly recommended.
The Test Manager
Understanding both the requirements and the problem domain is critical to the success of the Test Manager, and the project.
Requirements will be written badly at times. It is therefore important to hunt down the Product Owner and flesh out these missing pieces. Ensure that each tests conducted is repeatable and well documented. Ideally, automated testing is highly recommended.
A creative, technical, thorough and methodical Test Manager might be hard to find. Ideally you would want a person that is an expert in the domain of your application and have a knack of finding bugs in any system. The scope of the system must extend to that of the customer setup and OS/hardware variation.
The Scrum Master
The Scrum Master lives to help the team, both resolving any blockers and help run the team on a daily basis. Ideally you want a Scrum Master that has the best interests of the team in mind and is at the same locale as the team. Always remember that the Scrum Master works for the people and this position is not suited for an aggressive tyrannical individual.
For our outsourced project, we rotated the Scrum Master role between the team members in Bangladesh with varying degree of success. We deliberately assigned this role to a promising Junior developer as an attempt to break the hierarchical mold in Bangladesh. This did not work well as the concept of seniority is so ingrained that it backfired with a senior developer threatening to quit because he felt that he was undermined by a junior and that his talent was not nearly recognised. Naturally we also tried assigning this role to this particular senior developer but his style was so tyrannical and turned the role of Scrum Master into a mini authoritative dictatorship.
Scrum Master should challenge the Product Owner. Ensuring that the team can finish all the tasks in a given sprint is important. Nothing is more demotivating than constantly pushing sprint backlogs to the next. In stark contrast, nothing is more empowering than being able to finish the sprint backlog plus additional tasks.
One difficult aspect is dealing with bug fixes. Bug fixes can interrupt the whole sprint. That is unavoidable. However, scheduling a couple of bugs each sprint will help drive down the bug lists. A zero-bug policy is admirable. Personally, an alarm bell goes off when there is absolutely no bugs in the system.
The Product Owner
The number one advice is to be available for the team. Answer their questions on time and flesh out your ideas clearly and ensure each user story is well thought out. Communication is key. Ensuring that the team understands the deliverables for each user story will improve their estimations and save a lot of heartaches.
Be interested in the technical details. Participate in testing and consider participating in development. Write test cases, unit tests or anything that will help you answer your number one question: Can I release this product this sprint?
Expect a good product demo at all times. Ask hard questions and never settle for anything less than you deserve.
Having a solid release process also helps. Releasing is surprising difficult and challenging. As Steve Job puts it, “Real artists ship.” I also recommend looking at Chrome`s release cycle – every 6 weeks.
something else 