Agile Development Blog

I have a reason for liking Bob Payne. Bob has empathy and a true love for giving back. That resonates with some of what we are trying to do here in Boulder. Rally, as a B Corporation, has expressly created a charter about giving back to the community: 1% equity giveback, 1% employee volunteer hours (over 2500/year in the last two years) and a number of other local not for profit initiatives. For Bob and us, adopting Agile has  been an important component in how will pull our empathy and our software skills together. With Agile, we seek to deliver feasible, effective, desirable solutions in our complex world. And reaching beyond our corporate walls to deliver that desirability catapults us to being truly empathic in our solutions.

When you meet Bob, you immediately get what “giving back” and empathy is about in his Agile work and beyond. Bob is always looking for new ways to bring Agile to our community and the greater community: our complex world. Out of his own interest in giving back to the Agile community, Bob set up his Agiletoolkit podcasts site. A gift for all of us. At the recent ADP West conference, Bob was there with his sound setup.  Bob took interest in Rally’s Agile Zen acquisition when interviewing Ryan Martens. And I  had the great fun of talking about Seth Godin’s book “Linchpin” that both Bob and I had read.

In this post, I’m so honored to have the opportunity to turn the tables on Bob and be the interviewer.

“Bob, what got you started recording your Agiletoolkit podcasts?”

I began recording the Agiletoolkit podcasts in 2005 after hearing several interesting podcasts and wondering if anyone would be interested in a podcast about Agile. I had always been a gadget person so fiddling with recording equipment and microphones was a natural for me. In fact, I now also have an iPhone App for the podcasts.

I love having the conversations and the podcast gave me an excuse/push to have conversations with people that I might not connect with in the halls at a conference.  A good example of that was when someone said to me, “You have to talk to this guy Arlo.” Without that introduction via the podcast I am sure I would not know Arlo Belshee as well as I do now.

While I am by nature gregarious, I do not search out “networking opportunities”. The podcasts have forced me into a new comfort zone that includes a lot more people from the community than I would have connected with through normal channels.  While I hope people appreciate and benefit from the podcasts, I do them for myself.  That affects the style of the podcasts. Since I am not trying to be polished or create an edited product, the podcasts have a more natural/comfortable feel.  I just wish I said “UM” less and a was little more polished on my delivery. But…I am who I am and it is what it is.

“How did you get into Agile philanthropy?”

Agile philanthropy started as a way of trying to meld my passion for doing good in the world with my passion for agile methods.  Using the power that is evident in the agile community to do great things is one of the goals of Agile Philanthropy.  Ideally we will get to the point that this movement is self-sustaining. But we are really just starting out on this journey.  I hope that I can grow the movement in the direction of local chapters doing work for local not for profits. Right now everyone is very busy and I am the bottleneck.  We are currently working with Mano a Mano and Haiti Partners. And, I would love to have people with a passion for a particular cause to contact me and start up their own chapter.

“What about your other philanthropic interests?”

I am very interested in local sustainable food, economic development and social justice. I volunteer in my kids’ schools quite a bit.  Most recently, I built incubators with the kids and hatched chickens and worked with the teachers to incorporate that into the curriculum. I have been working to get local food into the schools; to create school gardens; and, to relax the laws in Washington DC as they pertain to the keeping of bees and hens. Most of my other work is more directly related to the work I do in Agile Philanthropy.

“When did you start the Mano a Mano project work and what have you and your yearly teams accomplished at the Agile conferences?”

Seems like forever but we introduced Mano a Mano three years ago when the conference was in DC.  I was running the development lab in the basement and hoped that I could get some real work done in the lab that would do some good.  After that, I tried to make it more formal and improve what we have done for them each year.  They have been very appreciative and very patient with us since I am learning as I go with this process.

