Your SlideShare is downloading. ×
Agile Development Practices Conference - December 2007 - PDF with Notes
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Agile Development Practices Conference - December 2007 - PDF with Notes


Published on

Recently, I was privileged to speak at Rally Software Development's Customer Summit at the Agile Development Practices Conference in Orlando. I gave a talk called Becoming Agile. It was a brief talk …

Recently, I was privileged to speak at Rally Software Development's Customer Summit at the Agile Development Practices Conference in Orlando. I gave a talk called Becoming Agile. It was a brief talk about our team's transition to agile. It follows our team's agile journey from our humble beginnings to our exit from our old organization and our new home here at Data Transfer Solutions. I've uploaded the slide deck from the presentation with notes so that you can read what was presented. I hope you enjoy the presentation and I would really appreciate any feedback or comments as well.

  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 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