Agile Development Blog

On the road to Agile adoption, I often get asked, “how do you get teams spun up on Agile fast?”  The short answer is to just do it. The long answer is that I believe there are 3 options. 1) Rally and other Agile coaching organizations offer programs that place a coach in your team to help with preparation, planning, estimating, setting norms, committing, tracking, daily stand-up, demonstrations and retrospectives. 2) You can take the DIY approach,  but watch out for the unintended consequences.  3) Finally, I think there is the intensive practice approach.  Let me give you some examples:

A Sprint Per Day for the First Week

While speaking and attending Agile Vancouver in 2008, Linda Rising facilitated a fishbowl exercise with a custom development firm in Vancouver.  Given they were starting and stopping projects and reforming teams all the time, they had developed an approach to speed the team through the formation process and inculcate new team members (employees and customers) to the process.  The would run a scrum sprint every day for the first week.  This intensive process would allow them to work through tons of issues in a very intensive week.  I would call a form of this preparation over planning.

A Sprint Every 90 minutes for a Weekend

If that is not fast enough for you, how about a sprint every 90 minutes?  That is what the folks at SnapImpact did last weekend in Boulder at their SnapCamp (based on the notion of Startup Weekend).

I heard about this from one of the organizers and fellow Sprint Triathlete Dave Angulo.  Dave is co-founder of the non-profit SnapImpact, a guerrilla non-profit that has a mission to “Make Doing Good Easy.”  They developed an iPhone application and WordPress plugin to simplify how people learn about volunteer opportunities near them.  It takes feeds from HandsOn Network and soon All for Good. It is cool, I’ve been playing with it for a year.  Anyway, ran into Dave at a CTO lunch in the TechStar’s bunker today and he told me about the wild success they had with 90 minute sprint process through the last weekend.

To give some background, SnapCamp was the kickoff effort for developing v2.0 of All for Good, the platform which powers http://serve.gov and a number of other sites. It’s the largest single repository of volunteer opportunities in the world. Version 1.x was pushed into production quickly and, while it is up and running, there have been a number of technical limitations which have frustrated All for Good’s partners and limited the platform’s usefulness. SnapImpact offered to develop v2.0 of All for Good because of the close alignment of the two organizations’ missions and their desire to have a more comprehensive list of opportunities for their iPhone app.

Dave - We started the weekend with dinner on Friday night to allow time for everyone to meet each other, learn about each other’s backgrounds, and have a shared group experience. We had people from all over the country as well as a great local contingent. Some were die-hard SnapImpact volunteers, others had only heard about us recently. The dinner allowed for folks to get to know one another in a casual setting without having to do it in between trying to get work done.

Saturday morning, we laid out the business problem, context, and goals for the weekend, then I announced we would do 90 minute sprints. The business teams (we had marketing, UI, and product teams as well), would adhere to the same schedule. The beginning of the first sprint for dev was spent laying out four areas of technical problems and having the team self select into what tickled their fancy. Everyone then got to work. I moved between the teams to discuss possible technologies for them to consider and dive deeper on the problems they needed to solve. The volunteers then took over and by the end of the first sprint everyone had a handle on their problem areas. Most even had a initial plan of attack.

Everyone has heard of Forming, Storming, Norming, and Performing. With 2 days to get work done, we had to get them to performing as quickly as possible. The dev teams were all about 3 people in size with differing skill levels and familiarity with the technology stack we were using. The 90 minute sprints forced a tempo which required the teams to get to performing quickly – no one wants to report out nothing was accomplished. Yes, some of the progress initially was small, but these were hard problems to tackle in a weekend. I had one team who’s requirements were being developed by the business team through the weekend, some sprints the deliverable was “received requirements from business and developed a response.”

By the end of Saturday, all of the development teams had produced something which was merged into mainline for the other teams to pick up. That was huge and everyone could see the bar moving.

Sunday started with a review and then everyone picked up where they had left off. The development teams reformed and started working before we even had the morning review. The pace on Sunday kept accelerating, merges occurring after every sprint, until late afternoon, when we started winding down.

I have run many volunteer projects. The SnapImpact team had actually completed one earlier in the week involving several hundred people with BDNT, and it’s absolutely critical volunteers feel like they are moving the bar. Given the scope of this project, it was going to be very easy to have volunteers lose sight of the progress they are making and give up. The 90 minute chunks with progress review and planning helped ensure the volunteers didn’t lose sight of the progress we were making that weekend. As project owners, we had goals of our own on what was going to be delivered at the end of the project. The sprints allowed us to keep moving in the direction we needed to go as well as identify trouble areas.

Dave – Training – One decision I made was to use a relatively new technology stack, Scala/Lift, for the framework. Instead of holding a formal training session for those unfamiliar with it, I made sure there were experienced people in each group and let training happen “on the job.” I think next time it would be better to do a short training session, as given the pace, sometimes that training disrupted forward progress. Just the basics, so when a concept was discussed it wouldn’t be completely foreign.

Deliverables – We got sloppy during the reviews and didn’t nail down specific deliverables for teams. At times, it caused teams to lose focus during the sprint. The reviews were every 90 minutes, so the lack of focus was caught sooner rather than later.

