Transparency With Scrum (Part II)
On the client side, requirements were formulated by the Business Unit and finalized and managed for the supplier’s team by the Product Owner (PO), and a business analyst on the supplier side played the role of Proxy Product Owner (PPO).
On the client side, the Business Unit formulated business requirements, which were finalized and managed for the supplier’s development team by the Product Owner (PO). Additionally, a business analyst on the supplier side filled the role of Proxy Product Owner (PPO), whose job was to be the sole source of clarifications of requirements for the team.
This additional role was set up in order to mitigate the fact that because of the distance, it would be logistically challenging to make the client’s PO available to the entire team all the time. So the PO and the PPO set up a knowledge management process whereby the PPO was extensively educated by the PO on the business requirements over time and was able to provide explanations for the team. Another function of the PPO was to write acceptance tests for the sprints.
The overall management of the program was done through the Program Steering Group (SG), with client Project Managers reporting into SG. The PMs were to monitor the team on the one hand, and to work with the PO on the other. Although Scrum does not provide for the Project Manager role in the traditional sense, the client felt it necessary to set up separate PMs to perform the following functions:
- Risk management: Identify and manage project risks on the day-to-day basis
- Team management: Onboarding of new offshore resources, interviews, scheduling, vacations, overtime, etc.
- Budget management: Tracking project budgets to prevent overruns or apply for additional funds in advance, if needed
- Tracking and control: Tracking the status and ensuring the overall transparency of the multiple concurrent projects to the Steering Group
The Scrum Master on First Line side interfaced with the PM and worked with the team daily to remove their impediments.
Initially, the client introduced specific reporting standards, documentation and metrics to be used on all projects. However, as a specialist development firm who has been successfully using distributed Scrum since 2005, First Line had its own tried and proven project management toolkit. Pretty quickly after the launch of the program, some of First Line’s Scrum Masters started using what is known internally as the Scrum Project Template. This Excel-based template essentially is a comprehensive set of clearly presented and visualized metrics broken down into several groups: product metrics (LOC count, code coverage, code complexity, defect density, etc.), project scope and budget burn-up charts, sprint scope and budget, and team metrics such as sprint estimation hit rate and velocity. Raw data for many of the metrics is collected automatically and exported into Excel from TFS, so putting the report together is not a huge demand on a Scrum Master’s time. The reports were submitted by First Line’s Scrum Master to the customer Project Managers weekly.
Essentially, the template provides a reliable dashboard that gives the client all critical project-related information at a glance. Some product metrics are not significant in terms of their absolute values (e.g., in practical reality there is no non-arbitrary way to determine “optimal” code coverage or maximum cyclomatic complexity, as we discuss at length here); however, managers can glean a lot of useful information by looking at the trends. On the other hand, metrics like sprint hit rate, team velocity, sprint scope, or product budget provide direct and immediate information at a glance. Since the dashboard is updated at short intervals, managers can spot menacing trends quickly and take corrective action.
Continued in Part III