Agile Development Blog

In a continuation on my last post on Eric Ries and The Lean Startup, I wanted to share how these concepts continue to ripple through Rally. (Learn more on how to apply these topics in your business at our upcoming in-person and virtual Portfolio Management Roadshow featuring Eric alongside an awesome line-up of speakers.)

Three weeks ago while in Denmark, I had a deep dive with customers on the topic. While in Copenhagen Denmark and talking with 40 European customers at Rally’s Agile Open Forum, one of the top 5 questions that group proposed was:

“How can we develop features that give the maximum long-term value and the minimum long-term cost?”

Vist Custdev.com for this "Cheat Sheet"

I believe you will find the answer to this question in Steve Blank’s customer development approach to differentiating new products or simply in the build-measure-learn cycle of Lean Startups. For Agile teams that can already build right and build fast, this answers the question of what to build!

By focusing on the concept of creating “validated learning,” a Lean Startup team does not provide solution development teams stories that are not validated or constructed to validate a hunch.  As such, the Agile backlog becomes prioritized by learning and risk.  The result is a team that couples Agile product development cycles with customer problem discovery and customer solution validation. What is great about this approach?  It works at the whole business or product-line level, and you can also slim this down for use with A/B testing of enhancements too. Your level of application only depends upon your scope as well as the scale and maturity of your Agile efforts.  The more Agile your enterprise is the more leverage you can have with these techniques.

The result of this work allows you to determine, if there is desirability for this solution before you commit to ship it.  As a result of understanding the intersection of feasibility, effectiveness and desirability, you can be sure to deliver features that have maximum value.  And, by working with a minimal viable product (MVP) concept, you can be sure not to overbuild that solution too.  In this way you can be sure to build the features with maximum value and minimal long-term cost.

To me, Lean Startup is a method to drive continuous innovation and brutal, entrepreneurial prioritization. But taken to the extreme, Lean Startup is a way of being and acting and can become an attribute of culture. In addition to speaking and teaching on the topic, we have had some customers and partners come to learn, teach and do with us. The following efforts demonstrate how these activities can become cultural.

Act like a scientist, not a fire fighter

In a tradition of Lean companies, we had one of our largest customers come visit our office in early October.  He and his company have adopted and scaled Agile very well.  Now, they are focused on creating validated learning to do concurrent set-based development on their toughest problems. He pointed us toward this HBR Article on Decoding the DNA of the Toyota Production System.  You will notice the Lean rules and principles from Toyota support the Lean Startup approach.  This customer’s hope was to share his learning to help make us a better partner.  His trip was a true gift.  Thank you, Pat.

Two weeks prior to our customer visit, our friends George Kembel and Scott Dorsey, from Stanford’s d.school were here in Boulder. The principles and method of design thinking are clearly wrapped into the Lean Startup.  In design thinking, the iterations include practices to empathize, ideate, prototype, and test/reframe. Typically, these cycles are used to create the initial design of a new product or service, but not at the d.school. In the d.school, students take these concepts into more of a continuous cycle to help shape emerging services or social startups. Like Lean Startup, the d.school is learning to run people and teams through fast and continuous cycles of build-measure-test to create a “continuous innovation to create radically successful” efforts.

In a serendipitous way,  I taught a seminar on customer development and business model canvas approaches to fellows at the  Unreasonable Institute.  In September, Zach did a crash course on “Why Lean Startup Approaches Work” for 120 folks at the Silicon Flatiron’s portion CU Law School and Boulder/Denver New Tech Meetup.  Like my first post said, it has truly been Lean Startup everywhere at Rally.

If this post was not concrete enough for you, my final Lean Startup post is on “How to Apply Lean Startup to Your Agile Rollout.”

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.

With the publishing of Eric Ries’ book, The Lean Startup, I can barely go a day without talking to someone about it. Eric clearly executed a lean startup on himself and this topic – by focusing on learning. Eric started much of his work a couple of years ago with his blog Startup Lessons Learned and by publicly speaking on the topic. I saw him first at Return Path, a local Rally customer, in May of 2010.  Since that time, he has continued to refine the principles and collected great stories for this book that speaks equally well to an new entrepreneur as a seasoned business professional.

