Agile Development Blog

40 preview customers, 34 builds, 3 launch events, 1 product. That’s what it took to launch our Agile Portfolio Management solution. Following Rally’s latest customer development project (see Ryan’s Lean Startup post), here’s how it all happened and Rally’s gift to you for the holiday season…

40 Preview Customers

A year ago, we put a call out to the Agile community. We knew to get it right, we had to first learn how customers currently managed their strategic plans, and the challenges they were encountering. So we scheduled many, many interviews talking to development managers, product managers and program managers currently working in large Agile development organizations to identify our “earlyvangelists”: those feeling the pain and feeling it badly enough that they crafted a way to solve it. We found most of the earlyvangelists were using Excel as their strategic planning solution – quite a flexible option for planning, but very tedious and manual to track development status of these plans.

As we dug deeper, a common set of needs quickly emerged from these interviews:

1. Highly customizable - Every organization seems to use different terms to refer to their strategic levels (features, projects, themes, epics, SAGAs, etc.), and how many strategic levels they tracked. There is often a strong attachment to that taxonomy.
2. High-level development status - Too much time is spent in Excel collating development status information to inform audiences outside of development. Questions such as: Did we start that initiative? Will we be able to deliver that work by this date? How much time have we spent so far working on this thing?
3. Tracking marketable items – As Agile has scaled in development, the business is drowning in user stories and needs a way to track additional information such as: value, risk, high level size, cost and sometimes unique information like the name of the product manager accountable for delivering a feature.
4. Realistic roadmaps – Roadmaps are mostly created in PowerPoint without accounting for actual development capacity. That results in overly optimistic plans and missed expectations. The challenge is exacerbated when teams cannot be fully cross-functional because the value to deliver requires specialized skills, often with limited yet high-demand capacity.
5. Alignment reports - There is a need to report back to the business that development is on track with the strategic goals. Most often those are created in Excel by manually and tediously pulling information from existing tools.

From that list of identified needs, we created our backlog of features to build in our MVP (Minimum Viable Product), and took names of customers willing to install it. What was in it for them? Helping us build a supported solution to their current challenges.

We also engaged with Rally coaches and industry experts, like Dean Leffingwell, to ensure our solution would support practical and proven ways to scaling Agile.

34 Builds

Our very first MVP was actually provided to us by one of those preview customers who had been trying to solve the problem on his own – a true sign of an earlyvangelist! Thank you, Stephen, for your contribution to this project.

The MVP – named Project Stratus – was a rich client application connected to the Rally platform.  That separate application allowed us to clearly separate our development resources – those focused on our current product roadmap – from our customer development resources, and to iterate quickly to incorporate earlyvangelists feedback. We produced 34 builds in that period, about 3 each month.

Once it became obvious that we were on to something of great value to the Agile community, we started allocating core development resources to implement the critical features in our flagship product, Rally ALM.

Our hypothesis of providing a separate application well integrated with Rally was invalidated. Earlyvangelists were clear: they expected to have both strategy and execution solutions in one single environment, so the strategy was visible to development teams and execution information was available when building strategic plans.

3 Launch Events

After 34 builds, we are ready to launch the product to all customers! To unveil our entire Agile Portfolio Management solution, we are getting on the road and rallying software and business celebrities to share their knowledge on the need for businesses to join the Agile curve. We will launch our solution in the Bay Area, Boston and Dallas. In-person attendees will have the opportunity to:

• Meet industry experts such Geoffrey Moore, Dean Leffingwell and Dave West
• Meet preview users, from Getty Images, The CBORD Group and John Deere, to learn how they used the highly-functioning MVP to help steer their Agile portfolios over the last year
• Participate in breakout sessions to get up close and personal with our Agile Portfolio Management solution

Not to foreshadow too much, this launch signals a major advancement for the Agile community, one that links the business and technical parts in agility. Now that is what we like to call – Scaling Agility.

1 Product

On Dec 6, we will launch the first increment of our Agile Portfolio Management product. That increment will address the most critical needs identified above. As 2012 unfolds, we will continuously deliver additional increments of the product roadmap that we validated in our customer development effort.

Don’t miss the chance to kick off Agile Portfolio Management in your organization!  We are sending quite a crew of Rally folks to each launch event to answer questions and demo our solution. We hope you will jump on that opportunity!

To sign up, register at www.rallydev.com/rpm for your preferred city. If you cannot attend live, sign up for the webcasts that will broadcast a portion of the live events.

(This post is the eighth in our series Scaling Agile to the Strategic Level)

Catherine Connor is Product Marketing director at Rally Software, with a passion for bringing Agile to product management. She loves hiking the Colorado foothills and cheering on the University of Colorado women’s basketball team.

