Agile Development Blog

I just played our fourth Agile portfolio planning game with a team of executives. First they had to rank and plan a portfolio of new product ideas, enhancements, architectural refactorings, and other work. It’s tough to balance competing priorities against strategic financial targets. Then we simulate a monthly steering council that must react to new learnings, development mishaps and market changes, all while maintaining strategic alignment.

I’ll give you a hint to winning the game:  Turn that waterfall team into Scrum teams early, and pay attention to quality.

Wagged by Plans: Is It Time to Change?

Do any of these problems sound familiar?

Execs play an Agile steering game

• The organization funds all or most proposed projects, and expects to make progress on them all simultaneously.
• Teams adjust each iteration based on new learnings, but the annual plan for the organization does not change.
• Teams adjust, but it’s hard to know whether the adjustments throw the portfolio off-goals.
• Projects are managed within silos; trade-off decisions are not made across the portfolio. As a result, some silos are under-capacity and others are overcapacity. Or, the whole doesn’t add up to the strategic objects for the organization.
• Teams are judged on their ability to deliver value; the portfolio is judged on its ability to meet plan.

If these scenarios apply to you, you’re probably ready to bring Lean and Agile principles into your portfolio management process. Especially if you have already solved these problems:

• Your Scrum teams are cross-functional and persistent and have learned to deliver consistently on iteration and mid-range commitments.
• Your Kanban teams have reduced significant waste in their value stream and consistently deliver to service level agreements.
• Agile teams have achieved a fairly consistent velocity/throughput (amount of work delivered per timebox) while delivering against quality goals.
• The Product Owner group elaborates requirements just-in-time, feeding teams a steady stream of high-value work.
• You have added the structures that enable multi-team programs to coordinate dependencies and deliverables within a closely related group of teams.

In working with earlyvangelists to develop our Agile Portfolio Management solution, we learned that in most organizations the portfolio is managed under the old, plan-driven paradigm, which is at odds with the Agile practices at the team and program level. However, it is equally clear that we cannot begin to challenge that paradigm before we’ve reached a certain level of Agile maturity.

It is too hard to engage the business before development has a track record of success.

It is too hard to build a realistic roadmap before teams have developed a steady velocity.

It is too hard to emphasize steering before teams have the discipline to deliver iteratively and incrementally.

Advance Your Agile Practices: The Agile Enterprise
Our early work delivering the Agile Portfolio Steering service has been exciting.  Fellow coach Isaac Montgomery and I have watched a room simply buzz as a group of leaders begins to imagine and employ the paradigm shift from plan-driven to value-driven portfolio management.

The buzz begins because of the people in the room; namely, a cross-functional group of leaders (directors, VPs, SVPs) from the business, product/portfolio, and technology. Together, we explore and understand the current challenges around building realistic roadmaps, tracking the progress of initiatives, and leveraging the agility of teams without losing focus and alignment. Sometimes this group has never built so shared a view of the organization.

There can be a moment of frustration when we’ve made the challenges so clear. But then the energy gets high as Isaac and I begin to provide possible solutions in the form of Lean practices. Together we dig into redesign their portfolio processes, to inject the visibility, feedback, governance and focus that enables Agile to work at scale.

Rally has already begun to see patterns in the Lean practices that implement more adaptive portfolio management.

• Map the value stream from concept to cash, and build a Kanban board to represent those states. “In Development” is just one state.
• Limit work-in-progress on that board. Fewer initiatives in play means better throughput, productivity, time to market, responsiveness, and reduced risk.
• Emphasize value and budget over cost estimates. This requires new data and a new mentality.
• Provide clear strategic objectives  and constraints, and then let the people closest to the work (the teams) plan the work. Use clear visualizations and data to verify the results align back to the strategy. Help teams adjust as necessary to remain aligned.
• A rolling wave cadence of planning and steering helps your leadership be both strategic and adaptive.
• Effective portfolio management will require planning and learning at different levels of the organization, on different levels of abstraction and strategy, and on different cadences.

The Service: Re-Tool for Agile Portfolio Management
Built on those early deliveries, I’m excited to now offer more generally our Agile Portfolio Steering workshop. I think it provides a powerful benefit through focused work.

