Have you ever been part of a company where your value to the organization seems to diminish as the company grows? Each time I have worked for a growing company, it reaches a point where the early employees leave (or are asked to leave) because no one seems to perceive their value anymore.

My story about a great company and its growing pains

I saw this happen at a highly successful company with a suite of hardware and software products. When I joined, the founder was leading the product management group responsible for about $250M in revenue. His product vision and his code were key reasons why the company held its dominant position in the market. Repeatable large-scale execution wasn’t his passion or gift, but (like most technical founders), he was an amazing innovator.

About a year after the company went public, the founder was asked to step down from his position. His future with the company was in serious question. In the maelstrom of execution as a public company, he was considered a risk. Why? Everyone was focused on removing any obstacle that got in the way of making quarterly numbers. After all, his strength was on future-looking vision and innovation.

Sadly, it seems that every successful company has moments where the focus on quarterly and annual execution can snuff out the future, both future-looking people and future-looking products.

What is this about?

What happens when a company’s first product goes mainstream and is the source of significant revenue?

  • It gets more difficult to to be consistently innovative; innovation seems like speculative investment in the future.
  • The inertia of success tends to run over anything that can’t prove its value in this quarter or next.
  • The culture tends to shift from embracing uncertainty to embracing repeatable execution.
  • Urgency shifts from figuring out what’s going to work to executing on what’s working.

In effect, the company moves away from embracing ambiguity and innovative people. Success is measured instead against steady, efficient execution of those products in the company’s portfolio that guarantee quarterly results. This may appear to be great – as long as what has been working in the past continues to work. The problem is that the pull of the past can be a killer. Why? More and more companies are waking up each morning trying to figure out how to disrupt your market to their advantage.

Is there any hope?

Last year, two important books were published to help balance the tension between immediate portfolio execution and long-term innovation: Escape Velocity by Geoffrey Moore and The Lean Startup by Eric Ries. Geoffrey Moore offers guidance on how to manage three investment horizons to ensure your company’s future. A great complement to this view, Eric Ries provides a framework for thinking about the extreme uncertainty inherent in new product and new market development.

Both books give new product and market creators great language for making future-looking business cases to execution-oriented people. They also create a compelling framework for portfolio planning. Their combined wisdom offers great insight into why we need to act differently, how to think about portfolio steering in a new way, and what to do in order to invite innovation back into our organizations. This is powerful guidance for investing in the future of your company and building a culture where your people will thrive.

Escaping the “pull of the past”

In Escape Velocity, Geoffrey Moore introduces us to the McKinsey concept of three different time horizons for a business portfolio strategy. The horizons describe ways a company can set itself up to escape “business as usual” and instead take advantage of, and plan for, present and future opportunities for success.

  • Horizon 1: Investments are expected to contribute to material returns in the same fiscal year in which they are brought to market, thereby generating today’s cash flow.
  • Horizon 2: Investments are expected to pay back significantly, but not in the year of their market launch. Typically, they are fast-growing from birth, but come off a small base and need time to reach a material size. Moreover, because market adoption is rarely linear, there are often fits and starts before they catch fire. In the meantime, however, they are making material demands on go-to-market resources in the current year without generating corresponding material returns, and so they demand patience.
  • Horizon 3: Investments here are made in future businesses that will pay off years beyond the current planning horizon. They are not expected to appear in-market during the current planning year, and while they make claims against R&D budgets, they do not affect the go-to-market operating plan.

Moore suggests that considering these horizons in the steering of your portfolio will enable you to “escape the pull of the past” and drive next-generation growth from new lines of business. I think this is key to being a successful Agile company with both a future-growth product strategy and people who remain proud and engaged.

(To get a good overview of Moore’s perspectives on these horizons and how Agile portfolio steering helps organizations achieve escape velocity, visit our website for the video on his talk from December 2011. To learn more about his perspectives on Agile organizations in general, check out the video of an interview Ryan Martens and I conducted with him last September.)

Inventing the future

A young startup working to put their company on the map lives in Horizon 3. Here, it’s all about learning: learning what the customer looks like and learning what product or service will inspire them to get their wallet out. This involves tremendous uncertainty. People who thrive in environments of uncertainty love to figure this out — knowing there are no obvious answers, and the questions to ask are pretty vague. My experience is that founders and early employees love the challenge and meaning of doing something no one else has done before.

Planning is still important here, but the plan itself isn’t the greatest value. There is something much more important going on. The company and the people are inventing the future, not predicting it. Deviation from the plan is expected. The only form of failure is not learning (or not acting on learning) and instead, sticking steadfastly to the plan. In fact, instead of revenue measurement, internal learning milestones are often a key success metric.

Growing, but not there yet

In Horizon 2, things are starting to work. A product is meeting a market need and has started to generate some revenue, but it hasn’t hit a tipping point yet. There’s still a lot of opportunity to learn, many ups and downs, and moments where it feels as though the company is taking steps backward in the market.

