Agile Development Blog

Ooooh! It’s Friday and time for another celebration of a one hit wonder. And though it is April Fool’s Day, this is no joke. Today I am thinking about how we have to continually hone our craft in our technology world. Sometimes, I feel as though I am in a never ending PhD program. Or, I keep moving from one apprenticeship to another. It can be overwhelming. And yet, I love my work. I love feeling growth and challenge in how we continuously improve the software industry.

I started in this technical world 30 years ago, programming JCL on punch cards. It was that or paper tape. (I am NOT making this up!) I moved on to PL/1, Fortran, C, and a couple of assembly languages along the way. I then made the dramatic move from procedural languages to object-oriented languages.

And there were other areas in which the world of technology invited my growth through challenge and reward. I slowly moved away from a very documentation-driven view of the world. (Well, I could call it “graduated from” but I don’t want to be too provocative on a “One Hit Wonder Friday!”) And there was a time when my sense of significance was deeply wrapped up in my prowess in Microsoft Project, in 5-level work breakdown structures, and in pages of perfectly aligned Gantt charts based on my skills with Finish-Start dependencies. Whoa! Just had a trip down memory lane! It’s a heart-breaking story. And it is worth telling. Because, now I am in an Agile world.

Today, I am pausing and reflecting on how I have had to continually be prepared to re-tool my thinking and my tools. It hasn’t always been easy. And, it has ALWAYS been rewarding. Moving to the world of Agile and continuously working on my grasp of lean thinking, systems thinking, complexity theory and knowledgement management has all been a challenge. The rewards, however, are priceless.

And now our one hit wonder of the day. This week I am thinking about an artist not from the music industry. His work was limited to the big (and little) screen. He was brilliant in his craft at the time of his fame. In fact, I would say he was singular, outstanding, ground-breaking. He won the hearts of millions. And yet, he fell into obsolescense to the point of later appearing in television shows and movies more as a perfect caricature of himself. Why? He didn’t keep up with technology. He remained in a world in which his craft lost its value. As good as he was, he was left behind. He is a poignant reminder that we must always invite growth and change even when we may feel lost or that it is all just too much. Our artist for today gave selflessly to others when all odds were against them.

Yes, today we are celebrating “Robbie the Robot” from the the 1956 movie “Forbidden Planet”. The spelling of his name (Robby/Robbie) seems to be somewhat of a mystery just as Robbie’s dedication to his performance was mystical. Though he appeared in a variety of movies and TV shows after “Forbidden Plant” (including “Lost in Space” no less), these were only as brief cameos, as sad reminders of glory days long past.

I met Robbie several weeks ago in the Intel Museum in Hillsboro, Oregon. I was at the Intel Agile Conference there when Scott Hanselman of Microsoft asked to interview me for channel9.msdn.com. Where better to hold the interview than in the museum just across the way from the conference? And there he was, Robbie the Robot. Wow. Me meeting Robbie the Robot. Robbie still holds up his head with pride despite being relegated to museum status. He still holds out his large rounded, clumsy digits ever ready to offer assistance despite his inability to do so. I salute Robbie for all he has given us.

Jean Tabaka is a crash skier, college hoops shredologist, author and Agile Fellow at Rally Software Development. You can follow Jean on Twitter at @jeantabaka

With the help of a large and passionate community, Dean Leffingwell and I feel confident in answering yes to the question we posed last December, “Is Agile the key to building high assurance software?” Based on the feedback we’ve received in Dean’s Scaling Software Agility Blog and the large number of medical device companies already successfully utilizing Agile practices, it’s clear that Agile is vital to bringing highly innovative and high assurance products to market before your competitors. Here are a some of the comments we’ve received from practitioners.

“I think this is quite interesting, and quite possibly could revolutionize the way medical device software is delivered.  Life sciences is the last bastion of waterfall development methodology. I look forward to championing the cause!” - Bernie Barbour

