Skip to main content

Guidewire: Waterfall is more expensive - 1

Scrum is in fact being used as an organizing principle in large and growing companies. Yesterday, Stuart Read came to the Scrum Breakfast in Zürich to tell us about Guidewire, probably one of the first companies ever to have adopted Scrum from top to bottom.

Guidewire is a no longer-quite-so-small start-up (350+ employees) which provides core IT technology to the insurance industry. The entire company is organized with Scrum, even the top executives are part of Scrum teams, and Stuart prepared what is probably the first documented case study of a such a company.

Stuart's method of presenting the material was most unusual. Instead of relying on a presentation to convey information, he divided the case study into an A Part and a B Part. The A part provides the background, describes the company, its successes, what's unusual about the company, etc. The B Part, which was only made available during the workshop, brings the reader up to a point where the company is faced with a challenge, which is then the subject of discussion in the workshop.

Everyone got to read the A part in advance. Then we discussed the situation and some interesting questions about the company. (Unfortunately only a limited version of the A part of Guidewire case is available on the net). Then he posed a series of questions to the group, only after discussion did he present the solution which Guidewire chose.

Guidewire was founded in 2001, in the wake of the Dot-Com boom/bust and just as the Agile Manifesto was being finalized. Company management decided early on to use Scrum as the organizing principle of their company. Why? Because the founders did not know the insurance business and needed a way to learn quickly. [Lean Principle at work: Maximize Learning]. Guidewire added some interesting twists to the basic Scrum structure. The entire company applied Scrum from day 1. So not just software development but also finance, marketing, etc. The Scrummasters rotated every month. So in essence, the company re-prioritized and reorganized(!) every month.

First question: Would you want to work for Guidewire? For Scrum evangelists (and the 30 or so participants in yesterday's event), no question, but for MBA students/executives in training? Not so obvious. Reorganizing every month can be traumatic. [And let us remember that MBA Students are being trained to work their way up quickly through middle management which, as Parkinson's Law explains, exists to preserve law and order — otherwise known as itself -- not to reinvent itself every month]. So does all this reorganizing really make sense? And this lack of obvious hierarchy is really quite threatening — How do I defend my Senior VP title? So either you love it at Guidewire or you hate it (and this later proved to be challenge when looking for Senior executives).

Who do you hire to work in a Scrum environment? We can (and did) talk about the personality types who are suitable for Scrum. Self Motivated, Team Players, Sense of Humility, Sense of Passion. But Guidewire applied the Scrum Principle of self organization to hiring as well: Let the teams pick. There is no interview process, just a 1 day on the job trial. If the team wants the candidate, s/he stays. In Switzerland, we call this a "Schnuppertag" — a day to sniff noses and get the feel of each other. (Seems like there ought to be résumé screening process: According to Jürg Stuker, the ratio of résumes to hires at namics is 100 to 1! )

Next question: Would you want to buy from Guidewire? Again, initially a difficult sell. The development process seems chaotic. The predictability of a 2 year road map is missing, so there is an impedance mismatch between the big customers (and all insurance companies are big) with a 1 to 2 year planning cycle and a supplier with a 2 month turn around cycle.

When we are honest, this two year roadmap is a kind of fairy tale - whether it will really come to pass is anybody's guess. But this roadmap subsitutes for trust, or perhaps simulates trust. So Guidewire started selling to second tier companies — hungier and less complicated than the biggest, most established players. With time, working software and responsiveness to customer needs wins out. Trust is really about track record and relationships, both of which are built over time.

Part 2: Would you buy from Guidewire?
Part 3: Scrum and Job Satisfaction

[ Update: Jürg Stuker has published an excellent synopsis in German on the namics blog. ]


Ted M. Young said…
I'd like to correct some misinformation here:

Guidewire has not been "100% Scrum" for several years -- certainly not as of when I joined the company in Feb. 2007.

The reorganization each month is a myth, or at least misunderstood. Again, as of the time I joined, there have been no such "monthly reorgs" happening.

I'm not sure if the point "There is no interview process, just a 1 day on the job trial." refers to Guidewire. If so, it's wrong.
Interviews have always been somewhat "standard" in that you have to be interviewed by 4-8 people before being given an offer.

Yes, Guidewire is agile, but that has been a change over the past 2-3 years. They were "Scrum-like" prior to that, but my view is that they were not truly Scrum when I joined.

- Ted Young

Popular posts from this blog

Sample Definition of Done

Why does Scrum have a Definition of Done? Simple, everyone involved in the project needs to know and understand what Done means. Furthermore, Done should be really done, as in, 'there is nothing stopping us from earning value with this function, except maybe the go-ahead from the Product Owner. Consider the alternative:
Project Manager: Is this function done?
Developer: Yes
Project Manager: So we can ship it?
Developer: Well, No. It needs to be tested, and I need to write some documentation, but the code works, really. I tested it... (pause) ...on my machine. What's wrong with this exchange? To the developer and to the project manager, "done" means something rather different. To the developer in this case, done means: "I don't have to work on this piece of code any more (unless the tester tells me something is wrong)." The project leader is looking for a statement that the code is ready to ship.

At its most basic level, a definition of Done creates a sh…

Explaining Story Points to Management

During the February Scrum Breakfast in Zurich, the question arised, "How do I explain Story Points to Management?" A good question, and in all honesty, developers can be an even more critical audience than managers.

Traditional estimates attempt to answer the question, "how long will it take to develop X?" I could ask you a similar question, "How long does it take to get the nearest train station?

The answer, measured in time, depends on two things, the distance and the speed. Depending on whether I plan to go by car, by foot, by bicycle or (my personal favorite for short distances) trottinette, the answer can vary dramatically. So it is with software development. The productivity of a developer can vary dramatically, both as a function of innate ability and whether the task at hand plays to his strong points, so the time to produce a piece of software can vary dramatically. But the complexity of the problem doesn't depend on the person solving it, just …

Scaling Scrum: SAFe, DAD, or LeSS?

Participants in last week's Scrum MasterClass wanted to evaluate approaches to scaling Scrum and Agile for their large enterprise. So I set out to review the available frameworks. Which one is best for your situation?

Recently a number of approaches have started gaining attention, including the Scaled Agile Framework ("SAFe") by Dean Leffingwell, Disciplined Agile Development (DAD), by Scott Ambler, and Large Scale Scrum (LeSS), by Craig Larman and Bas Vodde. (Follow the links for white papers or overviews of each approach).

How to compare these approaches? My starting point is Scrum in the team. Scrum has proven very effective at helping teams perform, even though it does not directly address the issues surrounding larger organizations and teams. An approach to scaling Scrum should not be inconsistent with Scrum itself.

Scrum implements a small number of principles and constraints: Inspect and Adapt. An interdisciplinary Team solves the problem. Deliver something of va…