Those who thrive here have a different comfort zone: executing on what’s starting to work. Even though there is still uncertainty, patterns are beginning to emerge, and translating those patterns into repeatable execution plans to exploit what is working is key. Early employees are now surrounded with people who can appreciate uncertainty, but are more comfortable executing. Performance in Horizon 2 is typically measured by some combination of internal milestones, market indicators of tipping points and revenue.

Today’s cash flow

In Horizon 1, it becomes all about executing on the repeatable game plan that was developed in Horizons 2 and 3. The company has shown that by spending more, they can predict marginal increases in revenue. Success is now measured by typical performance metrics: planning and predicting future revenue and executing to results.

The company puts hundreds or thousands of people on money-making Horizon 1 initiatives, and the 30 to 60 people who were highly valued during Horizon 2 and 3 begin to feel lost. In an environment of certainty, those who are passionate about future growth (where learning and discovering is more important than exploiting a repeatable game plan), may only see monotony.

This is a dangerous place. When those who love uncertainty are asked to scale their execution, it can bring varying results – along with damage to their reputations. Many will lose their sense of value as execution and certainty dominate the company. They may feel compelled, for the future of the business, to inject uncertainty into a machine that has been optimized for execution. This is dangerous to Horizon 1 folks and for those around them. It’s no wonder why most of them leave or are asked to leave and return to much smaller, more uncertain environments.

Next-generation growth

Successful companies with products that are generating returns today face a common challenge: creating future successes. This entails investing in and nurturing next-generation products in high-growth markets. Why? Because the portfolio strategy required to sustain a growth company can’t be found only in current business. Here is a worst-case scenario: one day the business wakes up and realizes the game plan they’ve been executing isn’t working anymore. There are no future opportunities that are ready. Nothing has been incubating in Horizon 2 or 3, where it takes time for ideas to move through incubation. And, if the current market shifts and you have no options in Horizon 2 to generate tomorrow’s cash flow, you’re stuck.

A company can invest in its future and its people at the same time

In The Lean Startup, Eric Ries shares the necessary conditions to work on future initiatives within larger, more mature companies. (To get a good overview of Ries’ perspectives on helping entrepreneurs increase their chances of building successful businesses, visit our website for the video interview Ryan Martens and I conducted earlier this month). He argues for three main conditions:

  • Scarce but Secure Resources
  • Independent Development Authority
  • A Personal Stake in the Outcome

Just as important are the people assembled to work on future initiatives. Your star performers focused on current initiatives in established markets may not be wired for this work. They excel at predicting the future and delivering a portfolio plan that consistently meets or beats those projects.

Forward-looking work should be full of people who embrace and excel at uncertainty. Consider the original people who initially led the company through Horizon 3 and Horizon 2 the first time. These are great people to take off of Horizon 1 work. Invest their time and passions instead toward the speculative work of inventing the future of the company.

Improving your odds of success and survival despite uncertainty isn’t easy

Inventing the future isn’t easy and it isn’t without its casualties. Once you make the leap of putting the correct people on future work, then comes the task of improving the odds of their success and survival. Venture-backed startups have a failure rate somewhere between 50% and 90%, but large companies do have one advantage over startups: they have a significant foothold in an existing market.

With this advantage, large companies nonetheless suffer two big disadvantages:

  • Horizon 2 and 3 work will be expected to not disrupt any current activity. This can be a hard pill to swallow.
  • Horizon 2 and 3 work may be subjected to inappropriate measures of progress based on a skeptical Horizon 1 mindset. The skeptics may view new product development as an unmeasurable art and therefore far too risky as an investment.

Execution-oriented people need to see a disciplined approach to investment

Historically, Horizon 2 and Horizon 3 portfolio investments have been made with a very fragile agreement that goes something like this:

“Give us a chunk of money and an independent corner of the business to operate within and we will invent the future. Trust us.”

This isn’t fair to either side of the agreement. Without an alternative, execution-oriented people will naturally measure the progress in ways that make sense for Horizon 1. But those aren’t fair measures for Horizon 2 and 3. Without a disciplined approach and a specific set of measures appropriate for Horizon 2 and 3 progress, the execution side of the company will become the executioners. The portfolio investment in Horizon 2 and 3 will fail and the failure will place inappropriate blame: on the teams that were engaged in that work.

The Lean Startup process provides a way to show progress and build trust

First, The Lean Startup provides a disciplined way to manage the innovation process within the portfolio steering. Secondly, it describes the innovation process in a language Horizon 1 execution-oriented people can appreciate.

The Lean Startup process allows for a much healthier agreement across the Horizon 2 and 3 teams and the rest of the business. The conversation goes something like this:

“Give us secure resources, we don’t need much. And give us the authority to run the team following the Lean Startup process using Agile development techniques. In return,  we will constantly report on our progress using the metrics of Innovation Accounting. You can see our process and measure our progress. Through our continuous transparency, we will create trust in your investment in our part of the portfolio.”

