Agile Development Practices Conference - December 2007 - PDF with Notes

Thanks for having me here this morning. I’d like to talk to you today about our team’s

adoption of agile practices.

This was our development team 8 months ago. We were working on a large enterprise GIS

project for a state agency and we were going downhill fast. The project was going to go off

the rails if we didn’t find a way to get it under control and quickly. We needed an efficient

and effective way to manage the project or the wheels would come off before we knew it.

In general, we were having problems meeting requirements, we had budgetary issues, and

we had serious estimating problems. We needed to change direction, and fast.

Our lead architect Dave Bouwman and I had both dabbled in Agile in the past and decided

we would implement some Agile practices to get the project back on the rails. We did a

bunch of research and decided that the practices and guidelines of Scrum seemed to fit the

bill for our development team. We talked it over with the entire team and everybody

agreed that it was worth a try. So, we put the Scrum training wheels on, got back on our

bikes, and decided to take the plunge and become Agile.

1

To us, Scrum offered a better bike to ride down that big hill. Our organization at the time

was stuck in the traditional waterfall methodology and had a difficult time completing

software development projects satisfactorily. We decided that under the corporate radar,

we’d begin using Scrum in two-week increments. We started out doing Scrum by the

book…and the book was Ken Schwaber’s Agile Project Management with Scrum. We

quickly found our footing on the project and began to immediately see results and useable

software at the end of every sprint.

Aside from the obvious improvement in our ability to deliver software, our team began

learning a lot about ourselves. At the end of every sprint, we held our sprint retrospective.

We are very fortunate to have a team of developers who are very mature, have no egos,

and are dedicated to improving how we do things. As such, we find it very easy to accept

the Scrum mantra of Inspect and Adapt. We constantly review our work and decide what

worked, what didn’t work and if there are better ways to do things for our team.

2

Now, I’m a huge fan of Guy Kawasaki. Guy Kawasaki is the former head evangelist at Apple,

the co-founder of Truemors, and the managing director of Garage Technology Ventures.

Around the time we starting to do Scrum, we came across a webcast Guy was giving about

product evangelism. One of the key concepts that Guy presented really struck a chord with

our team. It is the concept that we need to make things meaningful in order to inspire

others around us to take action. In his words “It’s easy to evangelize and get others to

evangelize things that are meaningful” . According to him, to make meaning, we need to:

Perpetuate good things

Create good things

End bad things

Our team quickly recognized the similarities between these three commandments and the

ultimate goals of Scrum and agile practices. We decided to accept Guy’s challenge and

make a meaningful effort to evangelize our team’s agile vision to the rest of our

organization, our clients, and the broader GIS software development community.

3

To that end, we needed to make a mantra. Guy believes that instead of mission statements

or vision statements that don’t really resonate or communicate why we do what we do, we

should make a mantra. A simple 2-3 word summary of why our product or service exists.

Mantras help keep us on track. They help us understand why we go to work.

We thought about what our mantra should be for quite some time. We considered what

mantras might be for other companies:

Nike: Their customer slogan is Just Do It, but their mantra for why their product exists is

authentic athletic performance

FedEx: yes, they deliver overnight service. When it absolutely positively has to be

there…they deliver peace of mind

After a bit of discussion and some head scratching, we all walked away with nothing. Then

Dave Bouwman, our lead architect, came in and said “What about ship quality?” He was

right. The lightbulb went off that that was it. What do we do…we ship software. The only

way we, as consultants, get paid for our software development efforts is if we ship quality.

We had it, something we could all hang our hats at the beginning of every day. SHIP

QUALITY.

4

In order to ship quality, we had to start doing things differently…and I don’t just mean

reading a book about Scrum and following the directions. That only works for a short time.

The first thing we learned was that we needed to make open and honest commitments as a

team to produce high quality software every iteration. It’s not as easy as it sounds. You

need to check your ego at the door. There are no heroes on our team….our team is the

hero. There are no goats on team…our team is the goat. We sink or swim together. As

such, we make a diligent effort at the start of every sprint to ensure that the entire team is

comfortable committing to the work of that sprint. We work hard together to complete all