The book is just a fantastic and hard-hitting summary of this approach to business, as well as a manual on how to teach entrepreneurial behaviors.  If Eric was a seasoned author, this would be a great book, but given the fact it is his first effort – it makes the book astonishing.  It debuted at #2 on New York Times Bestseller list!

If you do not know Eric or The Lean Startup model, it works by developing product/service in parallel with the customer in a market.  The method can be summarized by three words executed repeatedly; Build, Measure, Learn.  These cycles continue to help you assess whether to stay the course, pivot or stop.  The Lean Startup is a combination of applying Agile Development, and Customer Development methods, but draws on Lean, crowd sourcing/social and complexity to create a true collection of thinking and acting tools for today’s complex world.

Eric’s sub title really sums the book up well –

How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses

… as these ideas and thinking apply equally as well for venture-backed tech startup, impact investing, social startups or internally funded intrapreneuring efforts.  If you read his blog, you will see he A/B tested about 20 sub-titles to come to this one. So, not only is a great sub-title, but it is one that attracts the right market.

Have you clicked on the book image to buy it yet?  No?  Let me try one more thing!

For Agile teams, programs or enterprises, the message from this book should be clear: you need to start applying customer development approaches to the front-end of your Agile efforts. You can read about Rally’s latest customer development in the Making of Project Stratus; and you can see the results of these efforts at our Agile Portfolio Management launch in December.

As part of this launch effort, Zach Nies and I have been given a great gift in the last month of continuous lean startup (more on that in later posts). Last week, I found out that Zach and I will have the opportunity to interview Eric live on February 2^nd.  If you don’t buy the book, you should at least register for the 1 hour video event.

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.

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.

As larger organizations are diving into using Agile methods, we hear a lot of questions about how teams integrate various specialities and skill distributions. One common question that is frequently asked by traditional UX departments is “How will our work and focus change?” Moving from traditional design practices to agile design practices is a big step and requires a significant shift in both thinking and approach.

Jeff Gothelf is the Director of User Experience at TheLadders.com and is at the fore-front of the Lean UX movement. Jeff is also active in the Lean Startup community and posts frequently to his blog and twitter (@jboogie).

I first ran across Jeff at a talk that he gave at the SXSW conference this past year called “Lean UX: Getting Out of the Deliverables Business.” Jeff’s talk was excellent, extremely well-received by the audience and heavily discussed across the Lean UX and Lean Startup communities for quite a while after the conference. I frequently send copies of his Smashing Magazine article (written to accompany the SXSW talk) when UX teams enquire about the shift to agile thinking.

In this post, Jeff shares his experience in addressing the top 3 reasons that designers initially object to agile and ways that we can help introduce alternative thinking to traditional practices.

———-

When first introduced to Agile thinking and processes, user experience designers often balk. Years of software projects and interactive agency-driven initiatives have built strong waterfall muscle memory. Successfully integrating these designers into Agile teams and, more importantly, Agile thinking requires allaying their most important concerns. The three objections below are not the only obstacles to Agile and UX integration but they are the biggest ones. I’ve provided ways to overcome these issues that have worked with my team at TheLadders. Succeed here and you’ve taken a significant step towards creating a higher-performing team.

Objection #1: No more BDUF
BDUF stands for Big Design Up Front. It is what’s known in the waterfall world as the “Design Phase” – a period of time that can last anywhere from a couple of weeks to a couple of months where designers can take the project’s requirements and ideate, at length, over how the solution will manifest in interactions and aesthetics. Designers will typically explore various workflow options, data collection tactics alongside aesthetic, layout and typographical treatments. Even with the addition of a Sprint 0, which allows designers one sprint to get “ahead” of the development team, BDUF vanishes. Designers new to Agile will protest that they are not given enough time to think about the solution and that in no way can they turn around a design in the given timeframe. This resistance alone can quickly kill the momentum of an Agile team.