Inspired by the lessons of the portfolio planning game, the leadership group works with an Agile coach to begin to redesign its portfolio management process:

• How could we have better value data on proposed projects?
• How can we decide our investments rather than be wagged by cost projections?
• How could we fund fewer projects?
• How could we commit to goals rather than to lists of features?
• What data would we need to be able to steer the portfolio effectively?
• How often should we steer the portfolio? A project? A program?
• Could we reorganize our teams to enhance flexibility?

The outcome might be a new planning process, new data requirements, new progress visualizations, new planning and steering councils, and more.

The service is listed as “2 days”. In reality, we have learned that a leadership group might not spend two whole days in a room with us, but the hours they commit will be intense, with short breaks and working lunches, because this work matters. Dollars are at stake; business success is at stake. We will work together to design the right on-site session.

Stay tuned for more details during our Dec 6 and beyond launch events. We look forward to working with your organization, to understanding your context, and what challenges you have to align the work of your Agile teams and your strategic goals. What prevents you from delivering all the value you could to your business?

As Rally’s “Solutions Evangelist”, Ronica Roth promote solutions for our customers that combine product and process. She also promotes fun that involves mountains and snow.

Thousands of Rally Subscription administrators received the following email today. It is about a major upgrade in our community, support, help and training infrastructure. I am sending it our blog readers because I assume you may be very interested in these changes at Rally. I am also trying to open another channel for feedback regarding this email. While this email was targeted to our subscription administrators, I wanted to give you a channel to express your support or concern with us emailing you these kind of major service announcements. We did this because it is a set of changes that will affect all your users. Would you like us to continue doing this?  Should we expand the list to all Rally users?  Your feedback would be invaluable.

–

From the time you begin using Rally’s Agile lifecycle management solutions, you have access to a wide range of resources to ensure you get the most out of Rally and to get the most impact from Agile methods and practices. In keeping with this core value, Rally is upgrading our online Help, Training, Support and Community sites to provide more features, content and searchability. You may have already noticed these sites evolving over the last few weeks. Our goal is to roll out these changes incrementally and thoughtfully so that you experience new functionality and content, not broken links. If we missed something along the way, please let us know.

What’s in it for you?

• Our new Support Knowledge Base brings you how-to’s, best practices and FAQs on specific Rally actions and processes.
• More robust Help greatly improves the accessibility and searchability across Rally support resources. Check out the new task-driven menu structure, quick links to our most popular content, and articles from our coaches.
• Single source of connectors, apps and support materials lets you search and find a connector or app, install it and read support documentation in one single location.
• Coming Soon! You’ll get another email at the end of the month outlining additional resources, including a new Support Portal that will provide quicker access to information you need on a daily basis.

Quick links:

• Search the Rally knowledgebase for FAQs: http://support.rallydev.com/kb
• Browse Help topics: http://www.rallydev.com/help/
• Browse Rally’s catalog apps: http://www.rallydev.com/help/use_apps
• Learn about the latest Rally features: http://www.rallydev.com/productblog/
• Submit a support case: http://www.rallydev.com/support/support_case/
• Vote and interact with Rally’s Product team: http://ideas.rallydev.com/

This structural transition should complete by the end of September, and you will receive one more announcement to provide you the full set of links. We plan to make further enhancements to this new community platform and properties, while we reposition Agile Commons to become a do-it-yourself Agile resource site for more than Rally Customers. We are excited for you to be a part of this transition. Please feel free to send your suggestions to community@rallydev.com.

–

Ryan Martens is CTO and founder of Rally Software, a recovering Entrepreneur-in-Residence at the Unreasonable Institute and chief promoter of the Entrepreneurs Foundation of Colorado. You can follow him on Twitter @RallyOn.

Establishing an upfront, common understanding of “done” that suits the unique dynamics of each development project can be one of the most critical activities for Agile teams. With a consistent meaning of done, agreed to by the whole team, velocity or throughput becomes more stable – allowing your team to make and meet commitments, establish priorities and plan iterations.

