Case Study: October 2007

22 October 2007

Mike Sutton
Wizewerx Ltd

Background

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).

The Project

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.

Additional Considerations

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.

The Team

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.

The Issues
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.


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 0 (0 ratings)

Comments

Ken Hughes, CSM, 10/23/2007 9:32:23 PM
Mike,

Interesting situation you have...
I have some comments, hope they help...

Have the team, REALLY, bought into the idea of SCRUM ? One of the traits normally leveled at contractors is a lack of commitment (not saying that is the case for all contractors, or indeed your team), but without a team that buy in to 'we will do everything in our power to meet the sprint goals' then you have little hope...

Intriging that the development manager "doesn't have time" - sounds to like he may not have bought into it either ?? Depending on the politics of the situation, I'd look at using someone else (that you trust and have faith will do a good job) as your stand-in when you are not onsite - you never know this may put the dev mgrs nose out of joint enough to get him more involved ??

For the shortcuts that are being taken and the incorrect approaches to design (or the corrections that are being ignored) are you fixing these in the sprint (or maybe the following sprint ?) - this would at least highlight the substandard work to the business and allow someone to make it clear to the teams that the substandard work is not acceptable.

Just some comments - feel free to contact me if you'd like to discuss further...

.. Ken
Mike Lowery, CSP,CSM,CSPO, 10/24/2007 3:32:57 AM
I agree with Ken, some of the teams i have worked with have had the same issues (not doing the stand up when i was not there). I got over this issue by continually explaining that the standups were for them not a management check up.
We used to decide in sprint planning who was doing what, this lead to weaker standups as the questions were almost redundant and did not help people plan work. Now no task is assigned until the first morning, this has enthused the team to plan and say "well i want to do this" and then organise around it. I try to talk to my Scrum Master peers about getting the teams to do "Scrum the Lifestyle" not "Scrum the Process".
Andy Murthar, CSM, 10/24/2007 9:37:37 AM
13 team members is too many. You are already breaking the team by product items so consider splitting the team into two withing the 5 to 9 spec recommended in scrum. The teams do not have to be permenant. If you keep in touch with the backlog you can prepare the team mix in advance of planning.Consider personalities when team splitting, this is very important for culture.Whoever is scrummaster must want to do it, find a general team member who is keen, a people person over a techie. Have you bought books? have you passed around printouts? have you had workshops? What change menagement techniques have you employed to encourage the team? and finally is your boss behind you fully? If you would like to talk further, do not hesitate to mail me
Mike Cohn, CST,CSP,CSM,CSPO, 10/26/2007 11:03:09 PM
One of the things I like to suggest when a team has to drop items from a sprint is that they plan sufficiently fewer hours in the next sprint so that they are nearly certain to be able to finish the work of that sprint without dropping work. I don't ever want to see a team drop work two sprints in a row; it's just too frequent for the product owner to be able to make decent plans.