To date, we have moved them onto a Content Management Platform and developed their iPhone optimized donation page.  Most importantly, I am happy that I have connected Mano a Mano with David Hussman and a number of other volunteers in the Twin Cities that are helping out on a regular basis.  Wayne Simacek showed up for an event that Jeff Patton and Ed Kraay were holding to help Mano a Mano define their web strategy and ended up staying on as a volunteer member of their IT staff.

It is that kind of leverage that I hope to bring by connecting the two communities.

“What do you have in store for us at the Agile2010 conference?”

For the Agile2010 Conference, I am working again with the UX stage to do an Extreme Makeover for the Mano a Mano web presence.  We hope to be able to work on their information architecture and site design to improve the impact of the message that Mano a Mano is putting out. We are looking for volunteers to come by the LiveAid lab and help with the effort (hint, hint).

I also hope to get people interested in replicating this model for not for profits that they are passionate about.

You can do this too

To end this post, I want to thank Bob for the example he sets for all of us. I also want to emphasize Bob’s call to action to get engaged locally. You can do this through your existing local Agile group. Or, you can create a new group with an express charter to give back to the community. Recently Brad Feld here in Boulder wrote about the “Boulder New Technology Meetup” event that supported over 300 people engaged with 20 local non-profits. And here at Rally, we are marching along with Bob philanthopically working to give back: supporting  Intercambrio, donating time to local non-profits (Community Food Share and Growing Gardens) and working with the Salesforce Foundation.

On March 19th, I was fortunate enough to be able to attend 1 day of the  Engineer’s Without Boarders (EWB) National conference.  EWB is an international organization founded in 2002 by Bernard Amadei, my Engineering Geology Professor from the University of Colorado.  EWB-USA has 250 Chapter organization, 12,000 members and 350 ongoing projects; it uses college students and professional engineers to address engineering problems in developing nations.  (Take a look at their Projects section of their web site to search and see some of the great work done by these great volunteers, Chapters and Sponsors.)

In addition to browsing projects, talking with students and sponsors, I was able to catch Bryan Willson from Colorado State University give the Plenary talk.  It was very inspiring blend of my favorite topics; great engineering, sustainability, global change, social entrepreneurship and agility.  His group at CSU has built a number of social enterprises to help commercialize solutions for the large-scale global change.

These three areas of commercialization include:

1. 2-Stroke Retrofit is a fuel injector kit that reduces CO2 in two cycle engines by 90% and increase mileage by 35% for the 100 million engines in the developing world alone
2. Clean Cookstoves are solid fuel cookstoves that can reduces CO2 by 75% and increase efficiency by 35% for 600 million solid fuel, including wood, dung and coal, stoves in India, China and Africa
3. SolixBioFuels – A system for growing and turning algae into bio-fuels that is 7 times more effective than open ponds.

All three of these stories provide proof that commercial mechanisms, social entrepreneurship and Agile Product development can change the way our global society runs.  His team created these innovations by seeing the large-scale systems, collaborating across boundaries and creating something new, not just trying to solve a problem in the current broken system. Finally, his call to action for all the EWB members was to be the eyes, and ears on the street with regard to these solutions in the developing world.  For folks in the Agile Community, you can think of the EWB engineers as the proxy to the customers.  It is not that Mark’s team does not have a test lab, work in small batch cycles or reach into the field to see their products in action, but at the scale of 100’s of millions and scope of these global issues you need all the feedback you can get.   What a great partnership!

I encourage you to explore the EWB, SolixBioFuel and Envirofit webs sites.  I would especially like to thank Cathy, the current Director of EWB-USA, and Bernard for inviting me to attend this amazing conference.  I look forward to future collaborations.

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 just wanted to take this opportunity to thank each and every one of you who follow the Agile Blog.

Jean and I have had a great time writing these posts over the last year, and we are humbled by the way you’ve responded.  After a few years of casual, intermittent posting in our Agile Commons community, we jumped off the deep end into blogging this year by hatching out this site and our Engineering Blog.

We are truly grateful for how you have helped us learn and grow: for every comment, every tweet, everything that you have shared with us.

