Agile Development Blog

Rally was founded shortly after the signing of the Agile Manifesto, the document created at a 2001 meeting of leading software developers at Snowbird, Utah, that gave rise to the Agile movement. Since then, Rally has taken what we’ve learned from leading countless enterprise Agile transformations and funneled our collective experience into a formula that includes our Agile ALM platform and products, our expert coaching services, a vast library of educational resources, and a supportive community for asking questions and sharing advice. In celebration of the 10-year anniversary of the signing of the Agile Manifesto, Rally had a special commemorative activity at the Agile2011 conference.

Bryce Widom, chalkboard artist and painter, joined us and literally drew, in real-time, the history of Agile. Rally team members and conference attendees collaborated on the stories that made up this “Road to Agility” starting with the Agile Manifesto, and continuing with important milestones such as Dr. Dobb’s Agile adoption survey, Forrester’s Agile ALM Wave report and the formation of the PMI’s Agile community of practice. Bryce also drew colorful stories that illustrated benefits of agility from companies like Betfair, John Deere and McKesson.

Announcements

The announcements we made at the conference are a culmination of Rally’s experience in helping organizations expand Agile practices to maximize value across the entire organization, along with strengthening support for multi-process development (check out these video interviews on SSQ’s blog to hear more). Our first announcement highlights Rally’s support for multi-process Agile. As Agile moves deeper into new functional areas, Rally’s Agile ALM platform, products and coaching services have been evolving to meet these diverse needs. When Scrum is not the best fit, we include support for other Agile methods such as Kanban and high-assurance methods to ensure that we can be the go-to partner for all enterprise Agile roll-outs. We announced:

• Enhanced Kanban support, including support for Class of Service highlighting and reporting. Read this product blog post for more details.
• Support for new customizable defect reports that support all processes.
• A new Iteration Summary Panel for Scrum teams that provides in-product coaching assistance. The panel guides teams based on their performance and offers coaching-authored best practices.
• Apps that support traceability and documentation in Rally within High Assurance organizations (check out this blog series on High Assurance Software Development).

Our second announcement signifies the bridging of Agile into the Project Management Office (PMO). In its 10th year, Agile’s mainstream appeal has broadened its reach from the technical to the business parts of the organization. We recognize the trend and are helping to ease the transition for all parties. We announced:

• Unmatched integrations with industry-leading Project and Portfolio Management (PPM) vendors like Oracle Primavera, CA Clarity, Daptiv, and Planisware.
• An update to Rally Idea Manager, the leading Agile ALM demand management solution. This release bolsters the integration with Rally and provides a new leaderboard to drive end-user engagement.
• Availability of a new Agile Portfolio Steering services offering. This offering represents the next frontier of Agile and includes an interactive simulation to facilitate collaboration between Agile teams and business stakeholders.

Field Guide

At Agile2010, we provided vuvuzelas in celebration of the World Cup and, while I’m sure that many of you annoyed your families with these, we decided to leave you with a lasting educational giveaway at Agile2011. We assembled a content guide written by our coaches on Agile best practices. We hope you find this field guide useful in your day-to-day activities – download your copy here.

Thanks to everyone who contributed to the “Road to Agility” illustration, whether you were at Agile2011 or were following our progress on Twitter, Facebook and Flickr. In addition to celebrating the 10-year anniversary of the Agile Manifesto with the community at Agile2011, Rally also embraced the opportunity to reflect on how much we’ve learned from helping some of the world’s largest organizations apply Agile practices. We look forward to making continued meaningful improvement in our industry, and leading the next 10 years of Agile innovation.

Todd Olson is VP of Product at Rally Software. He is a marathon runner and cake baker. Find Todd on Twitter at @tolson.

Ryan in the cockpit with Tim the ISG System Tester