“Having been in FDA regulated development environments for over 10 years, this truly is an area where most people live & breath waterfall. But as you said, there are a few out there already doing agile in this domain and I would argue that it can be done (relatively) easy.” – Michael Meissner

The community really stepped up to help us pave the way for developing the first guidance truly focused on the details of implementing Agile in High Assurance Environments using Medical Devices as are exemplar (see topics like: Software V&V: Verification Testing Features and The Validation Sprint Explained). Having presented the meat of the process in our first series, we are excited to move forward on a second blog series, Agile Tooling for High Assurance Software Development.

In this series, Dean and I will provide examples of tools that many of us have in our own environment, such as Rally, Quality Center, and SVN, and show how these products can be used to support the compliance documentation that is commonly produced for audits in regulated environments. We will provide the community with best practices for using Rally as well as a best of breed solution that integrates Rally to other products.

The series will include posts like…

1) Use Rally to track and report on the basics – Define | Verify | Build
2) Achieve tight traceability and reporting from Product Requirements to System Requirement to Verification & Validation
3) Don’t overlook the implementation of the Validation Sprint
4) Testing and test traceability in High Assurance Environments

In conjunction with this series, Rally will release new applications like an improved traceability matrix and a SRS report that Rally customers will be able to take advantage of. In addition, we encourage you to share your suggestions for reporting that would help to automate the compliance process for your Agile team. If you are a Rally user, please enter your ideas at Rally Ideas and tag it as “compliance.” Or, feel free to send me an email at craig@rallydev.com.

If this topic interests you please leave us a comment below, on Dean’s Blog, or send me an email.

(Note: today’s blog post is brought to you by the letter “N”)

Continuing our series on N Levels of Planning, I realize that even the usage of “N” in our definition of planning levels has been perplexing me. Sometimes, I think I get what N means. Imagine N = 5. In this context, you might do higher level planning for your product teams. Create a great product vision. Build a thematic product roadmap. Have these faithfully inform release planning, iteration planning and ultimately daily planning. Okay great. Here, N = 5.  And then I think, “But what about when I move to more continuous flow of value delivery through Agile? Now what is my “N”? I move away from iteration timeboxes for delivery, so no plan there, right? Do I still think about some sense of planning at a product vision level and a product roadmap level? Do I still have some sort product release planning but it just differs in approach in continuous delivery versus timebox delivery? Perhaps I now have N = 2; or, is it 3 or 4? And, perhaps “planning” has a different meaning as well.

We’re not done with the ambiguity yet

The N levels of planning complexity doesn’t stop at the product planning level. Think about now inviting levels of business planning as a natural part of Agile transformation and maturity. If I add in a Strategic Business plan accompanied by a Business Roadmap plan, I’ve now moved to N = 7. Or not if I am not using timebox-driven planning. What if the business uses a milestone-driven approach? For example, we know we have this conference coming up; we want a release for that date. We’ll still use a prioritized backlog for our work and we’ll declare our release based on what functionality is available by the milestone. What is “N” now?

But wait! There’s more!

You’ve brought the business into your Agile transformation. As you do so, are you transforming business with your IT organization? Or, is your Agile transformation in the context of product lines in an ISV?  Your business context may impact what and how you plan. In both contexts, you are running Strategic Business planning and Product Roadmap planning in your N-levels of planning. But what do these plans produce and how do you use them? Here, “N” now may rely on your business context. In the emerging business initiatives, have we uncovered capabilities that spread across portfolios or maybe across products? Are there initiatives that extend beyond business unit boundaries? Does this boundary-crossing work create capability-driven versus product-driven teams? Now, what are our N-levels of Planning?

I wonder if I am going to end up with some sort of quadratic equation to resolve “N”

As we continue to delve into a guide for “N-levels of Planning” in Agile organizations, I believe we are discovering the “N” is driven by the variety of taxonomies that lie in our contexts. Criss-crossing these contexts and their taxonomies, there seems to be some potential skeletal guide for “N”. At the least, consider 4 basic realms in which “N” derives definition:

1. Your level of Agile Adoption into the enterprise (product line only, one business unit, or multiple business units)
2. Your business’s technical organizational and architectural structures (e.g. ISV versus IT)
3. Your thematic (requirements) structures (themes, epics, capabilities, MMFs, stories)
4. Your delivery structures (timeboxes, milestones, or continuous flow)

“N” is a complex variable in N levels of planning. I no longer believe there is one magic formula for “N”. I know for sure “N” does not forever equal 5, something I had been so sure of at one time. I will say, I don’t think “N” is an imaginary number :-) I believe “N” reveals itself as we apply intention around the four structures above for our Agile transformations and maturity. And, your mileage may vary.

More to come on our old friend “N”. But first, what’s your “N”?

Jean Tabaka is a “why bother” latte sipper, crash skier, college hoops fan, author and Agile Fellow at Rally Software Development. You can follow Jean on Twitter at @jeantabaka

Time for another installation in our “One Hit Wonder Friday” series! Today, I am thinking about work I’ve been doing in the many layers we apply in Agile planning. I’ve been trying to bring some of that to light in our “N-Levels of Planning” series. Working with my colleague Greg Frazer, some thoughts about what we mean by levels and planning have emerged.

Agile planning isn’t just one way

Greg and I have this notion that in truly Agile contexts, planning occurs not just top down (from the organization’s vision to the team’s committed velocity) and not just bottom up (from the team commitments and velocity to the product release). We also have a sense that plans at one level inform its immediate neighbors up and down as well as side to side. Think of a portfolio situation where the plans for different initiatives impact the plans of others. Each plan level and each parallel plan is informed by its neighbors. That makes the plan more organically useful over time. But, to be clear, this does not suggest high dependency of plans; any given plan also has a sense of autonomy. It holds itself and takes in information and radiates information as is useful to its overall commitment. That commitment, it turns out, is tremendously valuable to the “n-levels” around it.

Agile planning isn’t just planning

Greg and I are working with a group here at Rally called the “N-Level Rock.” Our small but mighty team investigates not only what we’ve seen change in the world of Agile planning; we bring in what seems to have persistence.  In particular, our rock team is inviting a big sense of planning. It stretches beyond the team, beyond a product line and into the real business of the organization. It’s a big world! And, it is NOT just about planning in that big world. It’s about steering in that big world. That is, bring trust and check and guidance into your planning world.

Agile planning is big and small

Back to N-levels. Yes, there is a sense of hierarchy in this nomenclature. More importantly, think about a symmetry of attributes around very large horizons into release horizons, iteration horizons and then daily horizons. In a continuous flow environment, you still have a long term horizon; it simply is informed by continuous flow of value evaluated and updated in each daily plan. When we embrace up and down Agile planning, planning as steering, and planning as both big and small, we avoid the pitfalls of traditional planning, We avoid that feeling of, “Another promise fallen through, another season passes by you.”

And now to our “One Hit Wonder Friday!”

Well, I’ve laid in a few clues about our band this Friday. (Thanks again to Wikipedia for feeding my one hit wonder trivia passion.) A small band singing their heart out about big things. BTW, my colleague Greg in the picture above is from Canada, roughly 3,850,000 square miles in size. THAT is a big country! But I digress. Back to our one hit wonder. While they were a fairly successful band in the UK, they managed to muster only one hit on the US charts. Our small but mighty band from Dunfermline, Fife, Scotland took a stance in 1983 about what it means to live with big dreams and yet hold them close, to not let them be shattered or to be expected to grow flowers in the desert. Tony, Bruce, Stuart and Mark are still active today with something of a cult following. But some of us will never think of them in any other way as “Big Country”: a small group from the great country of Scotland (square miles: roughly 30,400) who believed in greatness on many levels. With that said, today I offer you “In a Big Country.”