Insert more fun – Because the tempo was so high, I’m not sure folks had as much fun as they could have during the event. I’m a big believer in fun being central to any successful project and I think teams could have bonded a little more and we may not have been as exhausted by Sunday afternoon. There was some fun, we just needed more.

Dave – Our goal was a beta of existing functionality by the end of the weekend. We’re very close to that now, but some decisions made during the weekend prevented accomplishing that goal. The SnapImpact team is continuing development and once the existing functionality is in place we’ll start working on a host of new feature requests from the business team. We’re entering all of that information into Rally now and beginning the planning process. Folks will see v2.0 at http://allforgood.org in June.

Dave - Preparation started weeks in advance. My role in this project is CTO and VP of Engineering. So, the 3 critical things I needed to accomplish before the weekend started was making sure I stacked the deck in my favor with some talented people, had a toolbox ready with possible solutions to the technical challenges we would face, and had stakeholders present to make decisions.

Given the new technology stack, I needed to recruit folks with some very specific skills. To enable that effort we recruited the leader and founder of the Lift project, David Pollak. He helped us motivate a few people with experience using the technology. We also had the SnapImpact team actively recruit their friends. The result was a very high quality team capable of getting the job done.

When the teams started work, they would spend too much time investigating everything unless I gave them a starting point. By bringing some ideas (not solutions) to the table to solve their problems, it helped define their playing field and allow them to make a decision quickly. Implicit in this was understanding the known business problems that needed to be solved.

We knew we would hit roadblocks during development waiting for business input on implementation details. So, we made sure to have some present the entire weekend. One of the stakeholders even brought a developer who was using the existing system. We embedded the dev in one of our teams working on implementing some external interfaces. Yes, that really accelerated the implementation decisions. Also, the stakeholders were really disappointed with certain aspects of the existing system. We had ideas to resolve those issues, but needed to ensure they met the stakeholders needs.

Thanks Dave for the great details on this event and example of agility at work!

Right now, I’m watching a company try to improve itself.

It seems that management has recently learned that there is a thing called Lean, which even comes with some cookbook recipes called practices that you can do. There is lots of nifty new lingo, and it’s complex enough that you can interpret it nearly any way you choose

ShuHaRi - stages of learning that lead to mastery

This company has reason to believe that they have some understanding of this new animal because they feel that they’re already Agile, but as far as I’ve been able to determine there is nobody involved who has, lets say, an actual resume chock full of actual training and experience in Lean. The employees are pro Lean because (a) they always validate what management wants, (b) they want it, too, and (c) they think they understand it.

And I find myself thinking, “This is not right. You are doing these practices in ways that I have never seen discussed in any of the books or courses with which I am familiar, and I have put in some time studying this stuff. You are tossing ideas around like you really understand them, and I do not think that you do. Worse, you’re starting out with complex new ways of doing it rather than start at the rock bottom with the basics. This is bad!”

Then I have an opposite thought, which is something like, “Hey. What are they supposed to do, sit around reading books for five years before they try something? That’s just another form of analysis paralysis. Go for it!”

Then my coach brain kicks in (by now I can feel my brain cell overheating, but I persevere), asking me -  How may DIY (Do-It-Yourself) Agile implementations have you seen? (Answer: A lot) How many had great results? (Answer: Few) How many sucked? (Answer: Most) I am suspicious of DIY Agile and DIY Lean because I have seen too much badness there.

Enter Shu, Ha, Ri – a concept first introduced to the Agile world by Alistair Cockburn. The phrase is used to describe the three stages one goes through when pursuing the mastery of a complex art.

Shu, the beginner stage, is where you know nothing and you limit yourself to a rote application of very simple practices.

Eventually you reach the Ha stage, where you can stop concentrating on the simple application of techniques and graduate to the skillful execution of complex techniques that follow the known rules of your discipline while handling exceptions and even new situations.

Then, and only then, can you aspire to Ri, which is where you forget everything you know because you are beyond thinking about it. Here you transcend rules and blend techniques in artful and unpredictable, yet “correct” ways. (For me, this is the stage where “you can do it drunk”, though others may choose to describe it differently).

So returning to our story – here is the behavior I’d like to see from this company.

I want the company to reach and stretch, but I also want them to do it right. I want them to have a realistic understanding of who they are, and at the same time, not allow that understanding to deter or slow them down. How would that be possible? There’s only one answer that I can get to, and it is that you have to both act and study if you’re going to do either one effectively. Go ahead and leap right in, grab the marmoset by the tail and go for it, just don’t forget to do your homework too.

If I could talk to the management of that company, I’d urge them to get expert training for their people and to slowly, methodically, and gently yet firmly allow the company to move in the new direction. And I’d want them to make sure they are getting it right. It’s too easy to make this stuff up, and it’s too easy to bulldoze employees into following you down a path. Who’s going to argue with the CTO or the CIO or the CEO? Not many people will do that.

So I say, be humble. Bring in the consultants. Get the training. Keep trying new things. Be open to failure and to admitting wrong-headedness. You’ll make it. Just be balanced in the learning and the doing.

That’s what I think, anyway.

About the Author: Alan Atlas is a Musician, Certified Scrum Trainer, and Agile Coach at Rally Software Development. Subscribe today to get free updates by email or RSS.