THE CHALLENGE
TPVision is a joint venture created to manufacture and sell Philips-branded televisions in multiple regional markets such as EU, APMEA etc. With a history steeped in waterfall model of development, TPVision started its journey in the same path. Unfortunately, through 2010 to 2014, its attempts at quality deliverable within predetermined deadline remained unsuccessful. This had a long-term effect in its ability to generate business value and growth.
Having spent 2 years working in the above scenario, as a Project Manager heading SMART TV department, I started trying to understand the problems and help introduce any change which could make a positive impact.
ANALYSIS
Through multiple retrospection and post-mortem meetings, the following problems were identified for having a major impact on our ability to meet our commitments:
1. Supply management - Our suppliers delivered their committed deliverables with low quality. However, since TPVision was following feature gates and system testing happened at the end of development phase (which ran for 6-8 months), the quality of third-party deliverables were not tested early. This led to a higher risk of delay and poor quality for end users.
2. Late testing of software - Since TPVision followed phase gating and adhered to waterfall model, strict discipline was enforced regarding requirement finalization, development and testing. As testing would commence at a very late stage, bugs would start piling up once multiple test rounds started and would inevitably result in stretched work hours, slippages and a fall in quality.
3. Dysfunctional teams - The trust within management team as well as development team was low. It was presumed that managers would represent their departments in board meetings which generally resulted in a blame-game scenario with managers blaming others for their team's failure. Testing team was a completely separate team and worked in an orthogonal manner to the development teams. This percolated to development teams, where there was a general lack of commitment from team members. It all boiled down to the organization losing focus of the end goal.
4. Top-down decision making - Every decision was driven in a top-down approach. Estimations were made by Architects which were to be adhered to by developers. Deadline commitments made by directors were expected to be followed by managers and teams. Phase gates were setup based on code reviews, the deadline for which was committed by managers. These were not based on actual demos on production systems. This inevitably inhibited result-oriented actions from development teams as they simply needed to work as per plans given by architects or managers.
AGILE TO THE RESCUE
As a mechanism to resolve the problems listed under the "Analysis" section, I came up with the idea of introducing Agile processes within the organization. The initial step towards this was to interact with the most impacted stakeholders. In this case, it was my supervisor (one of the Directors) who needed to be consulted for any successful attempt at Agile transformation. The discussion was extremely fruitful during which we came up with a list of constraints we would need to respect if we wanted to implement such an idea. Some of these limitations were:
a) A pilot Agile project could be run only within my team.
b) All artifacts which needed to be provided externally would have to be delivered as per deadline. e.g, Microsoft project plan (MPP) with planning details
c) All phase gates needed to be respected, which meant that though development was to be carried out using Agile processes, the release needed to follow a plan as given at an organization level
d) No other team or supplier should be impacted due to my team's process changes.
Results were to be inspected jointly by a team comprising our System Architect, Director and me to judge the success or failure of the change. We came up with the following parameters to determine the results:
Productive effort actually used for the project deliverables
Defect count leaked out of the process towards end customers
Slippage in deadline for any deliverable
Transparency in reporting project artifacts
IMPLEMENTATION
Maintaining the aforementioned constraints on team activities, we implemented the following steps:
STEP 1: ALIGNMENT WITH THE STAKEHOLDER
A self-organized Scrum team consisting of members of a few other teams was formed. The team included participants from the testing team as well.
Artifacts were broken down and delivered in an incremental manner. The development plan reflected the final deadline as the delivery timeline of the last increment. E.g, Design document will be incremental and will be created in accordance with the development plan. Hence, in every increment, the design document will be updated and delivered as implementation goes ahead.
The stakeholders supported external queries regarding team activities through the data supplied by the team.
As cost was to be minimised, we used free tools such as Trello and manually created burn down charts.
I completed my Scrum Master certification and mentored the team on Agile policies and processes.
STEP 2: SETTING UP THE PROCESSES
All members of functional team were given a 2-day training on various aspects of Agile policies and principals. Special attention was paid to estimation techniques, team building and Scrum ceremonies.
Team was requested to propose a smaller scrum team for pilot project based on required competencies. Views of Subject Matter Experts (SMEs) and System Architects were also taken into account. On request 2 developers from other teams and 2 testers were also taken as part of scrum team.
Product Backlog was identified by a SME who acted as the bridge with Marketing team and became the Product Owner. Initial PBIs were EPICs which were broken into smaller stories during planning or refinement activities.
All defects found during scrum validation were entered in Trello and not into bug tracking database. All such bugs were fixed as part of Sprint. Deliverables were not released into product with defects and Sprints were failed in such cases.
3 Sprint ceremonies were finalized - Sprint planning to be conducted on first Monday of first week of the Sprint, Sprint review and Retrospection on last Friday of Sprint.
‘Working Agreement’ was conceptualized for the team and had 3 items:
All changes were to be completed on scrum branches and then merged on to mainline
Every developer was responsible for not breaking mainline build. No one should leave for the day breaking the mainline build
Every developer was responsible for mainline sanity and should merge code only after unit testing and automated testing
Sprint planning was used to estimate high priority user stories and update Sprint backlog based on team commitment (not on velocity or 'yesterday's weather'). Sprint duration was arrived at after couple of failures. Initial value of 4 weeks caused late feedback. Modified value of 2 weeks caused high failure. Hence, a value of 3 weeks was arrived at which was found to be correct through multiple iterations.
Daily standup was gradually turned into a successful meeting place for all to share stories and impediments. It was also seen that developers would self-form pair programing groups after standup based on competencies and needs.
Actual effort was deemed mandatory as output parameter for any task in Trello. This enabled data to be collated during Sprint review.
Team actively involved all stakeholders during Sprint review which was given through actual Product demonstrations.
Sprint refinement was gradually transformed into a major activity as this helped us with supplier management and dependency tracking for smooth Sprint execution.
Retrospection was used by team to brainstorm actual problems faced during Sprint execution, which could be either technical or process oriented. Action on management was passed on through board meetings.
Sprint activity was translated to MPP by me manually in order to maintain validity of external artifacts for the organization.
STEP 3: SUPPLIER MANAGEMENT
Suppliers were asked for breakup of their deliverables into smaller segments based on Sprint requirements. 2 weeks before next Sprint dependencies on suppliers were identified through Sprint refinement. These were communicated to suppliers and requested to be delivered in a manner which would not impact their phase gate commitments.
Suppliers were also informed that defects would be raised against them at a far earlier date as Sprint reviews would showcase defects within suppliers systems. This would translate to suppliers getting defect information at an earlier date than previous operations. This helped in better quality management for suppliers.
RESULTS
Following results were seen when Agile process was compared to previous waterfall model -
Actual effort for project during waterfall could not be arrived at, since actual effort for maturity phase was never identified. Hence, a calibrated effort of 30% of development effort was used for Ideal effort calculation for maturity phase. In summary, Ideal effort for planned activities in waterfall (1.3 * Development effort) was compared to Actual effort of project using Agile processes. Actual effort for project deliverable reduced by up to 25% using Agile process (this included effort of all teams involved in Agile and waterfall model)
Defect count reduced by up to 52% in Post-release scenario and a whopping 87% for Pre-release scenario using Agile process (as per organizational bug tracking database analysis)
Delivery timeline slippage was reduced to 2% using Agile. This was a major achievement as using waterfall deliverable at product level was never delivered as per commitment.
Most importantly, team morale increased. Ability to experiment led to better solutions coming forth. Transparency within team and externally was enhanced and automatically led to trust and commitment both inwards and outwards for the team. Stretched work hours also reduced leading to better work-life balance.
The results of the pilot project helped the organization gradually move all projects within the geographical site to Agile from Waterfall process.
About Me : A passionate Agile leader having 16+ years of experience in software industry, I have handled Agile projects of various complexities. Having successfully handled Agile transition for multiple organizations, I write about my experiences, challenges and some solutions.