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.
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.
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:
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.
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.
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:
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.
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.
On April 21 in Atlanta, the Lean Software and Systems Consortium will come together for its second US conference. Last year’s event in Miami was “amazing” according to Jean. So this year, Rally is exhibiting, I am speaking while Jean and Aaron are running the open space on Friday. The price per attendee goes up by $250 on March 31st, so if you do intend to go, REGISTER now.
At our booth, Rally will be demonstrating its product support for highly-visible Kanban, WIP/Cumulative Flow reports, and cycle-time metrics. Join Alan Atlas, Jean Tabaka, Aaron Sanders and Craig Langenfeld in our booth.
I will be presenting an experience report titled: PDCA: Beyond Simple Inspect and Adapt. On spring break this week, I’ve been thinking more about the details of my talk. Here is my abstract and outline for those of you who might consider attending:
Lean and Kanban focus on practices of continuous flow of product delivery. Plan-Do-Check-Act (PDCA) is a Lean discipline that moves beyond inspect and adapt of Agile team-level processes. At a corporate level, PDCA provides guidance for strategy as well as problem-solving work. In 2009, I led Rally’s move to PDCA for the company’s strategy process at both the annual and quarterly levels. My primary guide was Pascal Dennis’ “Getting the Right Things Done”. In this experience report, I share Rally’s PDCA first year of adoption: where we started, how this impacted our corporate behaviors, and where we are now. I want to share Rally’s story to compel participants to embrace PDCA and get good at it. I ask each participant to come with its organization’s #1 goal and success criteria. I will close with a planning A3 exercise from Pascal’s book .
Outline
What brought me here—background on why I am passionate about sharing my organization’s overall Lean story including the addition of PDCA, A3’s and concurrent set-based development. This talk focuses on PDCA as the critical step in increasing structure and discipline in strategy execution.
Point of View – Use PDCA to move your planning horizon out and as the principle governing mechanism for organizations in continuous flow.
Benefits — Mature your strategic planning and execution environment to handle the complexity of increasing speed, agility and scale and to gain alignment, pull and innovation.
Where we were and what was not working
The context at Rally was based on a couple of key concepts:
Core Values, Core Purpose, Sandbox and BHAG from Jim Collins
3 to 5 Quarterly Rocks, success criteria and Scoreboards from Gazelles
Rock team structures – cross departmental and story based
Facilitated, highly collaborative cross-departmental meeting of 30+ managers and above
Highly critical, non-cross departmental initiatives were de-prioritized
ORID process added to keep from jumping too solutions, but the data was not visible enough
What we decided to do about this:
Explanation of PDCA — A brief overview of PDCA in general and then specifically what I used as guidance from the Pascal Dennis book, “Getting the Right Things Done: A Leader’s Guide to Planning and Execution”.
Our initial experiments with A3 process the year prior — Working with our Ops team and product marketing teams on problem solving using real data
First quarter — How we kick-started Rally’s company-wide adoption of PDCA . I describe our “Mountain Team” and their transitional role.
Defining Rally’s True North
Creating our second level tree with current and needed metrics
Socializing these throughout the company seeking feedback in anticipation of our annual and quarterly planning
Started new experiments based on quarterly planning decisions
Next Quarter – Review new experiments, discussed learning and drive A3’s into the planning process
Mid-course adjustment by Mountain team, in middle of the quarter – What we discovered working and not working
The rocks were all dependent on each other.
Had to run Rock of Rock team meetings to steer to a final solution
Coordinated release planning would have
Final quarter – We worked to expand the plan. We took the Mountain team’s True North and feedback to drive our PDCA for Rally’s Annual Corporate planning by:
Taking company-wide feedback into our Annual planning to collaboratively drive cross-department A3 creation around each branch of the tree
Mountain Team retrospective over the course of year 1 that helped create a planning rock team. The Mountain team’s role as a transition team ended.
Year 2 – Doubling down our efforts to go from amateurs to intermediates —Changing our process to institutionalize A3’s and PDCA as our strategy execution approach:
Quarterly rocks moved to a world of pre-defined from developed on the fly
Quarterly planning moved from ad-hoc based on yesterday’s weather to more programmed based on True North and meeting the target metrics
Strategic planning worked to validate annual True North in the context of long-term planning, shared vision development, cross-boundary collaboration and larger systems
What we learned and what you should do about it
The cycle of adoption is a year, quarterly cycles work to improve the process, but it is hard to make leaps on a quarterly basis.
Year 0 – Introduce Lean thinking (A3 in our case)
Year 1 – Introduce PDCA (Novice)
Year 2 – Invest or abandon (Your choice)
A3 is now the language for problem solving
Making sure we are solving the right problem (aka slowing down to speed up)
Do not have a overall guidance team steering the continued PDCA process – it is owned by the “team”
Putting pressure on the organization to get more clear about our economic models to mature from “Theory-based decision making toward the right solution,” Now “Data-driven decision making toward the right problem”
Where to start – The Strategy A3 an exercise
What is next? – We call it the Innovative or Lean Organization. Seeing large systems, collaborating across boundaries and creating your reality.
Point of View – Use PDCA to move your planning horizon out and as the principle governing mechanism for organizations in continuous flow.
Call to Action – Introduce the language of A3’s through problem solving or Strategy A3’s
Benefits — Help build a company of problem solvers to focus your efforts on the critical few things.
Where I hope you go with this: Great companies build great software, great experiences and work on creating win/win scenarios.
Are there other questions you’d like to see answered in Rally’s experience report on Plan-Do-Check-Act? I look forward to seeing you at Lean SSC.
Recently, I was working on an introductory presentation about Kanban. A “thorough” Google search revealed how drawn out and convoluted many Kanban explanations can be. Was there one true answer I was missing? Something nice and succinct like, say, a tweet on twitter?
Acting on this and laziness, I decided to pose the following question to twitter:
I was so surprised by the number of great responses that I’ve decided to compile and share them with you here:
giff24:#kanban 130 chrctrs? PLS!!! I dnt hve time or patience 2 rd that much
erwilleke:#kanban combines systems thinking with a work-limited pull system to allow rapid maturation of teams and delivery of software.
davenicolette:#kanban “What 100-130 characters would you use to describe Kanban?” I’d use the cast of _Who Framed Roger Rabbit?_
knoxgourmet: Kanban is Scrum without the mess, no sprint planning, no midrange planning, no MSG headache.
kjscotland: Map the value stream, visualize, limit WIP & establish cadence. Reduce WIP to improve flow of value and individual fulfillment
agilemanager: #kanban visualize flow & limit WIP to encourage evolutionary change towards a lean outcome & high maturity culture
Sprezzatura: First establish your value stream. Next limit your work in progress. Then visualize & learn from your workflow. #kanban
most_alive: . #kanban: value flows, post-its move, step,step,step, workers unite
neontapir: Kanban uses visual signals to track and optimize work delivery through key stages in its lifecycle.
I like the commonalities around value, visualization, limited WIP, pull systems, cadence, and flow. This tells me that Kanban is speaking a common and useful language to a lot of us. And, its value can be articulated in a tweet.
But my quest goes on!
I encourage you to add to this list by submitting your own 130 character Kanban definition either as a comment to this post or as a tweet to me (@jeantabaka and use #kanban in your answer.)
In April, I’m attending the Lean SSC conference in Atlanta. There will be a lot of discussion about Kanban. I’ll personally carry all comments and tweets to the conference for inclusion in the discussion. If you’re able to attend, let’s stretch the envelope and go beyond 130 characters on Kanban.
I have been told repeatedly that my brain thinks in pictures, and as a result I have to work hard to communicate my logic effectively in words. Recently in my argument against an Agile Process Maturity Model, I made a comment that Agile is an instance of Lean.
One of the replies on the Agile Alliance Group of Linked-Incountered that my statement isn’t accurate – and in fact a team being both “Agile and Lean” is an oxymoron. So, I looked in the mirror and said this must not be clear. I need to communicate better in both words and pictures.
“The term Oxymoron originates from the Greekoxy (“sharp” or “pointed”) and moros (“dull”). Thus the word oxymoron is itself an oxymoron.” Wikipedia’s Etymology for Oxymoron
Instead of trying to figure out which is sharp and which is dull, I thought I would present my mental model on the evolving Agile software development ecosystem.
Agile as an umbrella term
First and foremost, Agile as an umbrella term was hatched in 2001 to represent a “way” of developing software that is focused on rapid value delivery, collaboration with a customer, face-to-face communication and measuring progress in working code. It casts a wide net of iterative and incremental process frameworks including RAD, Spiral, Extreme Programming (XP), Scrum, DSDM, Feature-Driven Development (FDD), Lean Software Development, OpenUP and Kanban. These methods stand in contrast to highly structured methods that tend to measure success based on meeting plans and following the process.
My rendition of the geneology of Software Development Approaches
Agile has evolved both bottom-up and top-down based on the evolution in technology infrastructure, tools and guiding ideas of our industry. It is symbolized by increased productivity, speed to market, response to change and craftsmanship.
I believe it is not a fad, but a natural by-product of the increasing scientific as well as craftsmanship approach brought to this critical industry.
Lean merges with capital-A Agile
I see the pictured genealogy tree merging Lean software development methods together with capital-A Agile methods. This is because the physics behind Lean design and production are the same physics that make Agile deliver impacts like we see in the Agile Impact Report from QSMA – 50% faster time-to-market and 25% increased productivity.
Small batch sizes, short cycles that create rhythm
Reduction in queues through pull
Reduction in work in process inventory
Design quality in
Stop-the-line defect control
Value streams the link to the customer
Integrated learning through reflection
Last responsible moment decision making
These patterns are the same for an effective Lean effort or an effective Agile effort. This thinking has me advocating that Agile is an instance of Lean, not just a ground-up new tree that was born solely from the roots of OO, Spiral and RAD. I am having a hard time seeing the black and white separation between agile and lean. This is all grey, maybe I should say blue and red based on the diagram, to me.
What do you believe – is Agile is an instance of Lean, or together are they are an oxymoron?
Kanban is great. I value that it seeks immediate fixing of problems, which is referred to as continuous improvement. I love that.
I value that teams are prepared to “Stop the line” and not allow process or defects to continue unscathed. I love that too.
I wonder what Ferris would say about "Fixes that Fail"
But for all that, I haven’t seen clear Kanban practices for long-term trending that would help us identify or capture those “Fixes that Fail” or “Unintended Consequences.”
I am concerned that the emphasis on immediate improvements may fail to capture what long-term negative impacts may be lurking. I worry about a “not seeing the forest for the trees” effect.
So what does my concern about Kanban have to do with Ferris Bueller?
It is admittedly an odd connection. Specifically, it refers to a classic line in the movie “Ferris Bueller’s Day Off.” Ben Stein, Ferris’s history teacher, asks the class, “Smoot-Hawley Tariff Act: raised or lowered tariffs– anyone? anyone?” trying to get at least one student to respond. Classic line from a classic movie, though most people believe that the line was about a fictitious act.
Smoot-Hawley, unbeknownst to Ferris Bueller and most of us, in fact RAISED tariffs in an effort to protect the US economy from an influx of foreign goods during a challenging national economic downturn.
At the time, the “immediate fix” of the Smoot-Hawley Act seemed like a good one. Ultimately, however, the pundits of the time declared that it wasn’t enough to save the country from the economic ravage we now know as the Great Depression.
Today, economists are reconsidering the supposed low or non-correlation of the Smoot-Hawley Act and the Great Depression. Did that immediate fix actually have a lot more to do with the Great Depression than had been understood? Hmmm. Something to reflect on for future possible fixes. The debate is absolutely there. An immediate fix (like Kanban fixes or Smoot-Hawley fixes) may be one of the “Fixes that Fail” or have “Unintended Consequences” that can only be seen through a longer view lens.
The value of this long-term reflection, whether in Kanban or in economic fixes, on such a small fix can have far-reaching impacts on our overall systems.
As Stein points out in his article, economics is not physics. For my part, our analogous comparison is that software development is not manufacturing. We need to walk the walk of systems thinking by being ever vigilant to seeing the entire system, the whole. And that means acknowledging that we will absolutely have delayed feedback loops on our fixes. Longer term reflection and retrospectives can help us make more informed “immediate” fixes as we move through ever challenging world of software development and delivery.
Jean and I made a commitment this quarter to go deep on Lean software development. We have been working with Lean and Agile for years, and really want to engage you in a dialogue to help explore the topic of how they relate.
Jared from Subway on his exploration of a different type of "lean"
To help focus our research, tell us, what are your favorite resources for Lean and Agile?
I don’t want to bias your feedback too much, so here are a few of our current favorite resources as a jumping off point:
Lean.org – Jim Womack’s site about Lean across industries
RallyDev.com
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.
Nowhere have I seen these techniques applied to software like I have experienced in 