We recently hosted a webinar entitled “Defining Done: Creating Velocity without Debt,” to discuss how a common definition of done lays the foundation for focusing on business value while avoiding technical debt. Although we enlisted Rally’s expert coaches to answer the hundreds of questions that pored in from over 2,200 people around the world who joined in, we wanted to spend some more time providing in-depth answers to a few of the questions we received. Below is a video with answers to some of the tough questions about the definition of done:

I also put together a presentation that goes into more depth about what your team can learn from burndown charts.

We hope these resources help you come up with a definition of done that suits your unique team and project. Have more questions? Feel free to post them in the comments section below – we’re always thrilled to continue these discussions with the Agile community.

Zach Nies is a CTO at Rally Software and a proud member of the Boulder/Denver Agile community for the last ten years.

We have all felt the pull of game play mechanics in software. You might be addicted to Angry Birds, Farmville, Foursquare or Mafia Wars? Or, maybe like me, you felt compelled to ski a couple extra runs this year thanks to the Epic Mix from Vail Associates. In either case, the achievement leveling and badging associated with the “gamification” of this software has most likely had some impact on your behavior.

Nowhere have I seen these techniques applied to software like I have experienced in StackExchange, a network of Q&A sites founded by Jeff Atwood and Joel Spolsky. Most of my experience is with the Project Management StackExchange, but there are 51 public sites and over 50 other domains emerging. Thanks to smart work by the StackExchange team, the leveling and badging mechanics are used to pull you into an ownership position with the community. As you earn reputation points, you are granted more privileges on the site. This progressive enablement of editing, voting, chatting and commenting capabilities seems perfectly matched with my gaining experience of the culture and ethics of the site. The more I use the site, the more I find myself developing a real sense of ownership and responsibility to the community. This is simply beautiful software for building a community of experts.

My positive experience with StackExchange has been echoed by a bunch of others at Rally. In fact, after playing with site back in March, Rally decided to partner with StackExchange to help share the knowledge from our inaugural RallyON Conference. Specifically, we started working with the project management and programers sites, as they have good coverage of agile, lean software, scrum, kanban, test-driven development, and continuous integration topics.

I encourage you follow our lead and try out StackExchange personally and with your agile teams. I think you will find it to be a great community for capturing and sharing knowledge on agile. Don’t miss Jean’s recent post, “Life in the StackExchange Lane,” to hear about her first month with the site.

Click to register for the webinar- Defining Done

For us, StackExchange is quickly becoming an indispensable community building tool – let me tell you the story and why we are going to use it to clear questions for the next event in our agile webinar series! To get started, please see this example question on pm.stackexchange.com – “How do you define “Done” on a project?” To see how the StackExchange community is preparing for this experiment, you can view the question - “Growing the site with a new experiment” in the meta section of pm.stackexchange.com.

To understand the rational for all this work I want to explore three areas: First, recognizing what was not working for us in our community;  Second, appreciating the stack overflow approach behind StackExchange; Third, comparing and contrasting StackExchange with other Q&A sites.

It’s hard to build a general community, but we need to

Since 2004, we have been a provider of agile solutions through the combination of products and services. For our customers, Rally and its partners deliver large and sustainable gains in software development time-to-market, quality and productivity as well as increasing the sense of purpose and joy on teams. To increase the impact of agile for our users who are spread arcross 100 countries, we launched a social community in 2006; Agile Commons.