The Intelligent Solutions Group at John Deere recently confirmed that they have been engaged in a large-scale Agile transformation since 2010. Chad Holdorf, Scaled Agile Coach at John Deere, has been sharing news about agile in his blog, Scaled Agile Delivery, since 2008. Chad’s blog is packed with useful information and fun videos including recent posts about Deere’s tool selection process and teaching Scrum with Legos. Deere’s Agile experience is also included in Dean Leffingwell’s new book Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise Requirements and on Dean’s blog.

At Rally, we are proud to be a part of John Deere’s successful Agile rollout, and I just retuned from a visit to Deere’s facility in Des Moines. I want to give a huge shout out to Chad and thank the entire ISG team for hosting me for two days. I especially want to thank them for letting me see their cool work in action. (see photos of ISG controllers steering the 8 wheeled tractor that I was driving!)  These guys are working hard on solutions that help us build more agile farming and construction solutions to help feed our growing planet.

On the trip, I got to ask Chad a few questions to highlight their blazingly fast rollout efforts.

1. When people think about John Deere, they likely picture big tractors, not software. Why Agile?

The Intelligent Solutions group designs the technology that runs our vehicles. This includes things like displays and receivers, guidance systems, field and crop management, and information and logistics systems. About a year ago, we were faced with a hard deadline for shipping a new display in a very short timeframe. It was a do or die situation. We knew then that what we had been doing wasn’t going to work for this effort. We really had no other choice but to go Agile then, and we’re still reaping the benefits now.

ISG video controllers in the tractor above

2. I know you made the deadline, but tell me more about getting 600 people to go Agile in a year?

We took an “all-in” approach. We wanted to get everyone on the same page right away, immerse them in training and Agile concepts and kick off our effort at once. Sure, it was a lot of heavy-lifting, but it really paid off when we saw the results. We moved a huge project through our pipeline in a third of the amount of time it would have taken otherwise.

3. So did the other shoe drop? How did people react to transformation? What’s different now?

We have smart, talented people. We knew that if could figure out how to get out of their way, we would improve. Since going Agile, we’ve seen huge buy-in and ownership from the teams. They have embraced the collaboration, creating team names, ribbon-cutting ceremonies and even mascots. Physical spaces have also changed. Walls have come down and work spaces are more physically open and collaborative. It’s all part of letting people do the right things. For the first time ever, we didn’t have anyone working over Thanksgiving or Christmas — and that’s even with a big end-of-year deadline. Efficiency has been huge. What would have taken us two months before, now we deliver in two weeks. I figure if John Deere can test working software every two weeks on a tractor in a field, then Agile will work anywhere.

4. You have told me about your “OSM,” can you share more with others about this key event?

After our release planning, we have an “Oh $%it Meeting.” We use that meeting to help give visibility to and cover all the contingencies and gotchas. We’ve found that it helps to refine our next iteration and make sure that we have covered everything and are ready to start the iteration.

5. I look forward to my visit this month, but give me a heads-up; What’s your next mountain to climb?

We have a few. We’re always measuring our success to make sure we’re delivering what the business needs. We’re also working to keep learning and growing our technical understanding and to encourage a culture of innovation by empowering our people to get their ideas on the table. It’s really about continually working to assess our efforts and understand how we can improve. We’ve had a great deal of success, but we’re always looking to get better.

Ryan Martens is CTO/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

It’s Agile 2011!

In my post last week, Agile and Rally – We’ve come a long way, I mentioned that Rally has a special commemorative activity at our booth this year. Now that the conference is here, I wanted to share more about this cool activity and let you know how you can participate with us.

Illustrating Agility

Starting today and throughout the conference, Rally will be illustrating, literally, the past, present and future of Agile’s exponential growth from the Agile Manifesto through mainstream adoption, and beyond. We need your ideas to help shape this illustration! If you are attending the conference, please stop by the Rally booth during exhibit hours and tell us about your Agile adoption, your most important milestones and the trends you think will shape the future of agility. If you’re not at our booth, or not even at the conference this week, you can also tweet your submission #roadtoagility. Then be sure to stick around and see our performance illustrator Bryce Widom drawing submissions in real-time.