Geoffrey Moore, a leading high-tech strategist and author of the bestselling Silicon Valley bible Crossing the Chasm, is speaking at Rally’s December 6^th launch event. His new book, Escape Velocity: Free Your Company’s Future from the Pull of the Past, offers a pragmatic plan for established enterprises to move beyond past successes and drive next-generation growth from new lines of business.

We chatted with Geoffrey last week about the focus of Escape Velocity, his thoughts on how companies can capitalize on their portfolio of opportunities, and why he’s excited to speak at Rally’s Dec. 6 launch event. Watch highlights of our conversation below, and join us next Tuesday to hear Geoffrey talk about how established companies can create and sustain next-generation business growth.

Geoffrey is speaking at the first of three Rally launch events that bring together authors, technology thought leaders and industry peers to discuss how to bridge the gap between development execution and business strategy. Sign-up to join us in-person or via live simulcast:

• December 6, 2011, Menlo Park, CA, 9:00am – 12:00pm (PST)
• December 8, 2011, Boston, MA, 9:00am – 12:00pm (EST)
• December 13, 2011, Dallas, TX, 9:00am – 12:00pm (CST)

Tune-in to our December launch events to hear Rally’s big news on the future of portfolio management, and thanks to Geoffrey Moore for giving us a sneak-peek of his keynote.

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.

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

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

Wagged by Plans: Is It Time to Change?

Do any of these problems sound familiar?

Execs play an Agile steering game

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

This post has been a long time coming. I’ve started and restarted it at least a half-dozen times.

Quality – there may be no more multi-faceted and powerful attribute in successful software development. Quality is central to everything we do and seek.

• Higher quality leads to greater productivity, throughput and velocity
• Higher quality leads to increased responsiveness, reduced cycle-times, shorter lead-times
• Higher quality leads to improved customer satisfaction, employee satisfaction
• Higher quality leads to better predictability, reduced risk, improved decision making

Or at least that’s my hypothesis…

And that hypothesis is widely shared amongst the Agile and product development communities.  We’ve developed numerous principles, practices and techniques intended to improve quality:  Test Driven Development; Continuous Integration; Automated Build and Deploy; Pair Programming; Customer Demos; Behavior Driven Development; Acceptance Test Driven Development; and Set-based Design techniques are all at least partially focused on yielding quality improvements.

But quality can’t simply be viewed as a set of tools and techniques – independent variables/levers which we hypothesize will lead to improved business outcomes. Quality is also a business outcome unto itself.

This series emphasizes the need to focus on business outcomes (success) first – methods and practices second.  So, putting aside the methods and good practice assumptions of Agile, and focusing solely on the business outcome of improved quality:

Quality = Fewer Defects in Production

We apply Agile quality practices and techniques, because we believe that doing so will yield improved business outcomes – quality (fewer defects in production) being one of those outcomes – along with productivity, predictability, responsiveness, customer and employee satisfaction.

Large, manual, end-of-cycle execution of formal testing by an independent QA organization is also a method aimed at improving these business outcomes. I hypothesize that it is less effective than alternative Agile techniques. But I don’t take that on faith, and neither should you. We must test our hypothesis.

How Do We Measure Quality?

There are innumerable quality metrics that have been devised over the years – each with its own strengths and weaknesses.  In my experience, it’s important to keep metrics simple, and to not let great become the enemy of good enough. In other words, if you have a metric that does a good job of providing insight into the quality of your product/solution, and is simple to collect and interpret; that is likely better than chasing after a metric that will do a great job, but would be more complicated.

For my part, I’ve had success over the years using a couple relatively simple metrics:

• DEFECT DENSITY – # Defects / KLOC
• DEFECT ARRIVAL – # Defects Identified / Month

What Do We Consider a Defect?

In both cases, I include only defects in the production system.

Measuring defects found and eliminated during the development cycle may be useful for managing your development and quality processes.  But from a business outcomes perspective, our focus is reducing the number of defects that make it to production – not making assumptions about how or when to achieve that.

Not All Defects Are Created Equal

Any good metric should drive in more questions than answers.  I find it useful to tag defects with information about type and severity, so that we can consider some of those questions more deeply.

• Our defect density is high; but our severity 1 & 2 density is low. What is the impact on other outcomes (productivity, customer satisfaction, etc.) if we were to invest in reducing our low severity defects?
• Our defect arrival is very high immediately following a major release. But the defects are mostly Type = Usability. Why are our customers having such a tough time using our new features; and how can we ease them through the learning curve?

You may have some hypotheses based on these questions. Perhaps those hypotheses involve application or improved use of Agile tools and techniques. What experiments would you run to prove or disprove your hypothesis?  What new questions will those results yield?

This is the third 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.

Isaac Montgomery is the harried father of twin sons, 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

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.