And we are hopeful that the learning has been a two way street. That is, whatever topics or ideas we posted in the blog that particularly resonated with you, we are honored that you invited us into your 2009 professional journey. In fact, we’d like to see your comments on what you found particularly useful or engaging in this past year. And we welcome your suggestions for topics in 2010.

We look forward to continuing this great conversation in 2010.

Thanks and Happy Holidays!

For 2010, lets find ways to focus on teaching our craft and growing the world of skilled software development professionals instead of trying to figure out who is “right.”

I believe much of the “Escalation” that Jean is seeing was correctly titled by Regina Mullen as a battle to be “right.” (see and read Escalation is Killing Agile – Can We Please Stop It? and Escalation is Killing our Healthy Conflict in Agile). That behavior focuses on carving up the pie instead of growing the pie.   There has been so much added to the field of software development methods, tools and techniques from the guiding ideas of Agile.  Now is not the time to stop and eat.

For me, 2010 is about continuing to grow the Agile software development pie’s reach and innovations.

I believe one of the key fixes to the problem of escalation can be found through increased professionalism and certification in Agile. By raising the bar through “difficult and skills-based certification,” as Brian Marick and the board at the Agile Alliance described, we can advance the Agile discourse through :

• a defined a bar that is deep in skill, knowledge and practice
• a significant enough bar to engage College and University study and examination
• research and curriculum that explore the tough questions in a scientific method
• development of more flexible or “T” shaped individuals that can see and work beyond silo roles.

With this back-drop, I am motivated by the notion of creating a  A Community of Thinkers,:

I am a member of a community of thinkers and I believe that communities exist as homes for professionals to learn, teach, and reflect on their work.

A Community of Thinkers creates more leadership in our profession. I see the expanding certification efforts in 2010 as great steps in these directions:

• Lean Software and System Professional – new certification emerging
• Agile Developer Certification – that is also emerging
• Certified Scrum Practitioner – especially as it intertwines with the PMI’s Agile Community of Practice

I encourage everyone in our community to figure out how to put energy toward one or more of these efforts.  The benefit of actively learning, teaching and reflecting on our work should lead us all to expanding civil dialogue that works to understand all points of view and keep expanding our thinking.  Thus broader education and difficult certification helps create a “Community of Thinkers.”  And, a Community of Thinkers will create a virtuous cycle of win/win and thus a larger pie for all.

That is my hope for 2010 in our profession.

About the Author: Ryan Martens is a happy father,  founding board member of the Entrepreneurs Foundation of Colorado, and Founder and CTO at Rally Software Development. Subscribe today to get free updates by email or RSS.

I had the fine fortune of spending a day with Liz Keogh and Eric Willeke in Boulder last week.

What a wonderful experience! The three of us gathered with the goal of producing something for the Lean and Kanban software community. We didn’t know what that would be. We just knew we felt strongly that we should give something to the community.

We were heavily influenced by past conversations with Chris Matts, his call for “fewer leaders, more leadership”, and a desire to see the Lean Software and Systems Consortium (LSSC) learn from some of the trials that other communities and community-leading organizations have undergone. Ryan Martens, the CTO and a founder of Rally, also provided thoughtful input to our discussions during the day.

As we talked, we discovered something. We were all keenly interested in the general notion of “community”. We became less convinced that the LSSC needed a challenge from us, and more convinced that it was applicable to software communities generally. For me, this was a deeply personal statement and commitment.  It played heavily into my recent blog posts on “Escalation”. And yet, together, Liz and Eric and I found the same deep conviction.  So as you look at the statement I provide below, if it’s exactly the same as the copies on Liz or Eric’s sites, it’s only because their arguments were equally sound and convincing.

Because of that personal nature, we wanted to avoid putting our statement up as some kind of manifesto that people can sign. If you feel strongly enough about this statement that you would want to sign up, copy it. Post it on your own site. Attribute it to wherever you got your copy from – the act of sharing is more important to us than the act of creation – and feel free to change it so that it reflects your own values. I don’t think that any statement like this can ever be perfect, nor will we perfectly live up to it.