The key is making sure the execution side of the company understands the process you’re following, because that is how they look at the world. They also need to value the new measures necessary to understand your progress. Even in extreme uncertainty you can be measured by your ability to incrementally learn what customers want and are willing to buy. That is the key shift. Disciplined learning is both the currency and the metrics of Horizon 2 and 3 initiatives in your portfolio, not cash in.

Before Eric’s book and the Lean Startup process, there wasn’t great language to describe this shift in thinking. Most successful early entrepreneurs naturally understand this. But often, these highly successful entrepreneurs couldn’t put it in language that Horizon 1 execution-oriented people within large companies could appreciate. That’s the brilliance of The Lean Startup – it works in early startups as well as within well-established companies.

Prepare your portfolio in a new way right now

The inertia of success can run over anything. You may find yourself having to prove your portfolio investment value every quarter. Your culture may shift from embracing uncertainty to embracing repeatable execution. This is the “pull of the past” articulated by Geoffrey Moore.

Now is the time to act

You need to ensure your future by creating teams focused on Horizon 2 and Horizon 3. You need to embrace this approach in your portfolio steering. And, this isn’t just a funding issue. Find a handful of your early employees and founders who may be trapped executing the known playbook. Bring them Eric Ries’s great work on The Lean Startup process. Get this independent team on the important business of freeing your company from the pull of its past. Give them a sandbox where they can innovate. Compel them with a personal stake in the outcome.

When you prepare to do this, you will give your company and these people the gift of meaningful work, while investing in your future.


Zach Nies is a CTO at Rally Software and a proud member of the Boulder/Denver Agile community for the last ten years.

Whenever I use John Deere as an example of a fantastic Agile adoption, I always get looks of surprise. That’s quickly followed by an ‘a-ha’ moment when I share that today’s

From my visit to the test farm in Des Moines - note all of the hardware on top of the tractors

tractors are run by more lines of code than the early space shuttles. Yesterday, ComputerWorld published a great article about John Deere’s Agile adoption, characterized as a ‘big bang’ across their 800-person development organization within a year. It’s definitely worth the 5 minute read.

By 2050, there will be 9 billion people on the Earth.

In 50 years, the world population will require 100% more food. Seventy percent of that food is expected to come from efficiency-improving technology. John Deere considers these their user stories, and they strive to use technology to help solve these global problems. If the ComputerWorld article is worth 5 minutes of your time, then Chad Holdorf’s in-depth talk is worth every bit of 25 minutes to hear John Deere’s bigger vision and how they inspire teams to tackle it at John Deere.

You can work with John Deere too.

I’ve been honored to work with Tony Thelen, director of John Deere’s Intelligent Solutions Group, and Chad Holdorf, their Agile Coach, throughout this transformation. And I share their passion for connecting engineers to solve these potentially disastrous problems. I’d like nothing more than to see some smart folks go to work for John Deere.

With my son in a John Deere plow.

Tractors and Agile? Absolutely. I can’t think of a better example of how software is shaping the world we live in – every single day. Congratulations Tony and Chad and best of luck on your social mission.

Ryan Martens is founder and CTO of Rally Software, a hopeful Citizen Engineer and a recovering Entrepreneur-in-Residence at the Unreasonable Institute. You can follow him on Twitter @RallyOn.

Are you an engineer? If so, our society needs you to apply yourself to the global warming and other global social problems for the remainder of your life.

Just before the Holidays, an article I wrote ran in Fast Company on the call-to-action I believe all engineers need to embrace. Read the article, “Engineers: Why Aren’t You Doing Work For Good?

Is this a calling that resonates with you? Do you think it’s feasible? If so, how can we get there? I would love to hear from you.

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.

Yesterday, we kicked off Rally’s Roadshow announcing the industry’s first Agile Portfolio Management solution. What an incredible opportunity to tell the Rally story, hear an inspiring presentation from Geoffrey Moore on how to escape the pull of the past, listen to the real-life story of aligning strategy and execution from Nina Schoen at Getty Images, and moderate a panel so lively that the panelists starting asking each other the questions.

Catch the Next Agile Portfolio Management Roadshow

Panelists Geoffrey Moore, Nina Schoen, Todd Olson, Dave West, Ronica Roth

The best way to learn more about this new solution is to tune in to our Agile Portfolio Management roadshow. Although we kicked it off this morning in the Bay Area, you can still catch Dec 8 in Boston (with Dave West from Forrester Research, Chris Haley from The CBORD Group, and Rallyers Todd Olson, Ann Konkler, Rick Simmons and others) and Dec 13 in Dallas (with author Dean Leffingwell, Chad Holdorf from John Deere, and Rallyers Todd Olson, Isaac Montgomery, Julie Chickering and others). If you can’t attend in-person, sign up for the virtual event where we webcast nearly the entire event from keynote to panel presentation, and incorporate online questions.

Self-Serve Materials to Learn More

Below are a few additional materials if you’re the self-serve type. The recorded webcast and slides of the above roadshows will be posted soon as well.

Next stop of the roadshow is Dec 8 in Boston, MA. We hope to see you there!

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.

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 6th 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:

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 2nd.  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.

Next Page »