To understand how to resolve this issue, we need to examine its root causes first. BDUF allows designers time to think about the entire experience the team is building. The expectation is that at the end of the design phase, the entire product is designed and spec’ed out. In addition, this is typically the first and last time the designer will get to spend a significant amount of time on the project so everything must also be right as there’s no (significant) going back.

When introducing Agile to designers, it is imperative to stress that they focus on only a sprint’s worth of design work. In fact, they should hesitate to design too far “ahead” of the development team as priorities may shift after each incremental release and that additional work may go unused. Focusing on a sprint’s worth of work dramatically reduces the workload for the designer. All of a sudden, turning around a much smaller amount of design work becomes much more realistic in the given timeframe.

Second, Agile is iterative. There will be another sprint and it will provide another opportunity to refine and build on the work currently being implemented. The waterfall designer’s mindset doesn’t expect that. The expectation is that the work will be launched never to be touched again. By convincing your designer that this is the first iteration of the implementation, that learnings will be collected and that subsequent iterations will give her opportunities to update, improve and resolve the UX you begin to alleviate the concern that a less-than-finished piece of design is released to customers.

Objection #2: Minimum Viable Product
Designers don’t design Minimum Viable Products. They design robust experiences that demonstrate years of training and skill. The idea of putting out an experience that is “good enough” is antithetical to a designer’s mindset. To her, it feels like half-assing the project.

“Yes, I can lay out a simple, grayscale grid that displays the data but with a few more days I can create color-coded representation of that same data complete with hover states and interactive menus.”

This is a variation on a common refrain from designers new to Agile thinking. The idea that each iteration is being used as an experiment to prove a hypothesis runs counter to the on-the-job training many designers receive at companies and agencies they’ve worked with in the past. In those scenarios, there was typically a “big idea” conceived by a high-ranking stakeholder and the team executed that idea to its fullest. There was no opportunity to get a lightweight version of the idea out, validate it’s potential and iterate from there. This is the true power of the MVP.

A good UX designer is well-aware of the benefits of customer research. Couch the MVP as just that – a way to ensure we’re meeting customer needs. What is the least amount of product we can design to prove this approach is valid or not? Using the MVP as a research tool puts it neatly within a familiar UX toolkit, demystifying it and increasing the designer’s level of comfort with the technique.

There’s a second challenge with the MVP – who gets to define what is minimally viable? In many organizations it’s the development team. In others it’s the product owner. As the responsible party for the User Experience, the designer wants a say in this decision. By including the designer in this decision, you, again, increase their comfort level with releasing what they feel is an incomplete product. Because they had a say in it, they can reconcile the experience in their minds as “complete enough” for this iteration.

Objection #3: Collaborating with non-designers
Agile espouses collaboration and conversation. Designers are comfortable with these tactics, as long as their collaborators are other designers. When asked to discuss their unfinished work with their teammates, defense systems are engaged. At the root of the problem is the designer’s sense of uniqueness and value derived from a belief that only designers can design. Hence, why should she consider the opinions of a software engineer regarding the informational hierarchy or layout of the page? This objection is exacerbated by the other two mentioned earlier. The lack of up front design team and a drive to release minimally viable experiences early on leads to what designers perceive as “unfinished” work. It’s one thing to show rough sketches (both literal and digital) to another designer but a non-designer will likely misunderstand it, provide feedback on the wrong elements and critique elements that aren’t fully baked.

To mitigate this, focus these conversations with non-designers more on functionality and feasibility rather than design elements. Review the rough work for the interactions and data requirements and set those expectations up front. Stress to your designer that discussing these directional sketches earlier in the process provides the developers with a better idea of what they’ll need to do, especially on the back-end, to bring this experience to life. If done well, these initial conversations will build a level of trust between designers and others on the team paving the way for more open discussion and the ultimate contribution of everyone to the design.

While there are other reasons designers struggle with Agile adoption, these three are the hairiest ones to overcome. Each one is a challenge and can take many months to get through. The mitigation tactics laid out in this article are techniques that have worked well for TheLadders. They are, by far, not the only way to bridge these gaps and bring teams closer together. What’s worked well for you? What other objections do you think should be on this list?