Jean Tabaka is a crash skier, college hoops fan, author and Agile Fellow at Rally Software Development. You can follow Jean on Twitter at @jeantabaka

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

Where are you in your Agile adoption? Are you celebrating your Agile successes?  Have Agile practices and discipline helped you address challenges with quality, delivery, and customer satisfaction? Are your Agile teams–and even multi-team programs–delivering high-quality, valuable features reliably?  Do both your team and program leadership effectively promote learning and value-delivery?

Our new Rally service offering

If so, congratulations!  You are now ready for the next step in your Agile transformation: Agile planning at a more strategic level.  We call this Agile Strategic Planning. Rally now offers this new service wherein we partner with you in this next step in your transformation. Let us help you bring Agile thinking to your portfolio roadmapping and other strategic planning cycles through this new Agile Strategic Planning service.

In Agile Strategic Planning, we align development work to the business’s goals, outcomes and strategies. We still support detailed decision-making at the team level, the people closest to the work. And we continue to explicitly help teams start learning sooner. However, in Agile Strategic Planning, we do this by establishing business cooperation and a cadence of feedback loops at a higher level that enable you to help and steer strategically as needed. The result over time is that work remains aligned to key strategic goals and remains focused on value.

Agile Strategic Planning has different challenges and different disciplines

While you may be ready for this strategic next step in your Agile transformation, your challenges are not over. You’ll know you are faltering if you experience the following:

• Long executive planning cycles drive big up-front planning
• Executive commitments do not benefit from course corrections during the year
• Portfolio Management or Product Management is still driving to plans with both date and scope fixed
• Other departments–like Marketing, Ops, Release Management –struggle to align their activities to the rapid deliveries of development
• The annual resourcing cycles that drive up-front planning also reduce agility in execution

Good Agile Strategic Planning embraces Agile thinking and discipline practices such as:

• Rolling-wave planning, in which we recognize that we have more confidence in the short-term and less confidence in the long-term
• Improving focus and throughput by limiting work-in-progress, funding fewer initiatives in a cycle, and potentially making initiatives smaller to reduce risk
• Establishing new feedback loops, such as higher-level regular inspect-and-adapt cycles and new information radiators
• Placing an emphasis on defining outcomes, rather than outputs, and on clearly defining value propositions and clear costs of delay for initiatives

Our Rally service starts with your context not prescription

Agile practices at this strategic level are far less prescriptive than at the team level.  As a result, we apply strategic principles to your specific context that then guide the practices that can achieve your strategic planning goals. Rally’s Agile Strategic Planning service starts with a Rally Agile Coach or Coaches spending time understanding your context: the current state of your Agile development practices and organization; your current strategic planning cycles; what challenges you’re experiencing; and, what goals you seek to attain by moving to Agile Strategic Planning.

Building from this initial assessment, Rally coaches facilitate your leadership team in applying Agile techniques to what becomes your Strategic Roadmap. We emphasize deciding on the right investments across the portfolio at the business level to get the right value from your development organization.

Next, Rally coaches work with you to define fundamental feedback loops that guide how you refine your Strategic Roadmap. Jointly, we help you develop a cadence for what we refer to as a “rolling roadmap” that continually sets a responsive and value-based strategy.

Our request: Be our co-creator

Rally is excited to bring this service to our customers.  Be one of our forefront customers, our partner, who helps us fill in more detail about this service while improving your own strategic planning.  We have built this Agile Strategic Planning service from our past experience working with enterprise Agile customers.  And now, we’re ready to put the pieces together into this single service.  Here is our invitation: help us create a great, whole offering that successfully brings Agile to the Enterprise level.

Our offer: Receive a special Rally partnership

Rally is eager to partner with early customers on this service. We are prepared to invest more with these first customers who help us help them.  As a result of your readiness to partner and co-create, you can expect more time, effort and Rally coaches for your money. Be our partner as we take Agile to the Strategic Planning level in your organization. Work with Rally and be prepared to celebrate your Agile success at a whole new level.