of the user stories we’ve accepted by the end of the sprint.

We believe that this new level of commitment fosters a true team atmosphere. We don’t

blame someone if something goes wrong during the sprint. Instead, we accept the

responsibility for the failure as a team and try to understand why it happened and what we

can do to avoid it in the future.

5

We also learned very quickly how to become a cross-functional team. Some of us are good at

architecture and design, others at coding, others at database design, etc. We’re fortunate to have a

team of very smart guys who can share the load no matter what their specialty is. In a way, we act

very much like the guys in this picture.

I am an avid cyclist and a rabid cycling fan. My favorite event in cycling is the team time trial (or

TTT). For those of you not familiar with the TTT, it is a bicycle race where teams of cyclists race

against the clock to complete a specified race course. The TTT is usually held as a single stage of

larger 2-3 week races like the Tour de France. The time for the team is based on the team's last

rider to cross the finish line. Teammates work together by rotating through the lead position and

resting in the draft of the other riders when they are not leading. In this way, the task of setting the

pace is shared. What's amazing is that the riders on the team are usually specialists in different

areas of cycling: they are climbers, sprinters, domestiques, individual time trialists, or general

classification guys. But in the TTT, they put their specialties aside and all ride for one common goal:

to cross the finish line with the best team time. If the slowest team member falls out of the group

during the race, they wait for him, and help him get back up to speed. Once they're back together,

they can achieve their maximum efficiency as a team again. The TTT team truly operates in a cross-

functional manner.

By working in a cross-functional team and performing like a time trial team, we have found that this

fostered an atmosphere conducive to our professional and technical growth. Our team is

constantly evolving by doing things they had never done before. And, we’re doing them well. And

in the long run, we’re crossing the line together and delivering quality software in a very efficient

manner.

6

During our transition to agile, we decided to do away with the traditional management

roles that seemed to dog most organizations. On the organization chart, I was technically

the office manager and the project manager. However, neither the team nor myself ever

really consider our official titles as anything more than words near our names on some big

chart. How we prefer to view our relationship is as peers trying to develop software. As

such, I elevated (or relegated, depending on your point of view) my position to that of a

servant leader. It wasn’t my job to tell our development team what to do. They’re big

boys…they know what to do and how to do it better than I do. What they couldn’t do was

get the corporate honchos off their backs long enough to get their project work done. They

couldn’t resolve IT department problems that were slowing down their development effort.

They couldn’t order phones that they needed to talk to our clients. But as the official

“office manager” I had some authority in the organization to do that. So my job became

that of a facilitator. Someone who could remove the impediments the team faced, and

allow the developers to do what they do best…create quality software.

7

So, I may not have said this yet, but implementing Scrum wasn’t easy. One of the hardest

things to accept in Scrum is its brutal capability to surface dysfunction very quickly. Over

the course of a few sprints we were beginning to learn things about our team that needed

improvement or changes. I think we all believe that our team is far more efficient because

of the changes we’ve made.

But what was more difficult to absorb was the level of dysfunction it exposed within our

larger organization. Most of our division’s projects were woefully behind schedule and/or

over budget when we started using Scrum. Because we quickly showed success, the

organization wanted to know what we were doing differently to get ahead of schedule and

get under budget. They wanted to know what they needed to do to replicate our success.

So, we told them the honest truth.

8

One of the biggest shifts our organization needed to make immediately was to put an end

to the fire drill mentality. You know the fire drill….I need the foo

functionality….yesterday…code it quick….get your team off whatever they’re doing and get

it done today!

[Tell the Image QC story here]

What our organization needed to understand is that agile teams are committed and

dedicated to the work of their current Sprint and are not to be interrupted during those

Sprints. The fire drill mentality distracts and disrupts team work and efficiency. Context

switching is extremely detrimental to developers. We pulled several studies that supported

this point. All the execs agreed, this needed to stop. The very next day after discussing

this, it started all over again. The organization just couldn’t commit to committed teams.

9

Another problem we had was our organization’s inability to break free from what Ken

Schwaber calls “The Tyranny of Waterfall”. They believed that the more time we threw at

developing detailed requirements and design documents, the better we’d be at completing