Ben Carey is an Agile Coach with Rally Software. You can find Ben on Twitter at @bencarey

I leave on sabbatical next week to be the Entrepreneur in Residence at the Unreasonable Institute as they kick off their six-week program for 2011 (see my earlier post for background on the sabbatical). If you are in Boulder or flying by this summer and you dig social venture efforts, you should definitely consider attending one of the Unreasonable Events.

The Institute’s Global Summit and VIP reception were fantastic last year and attending these events are what got me hooked on spending my sabbatical with this group. Daniel, Teju and Tyler knocked the ball out of the park last summer and I can’t wait to be more involved this year.

When I say involved, I am going to be at the Unreasonable headquarters four to five days a week and leading recitation sessions for five of the 2011 fellows. I am also going to be working on the business model for the Rally Foundation. The Rally Foundation is the evolution of our corporate social responsibility (CSR) team and additional corporate stock funding. The CSR group has ramped up in 2011, and we are now focused on making our efforts sustainable in the long-term. We do not just want to grant 5% of our capital every year, we want to do more and more every year.

I get inspiration for a self-sustaining foundation model from three examples:

• The Salesforce Foundation’s Social Enterprise Model that is funded through license sales
• The DemandTec Retail Challenge funded by the company and partners
• The Whole Foods’ Whole Planet Foundation microfinance loan pool, donated by customers

To kick off Rally’s Foundation efforts and the Unreasonable Fellows of 2011, Ben Carey and I will be teaching a course on Business Model Canvas on Tuesday, June 21st at the Atlas building on the University of Colorado campus. Our course will be based on Ben’s post on the 1-hour session he gave at our RallyON conference in May, along with Alexander Osterwalder’s post about how Business Model Canvas links with Steve Blank’s customer development in the area of social entrepreneurship.

In the spirit of being unreasonable and helping to kick-off our Foundation’s efforts, we have decided to help sponsor Unreasonable.TV this summer. This is a fantastic effort focused on sharing the experiences and stories of the the Unreasonable entrepreneurs. Our Foundation team is really excited about the alignment of vision and values between the Unreasonable Institute and the Rally Foundation.

Let us know what you think and hopefully we will see you at some of the Unreasonable events this summer.

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

You may have heard the news today about our $20 million funding led by Meritech Capital Partners. Meritech is a leading provider of late-stage venture capital to category-defining private technology companies. We are excited about the opportunity and welcome Meritech to the Rally team.

Read more about this announcement and other company news, events, and culture at our new Rally Company Blog. You can also subscribe to the company blog via email or RSS.

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

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

This is a story of how I went from being the poster child for bad posting etiquette on pm.stackexchange.com to becoming their poster child for fast learner! A poignant tale of hubris, struggle, fear, benevolent mentorship, and redemption.

Prequel: The Lure

Some colleagues of mine at Rally Software (Karl Scotland, Ken Clyne, Eric Willeke, Ben Carey, and Ryan Martens) have been telling me about how much they were enjoying their experiences in StackExchange. My CTO colleagues Zach Nies and Mark Gammon have also been enthusiastic about the value of being engaged in the StackExchange community. But I was intimidated. I feared I wouldn’t know how to appropriately engage in either asking a question or answering a question. It turns out my fears were well-founded.

Scene 1: The Leap

I finally decided to jump in. I set-up an account, fairly easy to do. I perused some of the questions already posted by others. I saw the tags and the replies. I saw the voting. Somewhat intimidating. But, I had a topic I was really excited about. I thought it would make a great question. And so I made the leap; I took the plunge. And this is what was wrought:

Scene 2: The Faux Pas