Ronica Roth is Rally’s Solutions Evangelist, an Agile Coach, a CST, a skier, and a Steelers fan.

(Creative Commons D. Sharon Pruitt)

On this last Friday of 2010, I thought I’d try to get a quick “One Hit Wonder” in before the horns toot and the bubbles flow. And maybe these New Year traditions are apt images for my topic today. I’ve been thinking about what we do for the New Year and what we do for Agile. We like to scoop up information to help us figure out what we can best do next. On New Year’s Eve we sometimes call that “resolutions” for the next year. Ugh. Not my style. Rather, I’d like to think about intentions. So bear with me as I reveal my style of  “inspect and adapt” for my personal New Year:

Accentuating what is positive and whole is best

Years ago, a friend of mine had told me about how she prefers to reflect on the last year. She has a way she moves into the New Year, answer three questions:

1. What will I let go of that has drained me or perhaps has caused me to feel guilt or shame?
2. What will I choose to continue to do, those things that energize and delight me?
3. What new things am I prepared to invite into my life to help me to continue to let go and grow?

I like this metaphor for Agile teams as they retrospect from iteration to iteration, or from release to release, or even year to year. I like paying attention to the positive.

1. What has not worked for us, caused us angst or distress whether in our process or our technology, that we are prepared to let go of?
2. What do we choose to continue to embrace about our work as we move forward?
3. And, what new practices or agreements are we prepared to invite into our team or with our stakeholders that will help us to continue to grow and improve?

Start simply: where you are

So for me, I start today, here, now. I could think about how I have seen my life from day to day. I can watch how my life has unfurled from week to week or month to month. Using appreciative inquiry, I can take what has brought me the greatest delight and pride and then look at what was happening when that occurred. And then I can choose to replicate those circumstances, sort of like what our guest blogger Lee Devin refers to as “Planning to Get Lucky”.

For Agile teams, we can apply this philosophy each time we demo functionality to our customer, whether at timebox intervals or as each new function or minimally marketable feature is completed. We’ve learned. These demos, often on a Friday afternoon, lead us to inspect and adapt. These demos also feed the team and the customer. We all learn. AND, we do this through the pride of completing working functionality.

I believe in the humanity and delight of this form of retrospection. Do you see why I shirk New Year’s resolutions? Instead, I look for the accomplishments that have helped me grow and move forward. Agile teams, through their demos and reviews invite the same.

And now for our one hit wonder!

I am thinking of a song that accentuates the positive, invites us to let go of what may be drudgery and to plan instead to get lucky. Oh the metaphors!

Thanks in advance to Wikipedia for helping me fill in the tale of our one hit wonder. The band (yes, not a solo act this time) started with a husband-wife team who then added another male/female contingent. The album that held their #1 hit song actually did quite well on the charts. And this was 1976 when you could buy songs as single 45 records (no, single MP3s were not yet available ; -).  The band received two Grammy Awards that year, “Best Arrangement (voices)” and “Best New Artist”. And yet two subsequent album outings not only produced no new hits; the husband and wife team were soon divorced. Oh the tragedy of it all after such success from a song that you can still hum today.

So what is our One Hit Wonder this last Friday of 2010? We’ve got Starland Vocal Band and their great tune with which to say, “Happy New Year, dear readers!”

Jean Tabaka is a snow shoveler, crash skier, author and Agile Fellow at Rally Software Development. You can follow Jean on Twitter at @jeantabaka

Question: what do Neil Young, Simon Sinek, Don Reinertsen, and Jean Tabaka have in common? We all want to know why.

Several weeks ago, we introduced a new blog series “N Levels of Planning”. Our goal in this series is to investigate how Agile planning can benefit from thinking of planning as a number of levels, or layers, or paths. In this series post, I’d like us to take a conceptual step back from what we mean by “N”. I’d like to instead think about the “Why” of Agile planning regardless of the number of levels.

