Thu 5 Feb 2009
Today at Rally, we completed a redesign of Agile Commons and changed a number of other things in our online communities. As a result, you are now receiving RSS updates from the AgileBlog instead of the Commons Blog in Agile Commons. If you would like to continue following RSS feeds from Agile Commons, please take a look around the redesign and subscribe inside the Commons.
To understand all the things we are doing with regard to this blog and Agile Commons, click on More.
Mon 2 Feb 2009
At Rally, we measured ourselves by winning the third consecutive Jolt Product Excellence Award and delivering 6 product releases to a fast-growing list of great software-driven companies.
We leveraged our Agile and customer community and new products to deliver feature priorities based on our customer’s feedback and votes.
With the help of QSMA, we benchmarked that Rally customers are 50% faster to market and 25% more productive than industry averages.
On the local front we were named one of the best companies to work for in Colorado as well as awarded the Affiliate of the Year by the Entrepreneur Foundation – these are awards we strive for and help us validate we are building the type of company that can endure.
You can see the customer and financial growth that resulted from these market achievements in an announcement we issued this morning, or you can go to the Rally by the Numbers page on our web site to see the transparency we use to communicate our progress.
On the Agile industry front, the Agile Alliance had a blow-out conference in Toronto in 2008. It was the culmination of my two years on that board and a very fulfilling experience.
We also saw this market grow with new customers and a host of incumbent as well as new competitors.
The Agile tools and applications market became real and Gartner put out a market map as a prelude to a magic quadrant; good news Rally was ranked in the “Positive” category.
At Rally, we’ll be busy doubling our efforts to make our customers successful with Agile and effective on both prongs of short-term efficiencies and long-term growth.
Tue 9 Sep 2008
When we started with Scrum at Rally years ago, we used to just do a design meeting every few weeks with a couple of key stakeholders to talk about what was coming up and prepare the backlog. This worked relatively well, but as we added more discipline to our release cycle, the ad-hoc backlog planning our Product Owners were used to started to break.
If you want your team to be able to make a commitment around 8 weeks of backlog, you need to do somewhat more prep than you would with vanilla Scrum. And if you want your team to meet that commitment, you need a mechanism to manage your stakeholders to minimize backlog churn.
About a year ago, we chartered a Product Council to solve this problem. The Product Council is led by the uber Product Owner for each product, and consists of stakeholder representatives from all interested departments. This team operates as lightweight Scrum that grooms the backlog for the next release, working in 4 meetings that are 2 weeks apart.
Meeting 1: Retrospective on the last Release
The first meeting falls about a week after the engineering team does Release Planning. The Product Owners review the plans for each Scrum, talking through the stories for the stakeholders. We’ll also highlight the work that definitely does not fit into the release. Usually we have commitments from the development team as to what will be delivered.
We then ask people to rate how they feel about the product (what we plan to deliver) and the process (how we decided). We tabulate these numbers, and then move on to a regular retrospective on the process – what went well over the last 8-week cycle, what didn’t go well, and what should be changed going forward.
Meeting 2: Bring Your Ideas
In the second meeting, we hang the roadmap and various backlogs on the walls – usability, platform, deferred defects, technical debt, customer requests, etc. The Council spends about 20 minutes “walking the walls” – reviewing the roadmap and various backlogs. People add items they think are missing, shift items forward where necessary, and talk about issues and concerns. The purpose of this meeting is to identify those items the Product Owners should research for the next release – we usually leave with about 10 epics that need investigation.
Meeting 3: Presenting the Design Continuums
The Product Owners spend about 2 weeks researching those key epics, and come back with rough design continuums (backlogs) for each one and high-level estimates. In Meeting 3, they present these ideas. Sometimes an epic is too complex or unknown to be considered for the next release, or perhaps it’s too expensive to build given it’s value. The Product Council votes to rank the different epics.
Meeting 4: Presenting the Detailed Backlogs
Based on the voting from the last meeting, the Product Owners go off and begin blending the strategic epics from the Product Council with small customer requests, deferred defects, and other small items. In Meeting 4, we present the detailed, forced-rank backlogs that we intend to present to the development teams in Release Planning. We talk about what’s changed and see if there are any last-minute, “Stop the line” type shifts that have to happen. We get a fist-of-five commitment from the Product Council to confirm their support for these backlogs.
Moving forward, I’ll post more details about how these specific meetings work.
or, Subscribe via email:
RallyDev.com