One thing I often suggest in these situations is that the team take the number of hours they dropped from the sprint, double that, and plan for that many fewer hours in the coming sprint. So if you plan 500 hours, drop 50 in the middle then in the next sprint you should paln for 500 - 2x50 = 400 hours. (This doesn't work when the team drops huge amounts, obviously; then just take the idea as a guideline.) The ideas behind doubling are (1) that if the team missed once I want to prevent that from becoming a habit so we want to drop enough that we'll be sure to finish; (2) if we dropped 50 hours of work we probably also cut some quality corners before that in an effort to make it; I want the team to not do that again and (if needed) to be able to go back and fix any cut corners without necessarily having to say "uh, then, give us 10 more hours to fix the whoozit we did a crappy job on." Yes, I prefer totally transparency and honesty but the team may not be there yet and I mostly just want any early technical debt paid off asap.

Thanks for starting this, Mike. I look forward to more of these case studies!
Mike Sutton, CSM,CSPO, 10/27/2007 3:59:36 AM
Thanks so much for the comments, I'll try and respond to (what I feel are) the key points:
Team Buy-In (Ken/Mike L): I am also feeling this entire team has not bought fully into Scrum the lifestyle. I feel its a kind of waterfall or JFDI institutionalised state of mind. On the plus side , they are looking for leadership - which is n opportunity to lead by example. The team self organising out of Scrum is not an option. There are at least 2 members of the team I trust will also set a good example and take the lead in my absence.

Split the Team(Andy): There is one big daily scrum but there are 4 'teams', so it is already split. And they are not permanent, they can be moved , changed etc. When we do have the standup, its brisk and people participate, I believe they are effective, but perhaps we can improve on this. Because I dabble in NLP and personality profiling, it was a significant criteria when assembling the team and indeed when we split the groups. But I think, there is more to be done to improve how people work together, especially lesser skilled members 'coasting'.

Dropped Tasks(Mike C): This company has a history of technical debt, and that culture is crap! It means that when I discuss with the paymasters about the shortcuts folk have made, they don't really appreciate that this will have to be paid (and budgeted for in cash and time). But I will incorporate pay back time into our estimates from now on.

Update: I have had a long think about this company and this prompted a very frank and open discussion with the head-honcho (who has a very high self opinion and 'knows' everything there is to know about agile ;).
My thinking and the subsequent discussion can be summarised as follows:

Crap-In-Crap-Out: There is a functional spec for the development, while its a good attempt at describing a system, you can't build a working system from it. So the input from the business is of a low quality. When we deviate from the functional spec, we lack a consistent way to record such deviations. This needs massive improvement. I will be discussing this with the Product Owner next week to start using User Stories as a means of recording requirements and instigation and tracking conversations.
Empowerment: There is some confusion between my role and the dev manager's and this is causing empowerment issues for me and the team. This will be sorted out next week in a huge powwow. The head honcho alleges that I'm the only one who supports agile in the team -I dispute this and I'm trying to establish that agile or scrum or anything else is not a silver bullet - the work still needs to be done and done well to get the results. There aren't any magic scrum fairies that suddenly come out and make it all OK. So we shall discuss this in the retrospective next week.
Jeff Sutherland, PhD, CST,CSP,CSM,CSPO,REP, 10/27/2007 4:32:37 AM
Consider a soccer team that doesn't buy into the rules of soccer. They lose every game. Maybe each one buys into a different theory about what game they are playing and they compete with each other instead of the opposing team. A professional team agrees on the rules of play and then executes with power. Far too many software teams are full of amateurs that can't play ball. The ScrumMaster needs to figure out how to fix this. The first Scrum team self-organized to replace every single member of the team before the team could play ball. Some of it was do to lack of domain expertise, some due to technical lack of capability, and some due to lack of real focus. The team self-organized with new players and went into a hyperproductive within a few sprints.

As Camp Scrum last week in Sweden we discussed how teams need to have "Ba" to deliver. This is the spirit of innovation and the flow of knowledge creation. Without the Ba the teams cannot deliver. Get Ba.
Jiri Lundak, CSM, 10/28/2007 5:58:05 AM
Hi Mike, it seems to me, that your PO is trying to do a good job. Have you considered his role's effect on the team. The PO is the person to accept the results of the sprint. He is also the person to refuse the Sprint results as insufficient. How do you present the results of the sprint? Do all team members participate? Have different team members presented at the review. Let the PO (or other real users) use the product increment, in full presence of the team. Let the team 'feel' the responsibility for the increment. Try to eliminate possibilities for excuses, like a poor spec they got from some department, by including domain experts from that department in the team, to clarify unclear points during the sprint. Failing a sprint, without finger pointing, can have a healing effect on the teams' cohesion. I personally have not made any good experience (in the last 20 years) with separating teams across technical layers (UI, object model, database). This often also leads to finger pointing across layers, like: "We failed because of bugs in the database layer", etc. The team needs to understand, that they have all the support and power to do anything to complete the sprint, but at the same time there are no excuses for not delivering and only the team as a whole can blame itself. Try also to take yourself out of the loop. Is it possible, that you try too much to say the team, what they should do? Recently we needed increase the quality of our sprints, because builds broke way too much. We convened with the team and instead of me the ScrumMaster/architect imposing the team my own solution, I just told them: "This and this is our problem, there would be a range of solutions, but I will not tell you which to adopt. You have one and a half hours to come up with a way you want to handle the problem. We will do anything you come up with, no questions asked." and I left the room. The team had some lively discussion, but in the end, decided on a kind of open source committer like form of working. This is now working for two sprints and has shown surprising results. Quality has gone up significantly. And what the best thing is: We have complete buy in of the developers, because they did self-organize and they own the solution.
Sam Brown, CSM, 12/7/2007 5:12:28 AM
Hi Mike,
I have been reading this case study with interest - any update since October?
I was reading The Enterprise and Scrum by Ken Schwaber, it reminded me of this case study.
Ken goes into detail about how there are many reasons why enterprises can't develop and deploy products as you would like them to. Scrum won't solve them. Scrum is simply a tool that will relentlessly and ruthlessly exposes them - which seems to be whats happening at this travel company.
As you try to build a release within the Scrum framework every time one of these obstacles is reached, it will be exopsed.
You can then erdicate them. When the obstacles are gone Scrum framework will enable you to deploy the release that you want. It will also help to identify when old problems reappear.
Please let me know if you have any update.
Samantha
Mike Sutton, CSM,CSPO, 12/7/2007 5:32:44 AM
UPDATE:

After the new development manager came into the picture, he basically set aside the process that myself and the team (and the previous dev mgr) had forged over the course of the last year. Our process, based on Scrum for process management and XP for development had accounted for over 80% of the development so far.

With his approach - which was essentially...

Report to me, only to me;
I assign work.
I am solely responsible for delivering the work (of 10 other people) to the business.
You will work overtime when I say so.

As a consultant at this site, I went to his boss and said this was counter productive, to which he responded 'Scrum/Agile had failed'. I did the entire schpeel that 'Scrum/Agile don't fail , implementations fail'...in any case the hint of support that was there was now gone.

In the 3 months since that conversation, the team has seriously struggled to complete the last 20% of the product, delivery dates (which were not communicated to the team) were regularly missed - needless to say the business are not happy.

They intend to commence the next phases of the project using the same approach.

What have I been doing during all this. Licking my wounds mostly. Taking things personally and learning from the experience. Needless to say I have terminated my engagement with the client for the time being.

Its not all bad though... the team have been spurred into self organisation, they are working better with each other, sharing knowledge and co-operating. Some of the XP practices are still being informally practiced but not enforced.

Lessons learnt (philosophical and otherwise):

Management support is absolutely necessary for agile adoption.
Agility is akin to maturity - some change will only come when organisations feel the pain of ineffective process AND are willing to do something about it.
As a coach, you do the best you can and leave the rest to others.
Value your testers - they are there to help and are not the enemy (my rule is do not argue with the tester!).


Haim Deutsch, CST,CSC,CSM,CSPO, 12/30/2007 3:21:08 PM
Hi Mike, first of all, you are a great example of courage and integrity for sharing your difficult experience with us. In your last update you say that "Management support is absolutely necessary for agile adoption", and you are sooo right. I'm myself working as a Scrum coach. Let me try to share with you some of my lessons learned.
First, as you said you MUST get full management support. by full I mean white card, you need complete authority to implement new processes and new methodologies in the organization. you have to make sure that this is fully clear to everyone in the organization. Second step: make an audit. you have to identify the bottlenecks, the communication problems, the difficulties the development group faced in the past. the best way I found to do this was using the six-result-domains coaching techniques together with individual interviews and technical audit comparable to FDA audit. This phase will give you a full picture of the actual situation, who's against who, plitics, processes, etc... You will know where to put 80% of your energy, and where problems will point from. And the third step is intensive 2-3 day training. you have to give separate training to developpers and to executive management, but you have to make clear to each one in the organization what is up to happen, how it will affect current processes and communication channels, what expectations to have (i.e. what will be the ROI after sprint0, after sprint1, after three sprints, and in six sprints), you have to leverage these training days to stress what is the actual situation (before Scrum) and what it may be if everyone acts well. (don't worry, if someone called you, it is that the organization has huge problems of delays or quality). If you want a case study, you may refer to my CSP application (it's maybe my CSC application I don't remember and don't know if this last one is made public), I describe there ASI case, and how I managed to get collaboration from "hard" guys. Hurry up!

You must Login or Signup to comment.