The Neil Young Connection

Warning: minor non sequitur. In 1970, Neil Young released his “After the Gold Rush” album featuring as its first track the great tune “Tell Me Why”.

Love that song! I had this song buzzing through my head after a discussion with colleagues about “Why.” Lyrics like: “Still the searcher must ride the dark horse, racing alone in his fright,” and, “Tell me lies later.” What can it mean?! What is there that is so important about starting with “Why,” and to ask it repeatedly? What did the Neil Young of yore get about the searcher, the dark horse, and the race that I needed to revisit now? And what does it have to do with Agile planning?

The Reinertsen Principles

I had some suspicions after reading Don Reinertsen’s “The Principles of Product Development Flow” that the “Why” is indeed what should be driving our Agile product development. In his book, Reinertsen exhorts us to inform our decisions about product development by starting with value flow. You may call this stating the glaringly obvious. For me who had been handily sticking to the “How” and “What” in my computer science expertise for decades, this tumbled several of my false idols. Ugh.

Simon Sinek’s Golden Circle

Recently, several colleagues here at Rally pointed me to a great TED talk: Simon Sinek’s “The Golden Circle”. If you haven’t watched it, take a gander. Sinek’s very simple model consists of 3 concentric circles, the innermost being “Why”, the outermost being “What” (See the picture above of the turquoise post-it.). Sinek defines successful businesses as those that start, not with “What” or “How”; they start with the core “Why”. This articulation of the “Why” rallies the business around one compelling vision and creates a vital emotional connection with its customers. “How” the company delivers on the “Why” follows from and is directed by the “Why”. Then and only then does the business move out the circle to the “What”. What exactly will our product be? Well, we know why we are building it, and we know how to deliver on this. Now it is time to build it!

We missed the “Why” boat in our initial Agile scaling advice

I was thinking about Sinek’s Golden Circle with regard to how we plan in Agile teams and Agile organizations. Too often, we have a tendency to start with  “What” as the core for our planning. If we are really maverick, we may start with “How”. Too often, I fear that our planning “Why” is conspicuous by its absence. I am fairly certain Ryan Martens and I fell into this “What” trap when we defined 5 steps for Agile scaling and maturing using Flow, Pull, and Innovate. Why were we defining how to scale and mature should have been the first question? And then How shall we do that? Okay, we did get the How: we turned to Lean Thinking principles about Flow, Pull, and Perfect (which we renamed Innovate) for guidance. And then we quickly jumped to What the practices are: 5 steps of what to do, what roadblocks to expect, what benefits to reap.

Agile planning levels need to start with “Why”

This is what I now believe to be true. Just as businesses must be driven by the “Why”, I believe we must consider the “Why” that drives any of our Agile planning. My hope is that we in the Agile product development world would come up with a fairly common answer for “Why”: smooth flow of value delivery. Period. Our “How” can be informed by the set of principles we believe would best address our “Why”. We can turn to Lean Principles as a great guide. Here, I’ll admit I favor Reinertsen’s principles of product development flow as the canon for “How”. We’ve got the “Why” and the “How” for our planning. Now we can declare our “What”: what will be our planning practices in our Agile organizations?

How Jean Tabaka fits in

With “Why”, “How” and “What” as our planning guide, there is one more beautiful gift of symmetry across Neil Young, Don Reinertsen, and Simon Sinek. Not only does this virtuous Golden Circle guide overall planning. I believe that within each of the “N levels of planning”, we can see that there is a “Why”, “How”, and “What”. Here is an example: “Why should we have a daily level of planning?” “How should we guide that planning, i.e. how would we know we were doing a good job of planning at this level?” And now, “What will our practices be around daily planning?” As we regard levels of planning as not just sufficient but necessary, we turn back to the “Why”, find guidance from the “How”, and then create the useful “What” practices.