I am a member of a community of thinkers. So are you.

”A Community of Thinkers” by Liz Keogh, Jean Tabaka and Eric Willeke is licensed under a Creative Commons Attribution-Share Alike 3.0 License. Please attribute to the distributor of your copy or derivative.

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.

Climate Change due to the increase of carbon from human activity is a “Global problem,” thus it has a couple of unique attributes compared with other world problems:

It affects everyone

You can act on it anywhere

I choose to act on this problem at home and at work.  As part of this action,  Tim and I chose to attend the Society of Organizational Learning’s (SoL) workshop based on Peter Senge’s book Necessary Revolution.

This three-day workshop leveraged long-time SoL content on leadership and mastery into the context of the global climate change.  It was a fantastic workshop that I highly recommend – as it has changed me and my mental models.

Tim, our CEO, Peter and myself at the end of day three

Living in Boulder Colorado with tons of the worlds best climate scientist and a University that helps you Lean More About Climate, I am familiar with much of the science behind climate change.  But, in this workshop we got to take our understanding up to the larger system level through system archetypes, multi-player games and simulations.

On the third day, we played with and did mock negotiations using the climate change system simulators that were built for negotiating teams going to Copenhagen in the next two weeks.   The systems dynamics models baked into the C-Lean simulator are made more apparent in the Seed Simulator on Carbon flows. (It is a simple bath tub model of how carbon flows through the natural system.)

For your information, the answer to the simulation puzzle of putting climate change in check and keeping average global temperature from rising more that 2 degrees involves three things:

1. have all countries in the world (un-developed, developing and developed) reduce there carbon output by 80% from 2005 levels by 2030
2. stop deforestation efforts
3. maximize reforestation efforts

To do this, the world will have to cross the threshold to a new game;  an infinite game of win/win behaviors that measures success based on ecological restoration and social well-being.  Finite game behaviors coming from zero-sum game thinking and patterns of shifting the burden and escalation will have to stop.  I like to think of this an maturation of our species from wildly growing adolescents to young adults.

Peter’s 5th Discipline Fieldbook and The Dance with Change, come with tons of exercises, tools and guest lectures that are all helpful at understanding organizational learning and systems thinking. However, as Peter said in the workshop, understanding the concepts are easy, but practicing them can be much harder.

Part of the success of this public workshop was working with these concepts in a context of a global problem that we all share.  We got to work on ourselves and a shared global issue.   And as a result, we seemed to all have limitless energy and worked from 8:30 AM to 7 PM each day.

I encourage you to visit these sites, they give climate change a face and a shorter feedback loop.  Both of these benefits can lead you and your teams to better understand and more easily act on this Global issue.

Thank you Tim, Peter, Sherry, Darci and all the other great folks who attended our workshop in DC.  I have my joy and I will share it and my personal learning’s from this event in my next post.

About the Author: Ryan Martens is a telemark skier,  founding board member of the Entrepreneurs Foundation of Colorado, and Founder and CTO at Rally Software Development. Subscribe today to get free updates by email or RSS.

Recently, I wrote the post “Escalation is Killing Agile – Can We Please Stop It?”  My passion around escalation brought 40+ in-depth comments.  With my travels and lack of internet access, I had been unable to sit down, sift through, and absorb all the various perspectives.  Until now.

I’m offering this follow-up post as a means to provide an overall response to all these great comments. I want to add some further background on the “escalation” topic and some more of my personal conviction around it. Specifically, I’d like to provide some insights into delayed feedback, the need for conflict, and how to “show up”, all without escalation.

In one part of the comment stream, I heard and felt the call for an effort to get to the root cause of such deep-rooted assumptions.

According to the Systems Thinking Toolbox from Pegasus Communications, to break an Escalation structure, ask the following questions:

