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!

I have a systems archetype in mind that is troubling me. I am annoyed that some of the current (and past) one-ups-man-ship around Agile is distracting us from the useful constructive dialogue I crave.

The archetype I am thinking of “Escalation” is where “my fix is your nightmare and you have to lose in order for me to win“.

Situations can get sticky with too much escalation

Think of the American movie “A Christmas Story” about young Ralphie Parker and his own dilemma with “Escalation”.  In this classic scene, Ralphie’s friends Flick and Schwartz dispute over whether a person’s tongue will stick to a frozen flagpole. Schwartz ultimately issues Flick a “triple dog dare” (the most serious of childhood dares); bypassing “triple dare” and resulting in a serious breach of boyhood protocol.

Dares, blames, accusations and hard stances all contribute to the distraction and destruction that is associated with “Escalation”. When everyone is trying to win, the system suffers. Anyone’s “win” is nobody’s win; and anyone’s “loss” is everyone’s loss.

I see no place for this in Agile and yet the fight is on. Triple Dog Dares are becoming business as usual.

Escalation is Killing Agile.

So why the heck are we involved in so much escalation around things like “My Agile approach is better than your Agile approach” or, “Well, you’re only in it for the money” or, “I’m going to make fun of you until you stop what you are doing“?

How is ANY of this furthering my growth or our organizations’ growth in Agile?

In a systems view of the world, we can see patterns made up of balancing loops and reinforcing loops. In the case of “Escalation”,  we see factions sucked into a downward spiral reinforcing loop of fighting. The more someone fights, the more the fighting continues.

In our case, the fight may be about certification, or timeboxes, or engineering practices, or continuous improvement, or tools. Fights then lead to blaming and finger pointing. And in the systems view of things, once you get into blaming individuals or other parts of the system, your system is broken. Not the individuals, the system.

So in our Agile world, I ask, “How is this fighting useful? Could someone explain that to me? And how is it our system has metamorphosed into one that allows (encourages?) blame and mockery, one that remains so, or even worse, seeks to move further and further into this archetype?“

For me, a more useful approach is to find balancing loops. Here, we seek to create more knowledge in dialogue not blame. We seek insights with others interested in dialogue, not in escalating debates and accusatory blame. We look toward inquiry versus advocacy and so we seek people interested in this kind of work, not fighting.

One way I intend to take advantage of balancing loops is to seek people interested in Agile growth NOT in attacks on approaches or individuals. I’m thinking, for instance, of Linda Rising as a good example. Linda has been our steadfast beacon of reaching into kindness versus violence or fear or confrontation to use our personal perspectives usefully and creatively.

I’m done with all the distractions that don’t feed my growth. I’ve lost the ability to abide behaviors that don’t give evidence of what was written with conviction in the Agile Manifesto. The train has left the station on a number of initiatives within Agile, Let’s stop fighting them. More fighting isn’t going to make anything go away. Instead, we will just feed “Escalation”. Let us get on with where each of us can find and contribute to growth. Please.

Here is my personal commitment going forward:

My personal commitment is to seek those interested in creating more and more insights about how we can grow and learn. I will seek dialogue around various Agile approaches and what can contribute to the growth of Agile. I will not take delight in anyone’s cleverness or meanness toward an approach they don’t support. I will seek voices of engagement, deeper intention, non-blame, and creative inquiry. “Escalation”, to me, is like the old joke of trying to teach a pig to sing: it only annoys the pig and it frustrates you. I have no intention of spending time with such activity in Agile.  It distracts and annoys me. You’ll have to figure out for yourself how it serves you or hinders you.

So, moving forward, let us think about true dialogue. Let’s challenge ourselves if that is what we invite in each of our interactions. To add encouragement and inspiration, think about the etymology of the word – dialogue:

From the Greek “to gather reason through speech, usually between two people“. I invite each of us to reach for gathering not escalating.

Without this intention, we will all lose.

About the Author: Jean Tabaka is a wine enthusiast, author and Agile Fellow at Rally Software Development. Subscribe today to get free updates by email or RSS.