Back to Neil Young’s “Tell Me Why”. I think we can avoid “riding the dark horse racing alone in fright” if we start our planning with a compelling “Why.” And, with thoughtful  “Why”, “How” and “What” levels of Agile Planning, I believe that we can avoid the “lies later” as well.

This is what I believe. What do you believe?

Jean Tabaka is a crash skier, sometime poet, author and Agile Fellow at Rally Software Development. You can follow Jean on Twitter at @jeantabaka

As a part of our series on Scaling Agile to the Strategic Level, I have invited our product lead on this project, Catherine Connor, to tell us about her experience in creating Project Stratus. Thank you for the great work and help on this series Catherine.

Project Stratus was conceived over a year ago from numerous customer discovery interviews geared at understanding the challenges of strategic planning with agile execution. From these interviews we started to form an idea of what an agile strategic planning tool could look like, but we also knew that we would need to do serious customer validation before getting to productize a solution.

We’d already selected a disciplined approach to customer validation based on The Four Steps to the Epiphany – Successful Strategies for Products that Win by Steven Blank. Although the book focuses on startups, many of the ideas, such as diligently conducting customer validation and creating a sales roadmap (i.e. a repeatable process to sell your product) can also be applied to new products in existing compagnies. The basic premise of Blank’s approach is that if you solve a problem for customers (called “earlyvangelists”) who are so acutely affected by that problem that they are willing to build a solution themselves, you are more likely to deliver a product that will solve that same problem for many more customers.

Four Steps to the Epiphany © Steven G. Blank

Project Stratus was drastically accelerated in April 2010 at the LeanSSC conference in Atlanta, when one of our customers unveiled the agile product portfolio scheduler application they’d built to solve their own strategic planning needs. Not only did the application visualize where we were heading, it also happened to be built on the Rally Platform. We’d just found our first earlyvangelist.

Four months later, at Agile2010, we privately introduced Project Stratus to a handful of industry analysts and customers to gauge their reaction. Based on their overwhelming excitement, we proceeded in identifying additional earlyvangelists from past customer interactions. An earlyvangelist is like a P1 defect, when you find one, you know right away. These customers are so excited to see a provider like Rally think up a commercially supported solution to the problem they have been trying to solve themselves, they are anxious to guide you, and some are even irritated by the fact that the product is not out yet; when all along we’ve been thinking not to deliver such a thing! I could tell when I first engaged with Paul, Dale, Nina, Christophe and others, that they would be partners in shaping Project Stratus to become a valuable product. The beauty of Blank’s technique is in its reciprocity. We, the solution provider, get to build a product that solves real needs, earlyvangelists get to shape a supported solution to replace their manual solution, and customers get to benefit from their peers’ expertise.

With earlyvangelists on hand, we sat down to define the set of hypotheses to validate. This is an important step to ensure that interviews provide meaningful outcomes. Nothing is more deflating than spending an hour with a customer only to find yourself with no good answer to “exactly what did I learn from this call?” Listing hypotheses is also a great way to communicate to yourself and others in your company what you are trying to find out and what you are purposefully setting aside for another time. This is very much like “theory-based decision making”, one of Rally’s corporate core values.

Since August, we have been incrementally evolving Stratus, one weekly build at a time, diligently validating our hypotheses one at a time.  Earlyvangelists’ real-life experiences combined with our coaches yearning to apply agile and lean principles to the strategic level are informing the direction of Stratus. I feel really good about where Stratus is going.

As an agile product manager who has seen several projects being productized prematurely, I am truly enjoying following Blank’s rigorous Customer Development approach and definitely would recommend it to my product manager comrades. You do need executive support which thankfully Rally provides me. Following Blank’s technique is no small feat however, it is hard and diligent work with no guaranteed productization plans until you pass his customer validation final exam: “you have proven you have understood customer problems, found a set of earlyvangelists and delivered a product that customers want to buy, developed a repeatable and scalable sales process and demonstrated you have a profitable business model.”  Then, and only then, will we graduate to Blank’s customer creation step, aka the delivery of an official Rally offering for Strategic Planning.

