In my first post I said that agile adoption reminds me of my personal experience in competitive sports. The pain was so intense at times, it left me physically and emotionally spent. But with a bit of determination, the gain was always much bigger. These experiences are much like my own experience transitioning to agile development. Here’s the rest of my story:

Here I was a Project Leader at a new company.  My leader walks up to me and says, “So,
there’s this new thing called agile development and we want to try it.  Are you up for piloting it with your project?”  Being the newbie and not wanting to start off on the wrong foot, I said “sure.”   He handed me the book, Agile and Iterative Development: A Manger’s Guide by Craig Larman, an introduction to the different agile methodologies such as Scrum and XP.  From that book and the Agile conference in Calgary that year, I was off to see if this thing was worth its weight in gold.

A year later our entire dev group converted to agile development…we were on our way to the promise land!  I’m sure this is no news to you… it was painful.  I’m here to tell you the gain was worth it!

At first it was great. We had this new-found vigor and vitality that agile development was going to be the “silver bullet.”  No more late projects; the business was going to be completely involved, and all the team members would rise to the occasion and be overly zealous to try this new thing.  And then reality set in.

The pains…

  • The agile bus left the station but not everybody was on it; and some who were should not have been
  • When people get “set in their ways” it’s hard to change them or convince them to change; change is hard
  • The business could not always give us 100% of their time; they had day jobs
  • We floundered around for a bit before we got our footing… no one is perfect right out of the gate
  • Did I say change is hard?

The Gains….

  • Delivering valuable/quality software to the business early and often – once they get a taste, they want more!
  • Collaborating with the business to ensure you are delivering the right things…having a prioritized backlog and knowing what absolutely had to be done was pretty cool
  • Coming together as a team to figure out how to work and deliver; we were free!  Not “cowboy” free, but able to decide how to get the work done
  • Infusing quality throughout, not just at the end… our testing folks were ecstatic to be included from the start
  • Releasing incrementally because we could!
  • Having Fun! Let’s face it, we spend a lot of time at work and if you can’t enjoy
    yourself, it makes for a long day

Not everyone is going to experience the same “pains” and “gains,” but I’m here to tell you that I have no intention of ever going back to life before agile development.  I’ve seen too many positive business gains, and I’m here to stay!

Read Part 1

Join the Discussion

    • Magnus

      Do you have any advice on how to overcome the pains you experienced? How did you encourage people to change? Were the gains, and time, enough to motivate people in the end?

      Another pain, related to resisting change, is the transition to cross-functional teams. This seems to be a big issue for many teams going agile. People are not used to get involved in things outside their core expertise. In Scrum at least, this leads to crippled sprints: it becomes difficult to select stories if tasks are tagged to people. People start to procrastinate when finished with “his” tasks, and you start trying to pick stories to get a good balance of work between team members

      • Luanne

        Hi Magnus,

        At first we did the standard things: brought in training, got our leadership introduced and on board, made organizational changes, and physically changed our workspace. This helped a great deal and allowed us to focus on the more “softer side” of the changes…the people. When we created our teams leadership looked at various team members and tried to match up initially members who could leverage the leadership and skills of others. We did have to make a few adjustments but overall that was a good move. There were folks who could not make the transition and they moved, which was good for both the company and them. After that we started to put things in place internally to share our experiences, bring in the experts, and give team members a chance to identify pain points that still needed adjusting. But I think the best thing that I did as a ScrumMaster/leader/servant was to listen and observe. I knew who was struggling and who wasn’t so again, I tried to leverage those who got it with those who needed more time to process and make the transition. I would also talk with individual team members periodically to get there feedback and see what I could do to encourage and help them. What I quickly realized was the more the teams self organized and made decisions themselves, the easier it became to for them. Not everyone got there….and I really didn’t expect them to but that is normal and I just accepted that and focus on helping the ones who were willing to at least try. One final thing we did is a lot of team bonding activities both during and after work. I can’t tell you enough how important it was for us to build our trust and confidence in each other and what better way to do that than having some fun!

        Regarding your comment about cross-functional teams and the pains there. We too had issues and I see it all the time…we have spent quite a bit of time and money getting folks trained and to be experts on certain aspects and then we tell them to now be generalists. Easier said than done! What we ended up doing is a lot of pairing up of developers to cross train them. Eventually they could take on different tasks but again, it took time and energy to make that happen. As a leader, I kept my eyes and ears open to opportunities to get folks out of their comfort zone and the team caught on and started to as well.

    46 + = 50