1. What is the relative measure that pits one party against the other and can you change it?
2. What are the significant delays in the system that may distort the true nature of the threat?
3. What are the deep-rooted assumptions that lie beneath the actions taken in response to the threat?

So, in our system of sharing information in the Agile community, we have to ask, “Are we setting up a dynamic that pits us against one another?” If this is true, then we have to ask, “How can this be addressed and still ensure that we share insights?”

Guided by Systems Thinking, that means we need to check in with: what is distorting our communications and what might our deep-rooted assumptions be that would have us act as we do?

Here is an example:

I created a delay in feedback by my not responding to posted comments. I believe that created assumptions around what I may or may not have intended in the post.  I think some individuals thought I had written the post pointed specifically at them. Faster feedback would have helped quell that assumption.

I was writing about, and continue to write about, the Systems Thinking Escalation archetype and how I see it in our community. I was and am looking at a dynamic not at an individual. Escalation is NEVER about an individual; it is about the system in which blame is occurring and allowed to continue. I am fearful that blame and the win/lose game are in our system and that is what I do not like and I want to address.

Some of the comments to my post seemed to indicate that I was anti-conflict. Far from it! In studying the inner workings of high-performing teams, I have often referred to Sam Kaner’s model for participatory decision-making. Conflict is a must.

In this model, Kaner insists that, to get to high performance we must bring forth conflict to discover the best informed decisions. Divergent ideas must be invited. Divergent voices must be heard. Divergence must be allowed to just be. That is, don’t just jump to conclusions. With enough time and patience around divergence, we can then move toward informed convergence.

Conflict in this context is dialogue. It seeks insights. It invites greater and greater participation. I also want to emphasize that in this context of dialogue and non-escalation, our purpose is to engage in forward thinking. We let go and we look forward. And as we look forward, we let go.

So, as a member of the Agile community, my interest in expending energy in discussions is to seek insights, encourage divergence, and discover convergence as it emerges. All of these practices help and encourage me to create more and more forward thinking. If this is not occurring in our community, then we are not getting enough for the energies we expend.  If in our community we really “must win”  in order to “be heard”, we are stuck in an “Escalation” archetype. And, that means we are all trapped on an up escalator to nowhere.

What could any individual do to break an escalation pattern in a system? Create energy around your insights and share them without a need to apply win/lose stakes. Stop expending energy to refute others.

Here is a simple formula for bringing your viewpoint to bear without escalation:

1. Show up. (Be willing to be engaged.)
2. Find out what has meaning to you. (Be willing to be honest about your perspective.)
3. Tell your truth. (Be articulate about your insight without attacking or assigning blame.)
4. Let go of what happens. (Be courageous enough to allow others to agree or disagree.)

I believe this formula provides guidance on how to remain forward thinking, remain open-minded, and remain engaged.

I have some more mental models I want to offer here. But they will wait for another post.

Thank you in advance for your considerations, insights, and comments.

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.

I was raised in the land of big software releases.

I spent over a decade celebrating the release of software to gold master at five different companies.  These events included plaques and various levels of behavior based on the amount of flesh that was lost in the release.  A few of them were great, but many of them left a bad taste in your mouth based on what was shipped or not shipped.

Early on at Rally, it was the same way.  We celebrated releases.  In our case, the numbered releases come about every 6 to 8 weeks.  I can recount having some over-the-top release parties, but mostly they seemed empty.  Now, we have moved to a world of release lunches.  These lunches now come after our retrospectives allow us to close the cycle well.  I do not consider them celebrations as much as a way to close.

Now we do something quite different, we make fun and celebration part of the agenda for every release planning.  As a result, we have events spread throughout the release and in many cases tied to holidays.

For example, here are three of the “scrumkins” entered in the Halloween contest.

In another example, last week we had Formal Friday.  Formal Friday involved everyone wearing some type of formal wear to work.   In a software company with T-shirts and shorts the typical attire, it was quite a shock to see many of our team members wearing a tie.  I honestly thought there was a funeral.  See for yourself.