Not a bad question. The problem was that in the text area below the question title, I gave further detail on the question. A lot of detail. I pulled a major faux pas: I waxed poetic on what I thought the answer was. (I’m not going to go into the topic here. Trust me. It was lengthy and unyielding. :-(

Fortunately for me, however, very timely and gentle advice appeared from Mark Phillips and jmort253:

Could they have been any nicer? What a great community!

Scene 3: Meeting with the masters

The good news is that help was on its way. Back in March, we’d spoken with Joel Spolsky (co-founder and CEO of StackExchange.) Ryan’s goal in talking with Joel was to look at how we at Rally could incorporate StackExchange into our upcoming RallyOn conference in May. How could we work together to create community in StackExchange as we were creating community in the conference?

The result? We brought in the great StackExchange masters Anna Lear and Mark Phillips to the RallyOn conference. In his opening remarks at the conference, Ryan introduced our two Zen StackExchange masters and Ryan’s hope for how we could all engage with them to kick start a powerful presence of the Agile community within StackExchange.

Yea! I was going to actually be able to work with Mark and Anna to become more comfortable and more productive in StackExchange!

Scene 4 : Lessons Learned

After Mark held a small session on getting started in StackExchange, I saw him in the hallway. I’d missed the session, but he quickly filled me in. It turned out, he’d used MY question/answer fumble as an example of how NOT to engage in StackExchange. I had become the poster child for bad StackExchange etiquette :-(

But both Anna and Mark quickly took my under their wing. We edited my original question. We commented on one of the answers. We created a new question. And we answered another question. The result was a new exchange of comments:

Close: A Happy Ending

Today, good news abounds. Mark recently wrote a phenomenal blog post: Why StackExchange is Hotter than Twitter

I continue to stay engaged asking and answering questions. I’ve learned to keep my questions short, my comments short, and my answers short. And, I’m gaining reputation points and earning badges, still with gentle guidance from Anna, Mark and “jmort253″.

My Rally colleagues continue to post as well. It is exciting to see the Agile community begin to expand in pm.stackexchange.com. Provocative questions with great answers. And through the tags, we can watch the expansion into other topic areas.

For the happiest ending of all, I’m saving the best for last: my email yesterday from StackExchange!

“Congratulations — you are one of the top new Project Management – Stack Exchange users for the month of May 2011! http://stackexchange.com/leagues/month/pm/2011-05-01 ” There was also the caveat that my name would not appear in the list of users because I still need to earn more reputation points. Okay, June, you are going down!

Help keep the story alive!

To wrap things up: I not only survived jumping into StackExchange; I love it. I’m hooked. So, my story is not over.

Now, I’d love your reply to this post to tell me how you are getting involved in StackExchange.

Jean Tabaka is an intrepid intercontinental traveller, a 6-badge holder in pm.stackexchange.com,  author and Agile Fellow at Rally Software Development. You can follow Jean on Twitter at @jeantabaka

In conjunction with the Lean Software & Systems conference this week, Rally is releasing a powerful Enterprise Kanban Board that provides a simple way to visualize the status and flow of work through a software project.

The addition of full, enterprise Kanban support to Rally’s Agile ALM platform provides users with an elegant visualization of work across projects, teams and the entire organization. It can be customized for each project, allowing users to choose which Kanban states are displayed and which states are mapped to Rally’s core schedule states. This allows teams to model their unique processes within Rally and view rollup reports between teams — providing complete visibility into the quality, status and progress of projects.

The Enterprise Kanban Board allows users to:

• drag-and-drop ranking and state changes
• block and unblock stories
• visually flag each story with user-defined states
• customize WIP (Work-in-Progress) limits with color-coded status indicators
• display stories and/or defects
• edit ready-to-pull or blocked items

Cycle/Lead Time and Throughput reports provide valuable metrics around how many work items are completed in a given time period or the average time that it takes a work item to pass from one state to another. The new Enterprise Kanban Board can be installed by clicking the + icon on the Rally menu and then choosing the Kanban Board from the App Catalog. And, if you have been using our current Kanban App, here are instructions on how to convert those stories to the new Kanban board.

In this video, I’ll demo the full enterprise Kanban support Rally is now offering within Rally Enterprise and Rally Unlimited Editions.

Todd Olson is the VP of Products at Rally Software. He is a marathon runner and cake baker. You can find Todd on Twitter at @tolson.

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.