Agile Commons provided an open platform to encourage dialogue and discussions with our users and others in the community. Of course there are many places on the Internet to have these general discussions. As a result, the parts of Agile Commons that really took off were those more closely associated with Rally specific content. We just did not have enough traffic to clear the questions with well thought out answers that really covered a problem space. As a result, Agile Commons has morphed into an open commons primarily for Rally customers and users. In addition, the general Agile community discussion has continued to splinter across countless blogs (see the top 200 agile blog list – we are #12!), email lists, and twitter. Due to this splintering, it is really hard to quickly find good, well shaped answers to common agile questions.

This problem has been plaguing the agile community for years and finally boiled to the surface at the 10 year agile gathering in Snowbird this year. In that meeting the following four items were cited as critical steps to keep the community growing for the next 10 years:

• Demand Technical Excellence
• Promote Individual Change and Lead Organizational Change
• Organize Knowledge and Improve Education
• Maximize Value Creation Across the Entire Process

You can read more about the 10 years agile gathering in my February post as well as the many sites and attendees that I reference. I think the industry is ready to address this problem. Now what is the solution?

StackOverflow thinking

I have been passionate about building and sharing knowledge since I was first introduced to web technology via Mosiac in 1994; however, I would not call myself a knowledge management expert. I have continued to dip in and out of this space but being introduced to David Snowden’s work at the Lean Conference in 2010 has been a significant catalyst in my thinking and passion on social and knowledge management. His work has stoked my fire around this problem and solution space. David’s talks and the morphing of Agile Commons have driven my pursuit of a great space to manage agile knowledge in an open manner. My research took me through:

• Wikipedia on agile
• Agile Alliance Resources
• Lean Software & Systems Wiki
• Scrum Alliance community
• Linked In Groups on agile
• Google’s Knol on agile
• Quora on Agile
• Stackexchange on project management

It was StackExchange that stood out to me as the clear winner for managing what Snowden calls ordered knowledge. StackExchange’s Q&A format is truly amazing, it is first a community of experts and second a well gardened knowledge management system. See the PM StackExchange ABOUT post to understand how it is a combination of four great technologies.

If you have not tried stackexhange, jump into pm.stackexchange.com and try entering any project management question you can think of, including anything agile. As you type, you should see a list of related questions based on the keywords in your question. If you do not see your question, please enter it using these simple guidelines and make sure to use tags like agile, scrum, kanban, or TDD. The community will help you shape it into something that will get a good spectrum of answers in a matter of a week. Even in beta the PM StackExchange includes the following site stats:

I don’t care what yahoo group or wiki you are on in our community, it’s difficult find that kind of diverse network to help you with your day to day questions. As I noted, the site is still in public beta. My guess is by 2012, this community will have quadrupled.

Problems with other Q&A sites

This post is about Stackexchange, but, as I mentioned above, there are other solutions for managing a body of knowledge like this. I found a number of short-comings in those communities:

• There is not enough people in community to clear the answer broadly and quickly – too small a sample
• There is only a certain clique of people in a community that provides too much of a myopic answer – 1 right way
• There is focus on discussing and debating, not answering the question in a focused way that matches the question depth – a podium
• There is opacity with regard to governance and content ownership – lack of transparency = low trust
• There is a lack of moderation to keep the community – entropy happens

I believe StackExchange addresses all these issues in a remarkable set of people, policies and bots. I encourage you to help our community move forward by finding ways to organize and share knowledge on Agile in StackExchange. Please share your ideas and other agile resources in the comments.

Ryan Martens is CTO/Founder of Rally and on the way to be the Entrepreneur-in-Residence at the Unreasonable Institute this summer in Boulder –  See the Institute’s 2011 Fellows – Watch the intro video to the Institute and follow my escapades in the Unreasonable Mansion with twitter @RallyOn

Rally’s ongoing use of hackathons to spur innovation and creativity are highlighted in a new article on Inc., “How to Set Up a Hackathon.” Our own Todd Sheridan, Scrum Master, and Chris Browne, Agile Coach, contributed terrific insights into the benefits, rules and how to best setup successful hackathons. One of the key takeaways from the article is recognizing that hackathon thinking “shouldn’t only extend to product ideas, but to how the company operates internally.” Taking time to step away from everyday issues provides valuable distance that can help stimulate creative thinking.

Hackathons, a time-boxed event used to build prototypes of innovations, are a popular way to spur new ideas and have been employed by companies like Google, Facebook and Twitter. A few weeks ago we shared Rally’s experience hosting week long culture and space “hackathons” as part of our effort to extend these innovative events beyond their traditional engineering and development contexts. We had an awesome hackathon week, applying the fundamental ideas of urgency and innovation to our own company culture while producing four great projects.

Do you use hackathons in your organization? We’d love to hear about how you’re hacking your products, spaces and culture.

Ryan Martens is a tomatillo salsa maker, school board member at Friend School Boulder, and CTO at Rally Software Development.

It’s shaping up to be a busy November for us here at Rally with conferences on both coasts. We’re a Silver sponsor of Gartner’s Application Architecture, Development & Integration (AADI) Summit November 15-17 in Los Angeles. For Agile Development Practices (ADP) East November 14-19 in Orlando, Rally is the Conference Sponsor and once again I’m honored to be presenting. We’re coast to coast, and we’ve got discount codes for both conferences (see below).

Rally on the West coast with AADI

Rally is excited to be a part of Gartner’s AADI Summit that focuses on powering the Agile enterprise. The summit includes a key conference track on Agile and highlights three critical building blocks of a successful applications strategy—Cloud, SOA and the overhaul of existing Applications. Stop by the Rally booth to talk with one of our Agile coaches or other team members to learn how we can help move your organization into the next phase of Agile adoption.

In addition, one of Rally’s high-profile, enterprise customers will be speaking about how their adoption of Agile practices in an 800-person development organization (within a $15 billion division) has delivered:

• 3X better throughput
• an 89% bug reduction
• the elimination of over 180,000 hours of development time in one quarter

For more news and information about the summit, follow the #GartnerAADI hashtag on Twitter. Also, stop by the Rally booth (F) to pick up a hat, register for a chance to win an iPad, and to learn more about how we can partner with you in achieving Agile success.

Rally on the East coast with ADP East

Once again, Rally is proud to be the Conference Sponsor for ADP East. This conference is a great opportunity to dive into both Agile basics and the latest trends in Agile. Participants will gain guidance in testing, development and organizational best practices.

I always love the ADP conferences because of the energy of the participants and the variety of topics. The conference is a great venue in which to share new ideas and experiences. This year I’m excited about exploring new trends in Kanban as well as revisiting Agile basics such as story writing.

Be sure to check out my two sessions on Monday and Wednesday along with these other opportunities to join with us at the conference:

• Monday, 11/15 at 8:30 am – Writing Great User Stories 1/2 day tutorial
• Tuesday, 11/16 at 4:30 pm - Welcome Reception, sponsored by Rally
• Wednesday, 11/17 at 12:45 pm – Lean, Kanban and the Art of Flow regular session with Bill Wake, Senior Coach at Industrial Logic, Inc.
• Wednesday, 11/17 at 2:45 pm – Agile with the Right Tools can Maximize Developer Productivity with Collin O’Brien, Technical Account Manager and Sean Billow, Major Account Manager at Rally Software
• Visit the Rally Software booth # 7 & 8 to chat with Agile coaches and other Rally team members about how we partner with organizations through tools, coaching and community to help achieve Agile success. Rally is also contributing an iPad to the conference Passport game, so be sure to stop by to get your passport stamp.

For more information and updates about the event, follow the #ADP10 conference hashtag on Twitter.

If you’d like to join us for either of these events, use the following registration links and discount codes: Gartner AADI use code ADRD to save $300; ADP use code RAAV to save $200

Jean Tabaka is a wine enthusiast, author and Agile Fellow at Rally Software Development. You can follow Jean on Twitter at @jeantabaka

Last week was quite a week here at Rally. Given the many activities we experienced, I was reminded of our engineering “hackathons” except applied in a whole new way.

Why do we only talk about hackathons for developers and the engineering team? (If you aren’t familiar with hackathons, you might start by reading our series on how to foster a culture of innovation.)

Hackathon – a time-boxed event, typically a day or a week, used to build prototypes of innovations that could be helpful in enhancing user experience, architectural capacity, or development team effectiveness.

Given this definition and given the work we accomplished last week, it became clear to me that what we had done was run culture and space hackathons

Monday and Tuesday – knowledge team leadership and hacking your culture

On Monday and Tuesday, we took 30 folks at Rally through Christopher Avery’s “Knowledge Team Leadership” course. We’d invited Christopher in after great reports from two folks we sent to his class last year. Based on that feedback, we decided to try the course out as a “management training course” internally at Rally. There was a ton of added value in that course for new managers as well as executives.  Included in Chris’ class is his work on the responsibility process, seen in the picture below. (click on the image to get to Chris’s site.)

Chris Avery's Responsibility Model

The really cool thing about the course is that, while we were learning about teams and leadership, Christopher had us apply our course work in separate, meaningful small projects that run concurrently with the course.  With our 30 people, we subdivided into five small teams, where two teams decided to work on one project together. Because this was a private course, each group chose a project related to Rally’s culture.  I would argue that they all turned out to be culture hackathon projects given that we only had 6 clock hours to produce a cultural innovation “product”. And boy did we get some great stuff:

• Rallypedia – a new internal wiki at Rally that has an encyclopedia of terms, models, stories and lore at Rally.  This site is critical to keeping our culture strong in a rapidly growing, geographically distributed company. What a great cultural contribution.
• Beyond Rally - a new wiki site for after-hours and non-work related announcements at Rally.  This open site shares music and other social events, for sale items as well upcoming volunteering opportunities.
• Core Values Revisited – a new wiki site that shares stories about us living our core values.  It is a platform to revisit these values and separate core values from cultural norms.  This project is a critical part of us creating our shared vision for 2020 at Rally.
• Rally teams video – a 5-minute video that introduces new employees to the importance of teams at Rally. The video explains five key components of teamwork and how this will inform and guide any new employee into our collaborative culture

Two of the projects launched at the “project demos” event during the course. The other two will launch later this month.  It was a testament to how well some of Christopher’s approach works for quickly, building high-performance teams.  It was also a testament to effectiveness of holding non-software hackathons.  Those two days of project work left all of us on a real high as hackathons tend to do. For me, we had taken advantage of that hackathon sense of innovation and urgency and applied it to great ideas about extending our culture.

Wednesday and Thursday – Design Thinking and hacking on your space

After two days of training with Christopher and our culture hackathon, I got to spend most of Wednesday and Thursday with a group that was focused on shaping our new office space.  (Yes, we are moving again!)  We have learned about building effective team rooms as we have moved our team to six locations since starting in 2003.  I see these six moves as a real gift.  It has forced us to keep playing around with furniture and space to help enable the emergence of high-performance and collaborative teams.  With each move, we are invited to purposefully pay attention to our culture and our knowledge flow. So our goal with this latest move is to be even more impactful and extend these innovations in space design to our entire office space.

To enable this kind of innovation to emerge, we had a space design charrette that was facilitated by George Kembel, Executive Director at the d.school at Stanford University.  This was a natural out growth of the innovations that I got to work with at while at the d.social summit this summer.  It could not have happened without John Kembel (yes George’s twin brother) and his team at RightNow here in Boulder.   Due to the successful RightNow acquisition of HiveLive, the RightNow office is growing and forcing a move here in Boulder as well.    It was really cool to experience this space type of hackathon with two companies of two different sizes in two different contexts with two different cultures at once.

Roughly five people from each company gathered in a large open space in the Rally offices to run their hackathon. After establishing clear tasks for each team, surfacing motivations, making some agreements, crafting a higher elevating goal for each team, and celebrating the diversity, we jumped in to an iterative process.  That process had the two teams move through four different process steps:

• point of view & strategy
• approach and empathy
• low resolution prototypes
• iterate on build-out plans

As a result of that work, the RightNow team created three floor designs using floor tape, tables and foam core. It was cool to watch that team focus on the prototype stage.  Because Rally is dealing with 65,000 feet and a move-in date of February, we were more focused on planning next steps and learning from a rapid prototyping experiment that we plan to start in our current office next week.   To aid us in our prototyping efforts, we have already built three different T-Walls based on formations I had seen at the d.school. We’ve let the T-walls loose in an area close to Support and Product Development to get feedback.  We also plan to tear out a couple of large tables in two of our conference rooms to make room for more flexible uses in those team huddle rooms.

Huddle Room at d.school

From our space hackathon, we hope to learn from those prototypes in the next month and let them inform what furniture components we will order for the space.  These low-resolution, non-precious prototypes will hopefully allow teams to experiment with more flexible solutions for their work spaces, team rooms, huddle rooms and conference/training rooms.

With regard to our point of view, strategy and approach, our prototyping team is resolved to run way through the finish line and set a cadence for continually hacking our space.  We are likely to be in our new space for a long time.  As a result, we need to keep the spirit of innovation alive and drive down the set-up time and costs for changing our space to suit the emergent nature of teams around Rally.

What a great week for implementing culture and space hackathons. I hope you and your organization are doing the same.

What has worked in hacking your space or your culture?

For more ideas from the d.school do not miss their site and blog and the tour of the new space.

Ryan Martens is a tomatillo salso maker, school board member at Friend School Boulder, and CTO at Rally Software Development.

I taught a public Certified ScrumMaster class in Boulder recently, and was struck yet again by how many folks had burning questions about how to manage multi-team programs with Agile.

Technically, the CSM is an introductory course, designed to give the basics of Scrum sprints and releases and of how to lead Scrum teams.  More and more, though, I find that people feel the need to at least understand how Agile works at scale, even as they begin to implement Agile for a single team.  “Tough Questions” from the class included: “How to collaborate with non-Agile teams on a single project,” and “How to handle coordination between multiple Scrum teams.”

I began to answer these questions during last week’s webinar: “The Secret to Coordinating Multi-Team Agile Programs.” In the webinar, I described why Agile teams have the advantage when it comes to quality, value *and* coordination in multi-method programs.  I also gave some practical tips for making coordination and integration work.

I was really excited to be joined on the webinar by Srikrishna Gopalakrishnan, eBay Senior Product Development Manager. I had the good fortune to work closely with Sri when we were launching eBay’s first Agile program.  Sri talked about what it’s really like not only to make the coordination work, but also to change the way you lead and manage, along with putting a different kind of energy into motivation.  Sri and I got to tell our stories, adding real-world experience to make sense of textbook Agile.

I invite you to listen to and watch the recorded webinar.  And, for those of you who listened and submitted questions, answers are on their way shortly.

There are other conferences that cover Agile software development, but the Agile 20xx show reigns supreme. At nearly 2000 attendees from around the world, this year’s show is happening at Walt Disney World in Orlando.  (It was moved there after the flood in Nashville.) For the first time, three of the major analyst firms (and as a result 5 of  the key analysts who cover Agile and ALM) are attending the conference – Forrester, Gartner and IDC.

Rally coaches, sales and marketing folk at booth setup

As a result of the show’s success, it has become the most significant market rhythm in our industry.  So this week, we announced a few things:

• Rally Software Extends Agile ALM Platform to Meet the Unique Needs of Global Organizations – New customization options, full traceability with build and source code, and sharing with corporate dashboards create a single source of record for progress and quality
• Rally Software Extends Visualization of AgileZen Kanban Board – New non-profit program offers a 50% discount on leading visual project collaboration tool
• Innovation Games Company Announces Integration with Rally Software – The leader in serious games for business brings customers improved collaboration and prioritization capabilities
• Tasktop Introduces Agile Planner for Eclipse – New product enables Agile planning from the IDE and integrates multi-vendor Agile ALM solutions

I am speaking tomorrow on PDCA: Moving Beyond Simple Inspect and Adapt. (Thurs 9:00 a.m. in A-1). Other Rally speakers remaining this week are:

Get your Rally cap

• Former Rally developer turned Rally technical account manager turned Rally coach Chris Browne speaks Wednesday on The Art of the Hackathon (Weds 15:30 – 17:00 in Asia 3).
• Rally coaches Alan Atlas and John Martin speak Thursday on “Your Team, Your Freedom, Your Responsibility” (Thurs 15:30-17:00 in Asia 3).

Follow the news from the show on Twitter at #Agile2010. Come see us at the booth and get a Rally and Deliver ballcap. Or let us know if you’re not at the show and want us to send you one (send name and address to kcaraway@rallydev.com).

Ryan Martens is an organic farmer, founding board member of the Entrepreneurs Foundation of Colorado, and CTO at Rally Software Development.

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!