The customer validation step for Project Stratus is going full steam. We welcome more earlyvangelists to partner with us in this exciting endeavor. The more input we receive, the more valuable the product will be. If you have strategic planning challenges and a passion for applying agile principles for solving them, I invite you to reach out to us at stratus@rallydev.com. – Catherine Connor

The work done by Steve Blank on this method is fantastic. In addition to Project Stratus, I have used it with our large on-premise customers and with TechStars companies in order to keep from leaping to conclusions and trying to by-pass the customer creation stage. I hope many of you can empathize with the discipline required to do both of these things in the world of product development.

Ryan Martens is an Epic Pass holder for 2010, a school board member at Friends’ School Boulder and CTO at Rally Software Development.

Catherine Connor is a Product Manager at Rally Software Development. She focuses on the product manager role in our customers’ agile transformation endeavors.

In “The Design of Business“, Roger Martin talks about businesses that find an algorithm and just stick with it. They exploit it and never really dare to explore new ideas or ways of doing things. Sort of like a one hit wonder. You just live off the royalties of that one great idea.

What’s a one hit wonder?

My colleague Mark Gammon and I were talking about Martin’s book and this phenomenon and decided it was time for a “One Hit Wonder Friday”. A one hit wonder is an artist, singer, or group who has made a hit, a really big hit, and yet has not been able to do anything else that really grabbed the public’s attention. Given that the one hit wonder Martin describes in his book is one I’ve loved for a while, we decided to kick-off our Friday series with his example. Here’s who we have in mind: someone who has a song pretty well known even though it is quite old. And yet, the artist (okay, that’s a hint, it is one person) never explored or expanded. It turns out he (okay, it’s a male), has been doing okay living off his royalties. But before we reveal further clues about our artist, first back to business.

Are you living off the royalties of your business “one hit wonder”?

Businesses can end up being one hit wonders too. They find that one “song,” that one big idea, or that one good process and believe they have to stick with it in order to be successful. This is the stuff of bureaucracies. The sad fate of business one hit wonders is that they just aren’t built to last. The idea either dies out or is bought out. One thing for sure, with business one hit wonders there is no room for chance or growth; that is too dangerous.

For your business to avoid the doom of a one hit wonder, you’ll have to challenge yourself continuously in process improvement, in product visioning, and in knowledge sharing. You will have to invite the discomfort of exploration and the unknown. Accepting and embracing the ambiguity of whether you will be a hit or not is not easy. But, as in the Agile world, with frequent feedback and delivery in small batches, you can make quick adjustments through heuristics that set you on  your next big hit.

Back to our “One Hit Wonder Friday!”

Here are a few facts about this week’s one hit wonder (thank you Wikipedia):

He’s a Massachusetts boy, born in the 1940′s. He studied music at Boston University (ah, that paid off :-) Using some of the proceeds from his one hit, he landed a farm outside of Petaluma, CA. So all is not bad for our one hit wonder!  The song itself is remarkably recognizable given that it came out back in 1969-1970 and sold over 2 million copies during that time. (Again, what an algorithm to stick with!) To our one hit wonder’s delight, it has been re-made a number of times, including by the great all girl punk band Fuzzbox (Hint: yes, there is a connection between the term fuzzbox and our song.) This is really good stuff :-)

The song itself had a combination of a sort of spiritual and hippie feel using heavy guitars and hand-clapping. Our artist wrote the song in 15 minutes as his own version of what he thought a gospel song could be. And finally, Rolling Stone rates the song #333 in its top 500 songs of all time.

So who is our one hit wonder this week?

Jean Tabaka is a crash skier, author and Agile Fellow at Rally Software Development. You can follow Jean on Twitter at @jeantabaka