SlideShare ist ein Scribd-Unternehmen logo
1 von 14
Downloaden Sie, um offline zu lesen
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. quot;Sure it works for
them,quot; he said, quot;they're huge. They can do anything they want to. We can't do that here. We're not
Microsoft or Google!quot; 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. quot;Acceptingquot; our limitations. quot;We can't do that because
we're not Googlequot;. 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 quot;...smooth out the edges and go for the centerquot;. I can't accept that.

My question back to the naysayers is quot;WHY NOT?quot; 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 quot;Why not?quot;. 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

Weitere ähnliche Inhalte

Kürzlich hochgeladen

5 Moments of Everyday Self-Loathing That Perfectly Describe Your Life
5 Moments of Everyday Self-Loathing That Perfectly Describe Your Life5 Moments of Everyday Self-Loathing That Perfectly Describe Your Life
5 Moments of Everyday Self-Loathing That Perfectly Describe Your LifeSalty Vixen Stories & More
 
Inside Look: Brooke Monk's Exclusive OnlyFans Content Production
Inside Look: Brooke Monk's Exclusive OnlyFans Content ProductionInside Look: Brooke Monk's Exclusive OnlyFans Content Production
Inside Look: Brooke Monk's Exclusive OnlyFans Content Productionget joys
 
"Quest for Knowledge: An Exciting Journey Through 40 Brain-Bending Questions ...
"Quest for Knowledge: An Exciting Journey Through 40 Brain-Bending Questions ..."Quest for Knowledge: An Exciting Journey Through 40 Brain-Bending Questions ...
"Quest for Knowledge: An Exciting Journey Through 40 Brain-Bending Questions ...RAGHURAMYC
 
Taylor Swift quiz( with answers) by SJU quizzers
Taylor Swift quiz( with answers) by SJU quizzersTaylor Swift quiz( with answers) by SJU quizzers
Taylor Swift quiz( with answers) by SJU quizzersSJU Quizzers
 
Holi:: "The Festival of Colors in India"
Holi:: "The Festival of Colors in India"Holi:: "The Festival of Colors in India"
Holi:: "The Festival of Colors in India"IdolsArts
 
The Hardest Part About Picking A Show To Watch (Comics)
The Hardest Part About Picking A Show To Watch (Comics)The Hardest Part About Picking A Show To Watch (Comics)
The Hardest Part About Picking A Show To Watch (Comics)Salty Vixen Stories & More
 
How the fever night scores above your mundane nightlife occurrence
How the fever night scores above your mundane nightlife occurrenceHow the fever night scores above your mundane nightlife occurrence
How the fever night scores above your mundane nightlife occurrenceJFI Production
 
Young adult book quiz by SJU quizzers.ppt
Young adult book quiz by SJU quizzers.pptYoung adult book quiz by SJU quizzers.ppt
Young adult book quiz by SJU quizzers.pptSJU Quizzers
 

Kürzlich hochgeladen (8)

5 Moments of Everyday Self-Loathing That Perfectly Describe Your Life
5 Moments of Everyday Self-Loathing That Perfectly Describe Your Life5 Moments of Everyday Self-Loathing That Perfectly Describe Your Life
5 Moments of Everyday Self-Loathing That Perfectly Describe Your Life
 
Inside Look: Brooke Monk's Exclusive OnlyFans Content Production
Inside Look: Brooke Monk's Exclusive OnlyFans Content ProductionInside Look: Brooke Monk's Exclusive OnlyFans Content Production
Inside Look: Brooke Monk's Exclusive OnlyFans Content Production
 
"Quest for Knowledge: An Exciting Journey Through 40 Brain-Bending Questions ...
"Quest for Knowledge: An Exciting Journey Through 40 Brain-Bending Questions ..."Quest for Knowledge: An Exciting Journey Through 40 Brain-Bending Questions ...
"Quest for Knowledge: An Exciting Journey Through 40 Brain-Bending Questions ...
 
Taylor Swift quiz( with answers) by SJU quizzers
Taylor Swift quiz( with answers) by SJU quizzersTaylor Swift quiz( with answers) by SJU quizzers
Taylor Swift quiz( with answers) by SJU quizzers
 
Holi:: "The Festival of Colors in India"
Holi:: "The Festival of Colors in India"Holi:: "The Festival of Colors in India"
Holi:: "The Festival of Colors in India"
 
The Hardest Part About Picking A Show To Watch (Comics)
The Hardest Part About Picking A Show To Watch (Comics)The Hardest Part About Picking A Show To Watch (Comics)
The Hardest Part About Picking A Show To Watch (Comics)
 
How the fever night scores above your mundane nightlife occurrence
How the fever night scores above your mundane nightlife occurrenceHow the fever night scores above your mundane nightlife occurrence
How the fever night scores above your mundane nightlife occurrence
 
Young adult book quiz by SJU quizzers.ppt
Young adult book quiz by SJU quizzers.pptYoung adult book quiz by SJU quizzers.ppt
Young adult book quiz by SJU quizzers.ppt
 

Agile Development Practices Conference - December 2007 - PDF with Notes

  • 1. 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
  • 2. 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
  • 3. 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
  • 4. 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
  • 5. 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
  • 6. 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
  • 7. 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
  • 8. 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
  • 9. 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
  • 10. 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
  • 11. 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. quot;Sure it works for them,quot; he said, quot;they're huge. They can do anything they want to. We can't do that here. We're not Microsoft or Google!quot; 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. quot;Acceptingquot; our limitations. quot;We can't do that because we're not Googlequot;. 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 quot;...smooth out the edges and go for the centerquot;. I can't accept that. My question back to the naysayers is quot;WHY NOT?quot; 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 quot;Why not?quot;. 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
  • 12. 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
  • 13. 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
  • 14. 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