My client is a multi-million dollar, global travel company.
It sells complete holiday packages, flights, accommodations and any combination of such travel components. It also sells travel accessories such as insurance, car hire, and so on.
It sells these products online, through its own retail outlets and also through third-party travel agents.
Travel bookings made via my client’s sales channels are currently managed through a number of call centres. Change actions to actual bookings (such as amending travel details, cancellations etc) are done manually (through green screen apps, faxes to hotels, e-mails, and phone calls).
As part of an efficiency improvement strategy, the client decided to replace a number of its call centres with an automated software solution. This would allow all bookings to be recalled, amended, cancelled or replaced all within the one solution. Basically it is expected that fewer call centre staff could manage more bookings faster with this solution.
The project is divided into four releases, which mirror the release of the new sales channel solutions. The call centre must support new types of bookings from sales channel solutions that are being developed by other teams. The client identified changes to requirements and domain understanding as a high risk.
Because the first release was estimated to be very large and the business needed to have delivery as soon as possible, I impressed on the customer that we needed an agile approach, specifically Scrum. I felt that only Scrum had the timeboxing and prioritised backlog features we needed to ensure that we would deliver in a timely fashion the most important functionality first.
The project is now in its fourth month.
All business logic (pricing, availability and component packaging) is held centrally in an aggregation engine and all sales channels use it to sell travel products. This third-party application is cumbersome and the client has very limited knowledge of its use.
Prior to beginning the agile project, my client had undergone a major restructuring phase and had lost, through redundancy (voluntary and otherwise), about 40 percent of its in-house development people (business analysts, domain specialists, developers etc). This reduction was offset by the increased use of an India-based, offshore development house.
Communication with the offshore teams is via e-mail, phone, and IM and is facilitated by onshore coordinators. The time difference coupled with cultural and language issues have significantly affected communication.
The client as a whole has not adopted any formal agile approaches in the past. Some people in the development department have dabbled with XP and RUP.
This is the first time that Scrum has been used in any project in the organisation.
The appointed business Product Owner is very proactive and supportive and the senior management have signed up to the ‘no-interference clause’ that I insisted upon.
The team’s definition of Done is two fold:
* “Technically Done” describes written code that has passed the developer test cases, has the set minimum design artefacts (logic/web flows), is properly formatted (style), and has the minimum documentation.
* “Done Done” is technically done code that has passed testing by the in-sprint tester.
A hastily assembled development team of thirteen contractors was put together because there were not enough permanent in-house people to draft and the offshore capacity was already maxed out. These developers vary hugely in their technical caliber and all have very limited business domain knowledge. Only one had any experience in an agile environment.
It was agreed that the business assigned development manager would fight the management battles, while I would be the team lead, architect (by virtue of being the closest to the project from inception), and ScrumMaster. My additional role was to mentor the development manager to progressively take over the team lead and ScrumMaster roles and essentially phase myself out.
The development environment and practices include industry-recognised best practices; for example, version control (using CVS), continuous integration (with CruiseControl), test driven development, and pair programming.
The team itself has gone through several inspection and adaptation cycles.
First, we started as one team, with everyone picking up any task on the backlog. This didn’t work so well because of varying technical abilities that were not identified in the recruitment process. So, rather than fire the inexperienced, we changed to a functional group setup.
Next, we split the team into four functional groups (such as UI, database etc), each headed by an experienced developer. This person takes ownership of all tasks relevant to the group’s expertise and is responsible for reporting on group progress at a high level. We still have the daily scrum with the whole team. This new functional group setup seems to work well. There are fewer issues of technical inability reported and more real impediments are now coming to light.
There is pair programming within each group. I pair with developers across groups.
We also practise collaborative and swarm design to ensure that we have consensus and buy-in on the model and design decisions.
Sprint Backlog not completed during sprint.
Over the last two sprints, the team has not completed its sprint backlog.
We hold retrospectives at the end of each sprint and each time the team identified reasons for the failure to complete the sprint backlogs. With the help of the team and the PO, we came up with workable solutions going into the next sprint.
A positive outcome is that although the backlogs are not completed, we progressively reduced the number of tasks left outstanding in the second sprint. We also identified different reasons in the second sprint for the tasks left undone.
Some completed tasks are of unacceptable quality.
Some critical tasks that were allegedly completed had significant quality issues:
- Despite the team having a very clear definition of Done, many tasks were taken to Technically Done, but consistently failed even a basic demo.
- Shortcuts were taken to fulfill the automated format and documentation checks (e.g., comments were written, but were not descriptive or helpful).
- Test cases seemed to be written, but on random inspection were found to be ineffective.
Team not following Scrum when the ScrumMaster is away.
Although I am based most of the time at this client site, I sometimes have to be away at other engagements and conferences.
During my onsite days, the Scrum process is consistently adhered to. The daily scrum happens every day at the same time and impediments are identified. I spend the rest of the day helping the team and, together with the development manager, focusing on overcoming impediments.
On my return from any absences though, I learn (usually from the daily scrum!) that no scrum was held on the day/s I wasn’t in!.
When I ask the development manager (who is also present at the scrum) why he doesn’t rally the daily scrum in my absence (despite being asked to), he says he doesn’t have time to do this.
Good practice during pairing is not being retained.
I routinely spend time pairing with the developers because it is often more effective to communicate ideas with code. The pairing presents an opportunity to review how the developer is approaching a piece of work.
Often though, when inspecting the developer’s code, I spot inefficiencies and blatantly wrong design approaches. I work with the developer to resolve these issues and leave the pairing believing that they will build on the reworked solution and design. Then when I check the code later, I find that they have continued with the incorrect approach. This has also been reported by some of the other experienced developers in the team.
To submit a case study for discussion, contact the editor.