Jeff's Pink Suite was the unanimous favorite

These examples of celebration build teams, trust and relationship much more that the big bang events of the past.

The source for this change started back in 2005 when we had a great Technical Advisory Board.  At one of the meetings Luke Hohmann game me a copy of Managing to Have Fun by Matt Weinstein.  It is a great book with some great ideas.

At this same time we also hired Melissa Gallegos onto our team.  Melissa moved from a role in QA to become our ScrumMaster.  She runs release planning and scrum of scrum meetings.  I shared Weinstein’s book and some ideas with Melissa as she started to move into the role.  In 2007, as Melissa began to get her stride, she became the official Master of Fun at Rally.  Melissa is a natural; as demonstrated by the blow-up palm tree and tons of toys on her desk.

So I ask, who is your master of fun at your company?

At Rally, we tend to celebrate as a company based on external validation.  External validation includes awards, product reviews, customer feedback or financial performance.  We do this because external wins are a whole company effort.  We focus on closure and managing to have fun in the teams because Chris Avery and others proved to us that the key to high performance teams is trust, relationship and shared purpose.

Happy Halloween! enjoy the Day of the Dead and your own celebration.

About the Author: Ryan Martens is a mountain biker, founding board member of the Entrepreneurs Foundation of Colorado, and Founder and CTO at Rally Software Development. Subscribe today to get free updates by email or RSS.

Last week at Agile 2009, I attended a great panel discussion with previous winners of the Gordon Pask Award.

For those unaware, the Agile Alliance states that “The Gordon Pask Award recognizes two people whose recent contributions to Agile Practice make them, in the opinion of the Award Committee, people others in the field should emulate.”

Rally’s newest Coach Aaron Sanders facilitated this 90 minute sessions in three blocks: (1) Q&A with the award winners, (2) Q&A with the audience and (3) reflections by the award winners.

Here are some of my favorite insights shared by the panel:

Laurent Bossavit

• “Situational Learning concepts are important as people move beyond agile-by-the-book”
• Here to drive more innovations in “Diffusing agile into the organizations quickly”
  

Jeff Patton

• I am focused on coaching as agile has moved beyond selling into “How to do it.”
• Next up – practices for the product/business side to help them build “just enough”
  

J. B.  Rainsberger

• “I am interested in complex selling concepts as agile is trying to spread up.”
• BDD is just TDD done right (unit and acceptance/story test driven development) – pushes the focus to design and drops the word TEST – this is good.
  

Bob Payne

• Chicken’s and Pigs hurts when trying to create “One Team.”
• What’s Next – Create an “Agile Philanthropy revolution”

Arlo Belshee

• Us versus them – beat them is a human fear response
• Middle managers are often scared
• People who are advocating more then asking – are hard to build trust with
• Next for me is “Whole Company” and Governance strategies
  

  
  

  (Last year’s winner Kenji was not at the conference, but you can read a great interview with him on Aaron’s blog -  Interview with Kenji Hiranabe – 2008 Pask Award Winner – it gives you more of the flavor of the actual session)

It was great to see that they all had meaningful answers to the question regarding how the award had affected them.  Three cheers to Brian Marick for idea and Three Cheers to the awardees for making something out of it!  The highly interested members of the audience included Jean Tabaka, Esther Derby, Rachel Davies and about 20 other folks.

If you have not been to an Agile Conference, this kind of intimate gathering is common and why so many people come back year over year. It’s sessions like this that have helped Agile 2009 become such a wonderful mix of new and old, small and large as well as academic and professional.

I look forward to seeing Simon Baker & Gus Power from the UK and David Hussman, the newest Gordon Pask award winners, using their award to extend their influence on the industry.  Congratulations gentlemen and Congratulations to the team of volunteers that put on another strong Agile Conference.  See you in 2010!