We will be sharing photos of the illustration throughout the conference. Join us on Twitter (the #RoadtoAgility hashtag), Flickr, Facebook, and through the comments below to contribute your ideas, share your thoughts and see how the illustration evolves.

Jean Tabaka is a frequent flyer on no particular airline, an author and Agile Fellow at Rally Software Development. You can follow Jean on Twitter at @jeantabaka

In 2001, the Agile Manifesto was created with 17 signatories from around the world. Following on the heels of the first XP conference in Sardinia in 2000, the Manifesto fired its shot of agility across the Waterfall bow. A year later, at XP/Agile Universe 2002, I found myself standing at a folding table with Janet Danforth of Facilitator4Hire. We were selling facilitation services to the members of the Agile community gathered at a Courtyard by Marriott in Lincolnshire, Illinois. Approximately 80-100 people had come together in that steamy summer venue to continue Agile discussions and to define ongoing growth of methodologies, practices and frameworks.

Where we were

At the same time I was at my folding table in Lincolnshire in 2002, Ryan Martens was at a whiteboard in Boulder, Colorado. Ryan was brainstorming ideas about how he could use Agile practices to create a Software as a Service platform in the Agile domain. His goal? To provide zero-waste, low-carbon emissions applications and services for this growing, vibrant community.

In 2003, the Agile community gathered in Salt Lake City for the Agile Development Conference. This was my first time presenting at an Agile conference. Janet Danforth and I conducted a workshop: Collaboration 4 Agile Projects. And, unbeknownst to me, Ryan was also in Salt Lake City for his first Agile conference. As Ryan was busy engaging vendors about how they were supporting the adoption of Agile, I was busy networking with Agile thought leaders and helping to found “The Freaking Flock” (you’ll have to ask me about that in person!) Our paths were set and Agile was on the move.

Fast Forward to 2011

Now, in 2011, we are 10 years on from the Manifesto signing, 9 years on from the first sighting of me at the folding table, and 8 years on from Ryan’s first foray into the conference.

The Agile 2011 conference is an exciting one for both Agile and Rally. We are pleased once again to be a Title Sponsor of the conference. This year, August 8-12, Rally has 11 speaking sessions on the wonderfully vast and diverse program.

• Jean Tabaka and Julie Chickering: Enterprise Agile Visioning and Learning
• Aaron Sanders and Carlton Nettleton: There’s an Agile Game for that
• Karl Scotland: Dr W. Edwards Deming’s Famous Red Bead Experiment – For Software Teams
• Ken Clyne and Eric Willeke: Putting the Fun Back in Your Retrospectives
• Aaron Sanders: Ten Tales of Positive Change
• Ken Clyne and Julie Chickering: Risk Management Game
• Karl Scotland and Eric Willeke: Flow Games
• Jean Tabaka: Tell me Why: The Golden Circle of Agile Transformation
• Steve Adolph and Philippe Kruchten: Reconciling Perspectives: How People Manage the Process of Software Development
• Shane Hastie and Steve Adolph: Agile Thinking for Business Analysis-Going Beyond User Stories
• Karl Scotland: Designing a Kanban System for the Enterprise

We’ve also participated behind the scenes in advance of the conference as producers, co-producers and reviewers for various conference stages. And, once again, we’ll have a booth where you can come to meet our Agile coaches, talk with our technical gurus, and see the latest that is happening with Rally’s Agile ALM platform and services. Plus, you won’t want to miss our special commemorative activity at the booth this year. Stay tuned to the blog and follow our Twitter hashtag #roadtoagility for more details on how you can participate with us!

Going back to my history of Agile and Rally and the conferences

Ryan and I never met at the 2003 conference. But in 2004, as the conference moved into the northern Rockies in Calgary, Alberta, 4 of us stood together at a folding table in a small hallway. Rally’s representation at that Agile conference was Ryan as President of the company, Richard Leavitt as our VP of Marketing and Sales, Brad Norris as our sole sales person, and me as the sole Agile Coach. At that point, none of us were speakers. However, Rally has had one or more speakers at each conference since: Denver in 2005, Minneapolis in 2006, Washington DC in 2007, Toronto in 2008, Chicago in 2009, and the 2010 event in Orlando. Additionally, Ryan served on the Agile Alliance board during the years of the Washington D.C. and Toronto conferences.

From the folding table to now

Some things have changed in Rally’s Agile journey. We’ve grown from a 20-person company in 2004 to over 250 people and counting. Ryan is now the head of the office of the CTO. Richard is now the Executive Vice President of Worldwide Marketing. Brad is our Vice President of Field Operations. And I am an Agile Fellow in the Office of the CTO.

From a Manifesto, a whiteboard, folding tables, and a single speaker to title sponsorship with multiple speakers, producers, reviewers, and booth presence in a true exhibit hall at a conference with over 1,600 attendees, we’ve indeed come a long way!

Jean Tabaka is a frequent flyer on no particular airline, an author and Agile Fellow at Rally Software Development. You can follow Jean on Twitter at @jeantabaka

In our Agile Tooling for High Assurance Software Development series we’ve looked at a prescribed user story structure for requirements traceability and we dove into how tooling is important to maintain relationships needed for traceability to other artifacts in the system (defects, test cases, etc.). Given this, how do we automate a traceability matrix from Rally?

First let’s review the why. Why do we spend so much time and energy creating traceability matrices?

There are a number of sources that I could cite but I’ll go back to the Design Control Guidance for Medical Device Manufacturers, where section F Design Verification states:

DOCUMENTATION OF VERIFICATION ACTIVITIES. Some verification methods result in a document by their nature…

Another self-documenting verification method is the traceability matrix. This method is particularly useful when the design input and output are both documents; it also has great utility in software development. In the most common form of the traceability matrix, the input requirements are enumerated in a table, and references are provided to each section in the output documents (or software modules) which address or satisfy each input requirement. The matrix can also be constructed “backwards,” listing each feature in the design output and tracing which input requirement bears on that feature. This reverse approach is especially useful for detecting hidden assumptions. Hidden assumptions are dangerous because they often lead to overdesign, adding unnecessary cost and complexity to the design. In other cases, hidden assumptions turn out to be undocumented design input requirements which, once exposed, can be properly tracked and verified.

Although this is only a guidance, it is pretty clear that the FDA is encouraging the building of traceability matrices, that might be “why” we all create them. In order to automate the creation of this matrix Rally has offered two Rally Catalog apps in the product, the Iteration Traceability App and the Release Traceability App. The screenshot below shows an example of the Iteration Traceability App that displays Stories with their associated Tasks, Test Cases, and Defects for an Iteration.

In the spirit of the work that Dean Leffingwell and I have been doing I persuaded one of Rally’s awesome App Developers, Charles Ferentchak, to help me build an additional trace matrix app based on an example shared by a customer. This app is not bound to an Iteration but instead allows the creator to select from their list of tagged PRD’s and creates a trace report showing all of the features associated to the PRD along with test cases, results, design outputs, and etc.

Both of these traceability matrices are examples of possible automation that can be easily achieved by adding tooling to your Agile practice.

To submit your own idea for a Traceability Matrix to Rally’s Product Team visit Rally Ideas for Regulated Industries and the next time you are on LinkedIn be sure to join the Agile in Regulated Environments LinkedIn Group.

And, as always, I encourage your comments on this post or email craig@rallydev.com.

Craig Langenfeld is a Technical Account Manager with Rally Software Development who has been working closely with many Agile Practitioners in the Healthcare Industry to define best practices.

Dean Leffingwell is an entrepreneur, executive, author and consulting methodologist who provides agile transformation consulting services to large software enterprises. Between consulting engagements and keeping up with his Blog Dean managed to publish his latest book, Agile Software Requirements.

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.

Are you challenged with trying to map Agile Software Requirements to a traditional requirements model for the documentation required during internal or external audits?

If you answered “yes”, you are not unlike many of Rally’s highly regulated customers who want to reap the benefits of Agile but struggle to find good tools for creating and managing system documentation. For the next two posts in our Agile Tooling for High Assurance Software series, I will provide an overview of the material that I presented to a small sampling of customers in early May at our inaugural RallyON conference in Boulder. This work is a continuation of the project that Dean Leffingwell and I have been working on over the past year.

Let’s start by reviewing Dean’s post, Agile Software Requirements in High Assurance Development, which provides us with a traceability model as well as a medical device example to follow. From there I’ll demonstrate how Rally can be used to support traceability from what we traditionally think of as a PRD, a document detailing the system’s intent, to user stories that are commonly used to implement the features of the system.

An important part of the verification effort is to assure that every feature traces to one or more user stories (or other forms of software requirements expression) as is illustrated below. But first we need to begin with a PRD that defines the overall behavior and intent of the system. This will serve as design input in FDA terms. The PRD is going to be decomposed into individual features that will be implemented by many Software Systems Requirements, which we’ll also refer to as User Stories. Take a moment to review the illustration.

With regard to managing these requirements, many of us have encountered or even created spreadsheets with thousands of rows of requirements and tens of columns of attributes that described the system we intend on building.

As part of the introduction to Agile practices we will trade-in the spreadsheet for an Agile Lifecycle Management (ALM) tool that will provide us with better traceability to the real system being implemented. An ALM tool, like Rally, allows us to create a high level user story that will represent system intent and maintain those items that we said were important to document such as a PRD. In Rally the system, intent, features, and user stories will all be tightly coupled by creating a family of user stories through parent/child relationships.

The screenshot below shows the EPAT example that Dean Leffingwell described in his post, extrapolated in Rally. Notice that our EPAT Device Enhancement has been broken down in a way that will allow us to trace each child user story back to the PRD (represented by a parent user story). Another convention being used in this example is that of tagging. Rally users often tag stories to represent requirement types like PRD, SRS, functional, or non-functional stories for better reporting on specific story groups.

Being prescriptive and consistent when structuring our Agile Software Requirements (User Stories) in Rally provides us with the unique capability to create our own custom document exports, such as the Product Requirement Document that I will highlight in a post next week.

In summary, Rally helps us to transform individual user stories that each implement a small increment of value into a aggregation of stories that represents the intended product.

To learn more about Rally’s User Story Hierarchy watch this informational video.

To submit your own ideas to Rally’s Product Team see Rally Ideas for Regulated Industries and the next time you are on LinkedIn be sure to join the Agile in Regulated Environments LinkedIn Group.

And, as always, I encourage your comments on this post or email craig@rallydev.com.

Craig Langenfeld is a Technical Account Manager with Rally Software Development who has been working closely with many Agile practitioners in the healthcare industry to define best practices.

Dean Leffingwell is an entrepreneur, executive, author and consulting methodologist who provides agile transformation consulting services to large software enterprises. Between consulting engagements and keeping up with his Blog Dean managed to publish his latest book, Agile Software Requirements.

This is the second post in our blog series, Measuring the Impact of your Agile Investments. The series focuses on measuring the impact that Agile practices have on business outcomes.

For many leaders, increasing the productivity of the development organization (delivering features the business needs and generating improved ROI) is their primary and over-riding goal. ‘Doing more with less’ is a mantra they preach to their teams continuously, and which colors every decision they make.

Yet few have a clear and consistent definition of productivity or an effective means of measuring it.

Productivity: a relative measure of the efficiency of a system in converting inputs into useful outputs.

Productivity: the ratio of the real value of outputs to the combined input of labour and capital.

Productivity: a measure relating a quantity and quality of output to the inputs required to produce it.

So, in simplest terms:

Productivity = Valuable Outputs / Costly Inputs

Be Careful What you Wish For

While I am a ardent believer in the value of metrics, it is important to keep in mind the potential for unintended consequences. Individual and group behaviors will evolve to meet your measures – not necessarily your goals. So ensure that the measures you use promote the behaviors you desire.

Most documented productivity metrics in software development define a unit of output as either a KLOC (thousand lines of code) or as a Function Point. Both have significant disadvantages.

KLOCs are generally favored for the simple reason that they’re unambiguous and easy to measure. However, they can unintentionally promote poor design and coding practices. Elegant, efficient, maintainable software takes more time to write, and takes fewer lines of code. Therefore, a KLOC metric inadvertently creates a disincentive for building high-quality software, and rewards poorly thought through designs and shoddy craftsmanship.

While Function Points don’t necessarily promote poor design and craftsmanship, they have their own unique challenge – they are famously difficult and expensive to calculate and measure.

Perhaps even more importantly, both KLOCs and Function Points ignore the core aspect of ‘Value’ inherent in our definition of output – and therefore productivity.

It has been stated that 64% of the features and function in the typical software system are rarely or never used (Standish 2002). Calling the code that delivers these features and functions “productive” may be a mischaracterization.

Similarly, those features and functions that ARE commonly used are generally not of uniform value. The Pareto Principle would suggest that 80% of the value is delivered by 20% of the effort. Yet KLOC and Function Point-based metrics treat all features and functions (and code) delivered as interchangeable. This promotes focusing on the easiest and lowest technical risk; rather than the most valuable, most innovative and greatest business risk…

Output is a measure of the value delivered, not the effort expended.

A number of people in the Agile community have written about an alternative unit of output measure – Value Points.  While the simplicity and value focus of this model is appealing, it has challenges when scaled beyond a few teams. In order to be meaningful at the organizational level, you must normalize the relative value point scale across teams and programs – which can be difficult and expensive.

Also, the Value Point approach does not easily translate to initiatives and/or divisions that may not be delivering in an Agile manner. Having a common measure of output, and therefore productivity, is critical to measuring the impact of your Agile investment.

So, the approach we recommend is to associate a percentage of the total value of a given initiative to each Minimally Marketable Feature (MMF) or production release. These percentages can then be applied to a any monetary business justifications (ROI, NPV, Discounted Cashflow, etc.) to arrive at an expected dollar value realized from each release.

Hence,

Productivity = Total Value Realized (delivered to production) /  Total Cost of production (labor)

Using this approach, your organization (be it a Scrum team, a multi-team Agile program, a waterfall project, or even an entire product development group) base-lines their productivity for a period of time and monitors the change over time.

Example:

The division has 3 initiatives in progress:

• Initiative A:  Total Expected Value $5MM; being delivered by a Scrum team with an iteration run-rate of $70,000.
• Initiative B:  Total Expected Value of $25MM; being delivered by 5 Scrum teams with a combined iteration run-rate of $400,000.
• Initiative C:  Total Expected Value of $50MM; being delivered according to a project plan and resource matrix that charges $2.5MM to the project in the 1st quarter.

In Q1:

• Initiative A: Released to production monthly and delivered a total of 60% of Expected Value; or $3MM. 25% of the backlog has been burned-down in terms of story points. Total Cost $210,000. PRODUCTIVITY = 14.29
• Initiative B: Released to production quarterly and delivered a total of 65% of Expected Value; or $16.25MM. 35% of the backlog has been burned-down in terms of story points. Total Cost $1.2MM. PRODUCTIVITY = 13.54
• Initiative C: Completed requirements definition and is 50% done with Detailed Design, and delivered 0% of Total Expected Value. Total Cost $1.2MM. PRODUCTIVITY = 0

*undelivered work is WIP, and therefore not yet productive.

Aggregate Division Productivity for Q1 = 7.38

As you can see, it would be relatively straightforward to predict Q2 productivity – at the initiative as well as division levels – by assessing the various product roadmaps and traditional project plans. Those projections could then be used to:

• drive discussion about trade-offs on where to allocate limited capacity and maximize productivity
• staff and fund initiatives where productive potential is high, and to cancel successful projects whose greatest productive potential has already been harvested
• inform intelligent business decisions – which is WHY we’re measure outcomes

By understanding the productivity of the development organization (its efficiency in delivering features the business needs and delivering improved ROI), leaders can effectively drive improvements and business decisions that maximize productivity – Doing More with Less.

The next topic I’ll address in the Measuring Impact series is Quality. Most organizations claim to have a Quality focus, yet few take a holistic view of Quality or appreciate the strong correlation between Quality and our other Outcome Metrics – Productivity, Responsiveness, Customer Satisfaction, Employee Satisfaction and Predictability.

How are you measuring the impact of your agile investments? Please share your ideas and feedback in the comments.

Isaac Montgomery is the harried father of twin sons, the adoring husband of Angie, a frustrated hack on the golf course, and an Agile Coach at Rally Software. He blogs at Leading Results, you can follow him on twitter at @iwmontgomery

Next week we are running a fun experiment in Boulder, as we host our first users conference: RallyOn 2011. We are experimenting with a number of things as we learn how to engage, connect, and contribute to our growing world-wide customer community.

First, we are trying to leverage social technologies in a number of ways to reach users all around the world. One way we are doing this is by using Stack Exchange, the Internet’s leading community-driven Q&A engine, to meld a community of agile software development and program management experts. Conceivably, this could kick-off a new paradigm in professional conferences, attaining the elusive goal of extending the conference experience of networking, knowledge sharing and community into the online environment with virtual attendees, and living long after the closing session.

We invited representatives from Stack Exchange to join the conference, promoting and shepherding the community experience. As a result, two members from the Programmers and Project Management communities will be in attendance, sponsored by Stack Exchange. Mark and Anna, who have coauthored this post, have already brought guidance and energy to the interactions between communities, and are sure to do so during RallyOn, as these two communities closely align with the goals of the conference and the interests of our attendees.

Cool stuff about Stack Exchange that I bet you did not know:
You may be familiar with Stack Exchange’s most popular site, Stack Overflow, the flagship software programming Q&A site that receives tens of millions of visitors each month. However, the vision far exceeds that single site. Since August 2010, the company has launched 49 new vertical-oriented Q&A sites. By building vibrant communities of experts around specific topics, Stack Exchange is able to facilitate answers to 94% of all questions network-wide.

• Questions generally average 10 answers, giving you different insights and approaches to tackling problems or issues.
• Answers are peer-reviewed by experts within the community, with those answers receiving the most positive votes rising to the top, guaranteeing the most accurate, relevant or acceptable answer to even the most difficult question.
• Optimized for search engines, these answers help hundreds if not thousands of other people who are seeking answers to similar questions on the web.
• The experts forge a community of subject matter enthusiasts, earning reputation and recognition for their contributions through the reputation point system.

At Rally, we have a fantastic marketing department that puts on great regional events and huge webinars, but we have never done a users conference. However, we are not sure what the best model for our users conference should be. So we are bringing a community of experts and Agile enthusiasts together around the RallyOn 2011 conference. With the help of two enthusiastic Stack Exchange members to showcase the power and benefits of a community-driven Q&A network like Stack Exchange, we are excited about adding a whole new group of Agile experts to our current communities.

To help track the success of this endeavor, we’ve created a special RallyOn11 tag on each Stack Exchange site. Please tag your questions with this tag and also include it in your profile. Participation is a snap, and we’ll be there at the conference to give you a hand.

While exploring the Stack Exchange sites, check out the RallyOn11 tag to discover peers with similar questions and interests. We’ll also be streaming live feeds from the sites directly to a monitor at the conference, allowing you to observe the community’s activity in real-time.

What’s in it for you?

• As a director, the sites give your team an existing resource to crowd-source problems and find solutions from a group of subject matter experts.
• As a director, the Project Management community often addresses management level problems including those involving other managers, executives and team members.
• As an Agile coach or internal champion, these sites are a resource your customers can turn to stay on the right track.
• As an Agile coach or internal champion, you can build your reputation and find inspiration for new ways of approaching issues.
• As a developer, you can find answers to programming problems, project management concerns or challenges interacting with management.

Find Me at RallyOn!

Community: Programmers
Programmers attracts software development experts with interests in subject areas such as development methodologies, architecture practices, and algorithm and data structure concepts. It evolved out of the flagship Stack Overflow site when it became apparent that a separate place to ask questions about general software development concepts and programmers’ professional development, rather than specific implementation details, was needed. An example of this type of question can be found here.

Anna Lear (@aalear) is joining us from the programmers community, and is one of the community’s respected moderators.

Find Me at RallyOn!

Community: Project Management
Project Management covers a wide array of topics including: learning and implementing project management, challenges in managing projects and people (as well as challenges with project managers) and specific techniques and best practices from different methodologies. Project management approaches discussed include Agile, Waterfall, the PMBOK Guide, PRINCE2, ITIL and mish-mash of methodology that often gets implemented in the real world.

Mark Phillips (@mpmobile) is joining us from the project management community, having been a member of that community since its earliest days.

Ryan Martens is a member of NRDC’s Environmental Entrepreneurs, founder/CEO of the Entrepreneurs Foundation of Colorado, and Founder/CTO at Rally Software Development.

In last week’s blog “Rationale for Project Stratus”, Ryan stated “The model articulated in Dean Leffingwell’s newest book, ”Agile Software Requirements: Lean Requirements, Practices for Teams, Programs and the Enterprise“ is clearly one of the patterns of agile strategic planning.”

In this post, I want to expand on how we reached that conclusion.

I’ll start by introducing Chad Holdorf, Agile Coach and earlyvangelist for Project Stratus. Chad has been guiding Project Stratus in support of Dean’s model. Take a look at what you get with such customer collaboration: http://www.scaledagiledelivery.com/2011/04/22/agile-portfolio-planning/

Now on to how we got there:

As mentioned in the “The Making of Project Stratus” blog, we have been diligently following a customer development process based on Steven Blank’s model. Because the book focuses on startups, we adapted the model to existing companies (like Rally) wanting to deliver new solutions to their market, but one aspect that applies to both is a ruthless search for a handful (3 to 5) of what Blank calls “earlyvangelists”.

Earlyvangelists are customers that have these particular characteristics:

1. Has a problem
2. Is aware of having a problem
3. Has been actively looking for a solution
4. Has put together a solution of piece parts
5. Has or can acquire a budget

#4 and #5 are of key importance: Earlyvangelists have more than just the problem. They have it, want to solve it, already are trying something less than ideal, and have the availability and organizational authority to garner the resources to do something more about it.

With Project Stratus, we found many many customers have the problem (unrealistic roadmaps, poor visibility into development status of marketable features, lack of alignment between business goals and feature work). There is no doubt Rally has a responsibility to the market to produce an agile strategic planning solution. The challenge is finding earlyvangelists that can guide a successful solution to that problem.

We have been grateful to locate a handful of earlyvangelists: customers who have installed the Stratus preview application with their roadmap data, run their planning process for real with it and kept my inbox interesting with plenty of “Catherine, this is great but I need X to really make it work for us.”

If you are attending our RallyON conference on May 10 and 11, you’ll get to meet Chad. If not, track the Scaled Agile Delivery videos he has posted on his site. Thanks Chad for contributing so actively to Project Stratus!

As you can tell, it takes a while to get to the commercial product the right way to ensure the product will be a success for both Rally and its customers.

As we work at delivering the first release of our agile strategic planning product to support the first identified pattern, we are working with other Chads – Nina, Jeff, Dale, and others – to further our study of strategic planning patterns that would warrant product support. Please stay tuned.

Catherine Connor is a Product Marketing Director at Rally Software. She focuses on leveraging agile and lean values for the product manager role. She is the lead for Project Stratus.