the project. Each time we discussed agile practices with them, every one agreed “This

sounds great. Let’s do it. But not on this project, that project, etc.”. And, to use another

one Ken’s phrases, they constantly reverted to muscle memory. Any time they saw a chink

in the armor of agile practices, their battle cry was, “This Scrum stuff doesn’t work.”

Instead of inspecting and adapting to make it work, they were ready to revert to waterfall

at a moments notice.

10

A few months ago at a company offsite, I spoke about the cultural changes organizations must be willing to make to really promote and encourage agile practices. I gave examples of things that the big boys are doing at Google, Yahoo, Microsoft and Netflix. Things that make a huge cultural difference and actively support agile practices. I was trying to illustrate what agility looks like from a cultural and organizational perspective. I was trying to demonstrate what it would take for our organization to truly adopt agility and provide a supportive environment in which it could thrive.

However, a comment I received from one of my colleagues stopped me in my tracks. "Sure it works for them," he said, "they're huge. They can do anything they want to. We can't do that here. We're not Microsoft or Google!" I was flabbergasted and didn't know how to respond at first. I am a firm believer that you can do anything if you put your mind to it. I feel that way personally, and I feel that organizations should think that way as well.

I think that a fundamental failing of organizations today is a self-limiting attitude of complacency that seems to exist at many companies. Striving for mediocrity. "Accepting" our limitations. "We can't do that because we're not Google". It's easy for companies today to live in the middle ground. Average companies, with average organizational cultures, producing average products…you know…crap. As Seth Godin says, most companies "...smooth out the edges and go for the center". I can't accept that.

My question back to the naysayers is "WHY NOT?" Why not do something remarkable? Why not change our organizational culture to become remarkable? Google, Microsoft, Netflix, Yahoo!... they all became successful precisely because of their ability to say "Why not?". They became successful because they understood the value of organizational culture. They provided an atmosphere for free thought and forward progress. The decided not to live in the corporate middle-ground. I'm not saying that every company can do what Google, or Yahoo, or Netflix has done, but we can certainly learn from them. We can learn to change our culture to support agile teams. We can decide to do something different...we can become agile organizations. If one of the key criteria for the success of agile adoptions is an agile organizational culture, then I'd like to propose its antithesis: One of the main reasons for the failure of agile adoption is organizational complacency.

11

After doing some serious retrospection, our team decided that our organization just wasn’t

ready to really adopt agile practices. However, we were very happy together as a team and

felt we had something very special between the five of us. So we started to ask ourselves

the question “Where to next? Do we keep working against the grain? Do we give up and go

back to waterfall? Do we do something else?” It was a difficult time. So, what did we

decide to do?

12

Well, I guess you can say we inspected and adapted at an extreme level. We kept our

development team in tact and found a new home at another company that was eager to

embrace agile practices, Data Transfer Solutions right here in Orlando. Our old organization

kept us on for a few weeks after we resigned to “transition” our project work. We decided

that we would remain agile to the very end. We decided that all of our tasks for the

transition of knowledge would go into a project backlog and we’d sprint out the door. It

worked beautifully and we delivered everything our old organization wanted and needed to

move forward after our departure.

We’re very happy to be here today under better circumstances. We met with our first

clients earlier this week and both they and our new organization are committed to an agile

approach to our first development project. In closing, I’d like to say that what we did was

probably not typical and I hope you all are happy at your current home. I also hope that if

you are becoming agile, you can find a way to work within your current organization as

effective agents of change. However, we have no regrets about what we did, but it was

very difficult. I’d like to give a lot of credit to the guys on our team for having the ability to

know a good thing when they saw it. I’m very proud that we stuck it out, stuck together

and stayed agile to the end…or the beginning…

13

Finally, I’d like to thank our new employer Data Transfer Solutions for being kind enough to

let us speak about our experiences with all of you. And I’d also like to thank Rally for

providing us with not only great software, but some great friendships and relationships that

have allowed us to really grow as an agile team.

So, our team’s story will continue from here and we’ll keep you posted on our agile journey

through posts on my blog and Dave Bouwman’s blog as well. So stay tuned….and stay

agile!

14