Agile Development Blog

In summer, the Entrepreneurial Thought Leaders series at Stanford released their video podcast with Geoffrey Moore on his new book “Escape Velocity” As soon as we saw it, I contacted Geoffrey to see if I could get an early copy of the book. Geoffrey was very happy to share and subsequently talk to me about how Rally could help promote this great new book and web site, Escape Velocity, which launches today.

I highly recommend the book, buy it today, and see the video. As you can see from my collections of his books, I love his work. His command of English and simple models always makes reading his books a real pleasure. I got “Crossing the Chasm,” when I was in school as an engineer back in the 1980′s.  I enjoyed working with him and The Chasm Group back in 2000 while I was at BEA. But, now this newest book has hit while Rally is working with customers that struggle with escaping the “pull” of the past. As Geoffrey describes, this is “A better vocabulary to talk about power versus performance.” I see many customers describing why they invest in Rally – to transform their execution and offer power.

As a result, this book is not just interesting for product management, but for the executives in engineering, marketing and sales, as well as the whole executive team. Because my team was so excited about this book, we were able to get our marketing team excited too. I am thrilled to announce that Zach and I will be interview Geoffrey live on September 22nd. Please consider joining us for this webinar.

Now to helping us make this interview work for you. Zach and I are going to run this interview based on our understanding of this book and our experiences, but we are also very interested in your questions. We will support chat and Twitter during the webinar, but your comments on this post would be even more appreciated. Here are some of the our draft questions:

• Most Agile development teams have fixed the execution power level – what is next and why?
• I have read all your books – can you reflect on this book in relationship to past works? Is the really the capstone?
• For a recent graduated from college, what order would you have him read your books?
• Do you assume engineering needs to be Agile to pull off this approach?
• You mention it’s important to separate differentiation, neutralization and optimization efforts, why?

What is top of mind on this topic for 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.

Zach Nies is the co-CTO at Rally Software and passionate about building successful software products and a proud member of the Boulder/Denver Agile community for the last ten years. You can follow him on Twitter @ZachNies.

Along with our Project Stratus initiative (see our Scaling Agile to the Strategic Level blog series), Rally Idea Manager is a big piece of Rally’s goal to extend agility outside of development and into the enterprise.

Traditional ways in which product management collects user input – customer visits, enhancement request forms, homegrown systems, and commercial product management tools – tend to fall apart as development goes Agile.  Agile teams are hungry for user input as their frequent delivery schedule calls for fast feedback loops to continuously influence development.  Agile teams know it’s important to build things right, but making sure they build the right things requires product managers to engage quickly with customers around the world.

Product managers have another challenge in our competitive world — they can’t just take feature requests at face value. True product innovation comes from understanding the WHY behind feature requests. Rally Idea Manager is a social site specifically designed for actively engaging users in frequent conversations and getting to the WHY.

Rally Idea Manager was released a year ago to help product managers effectively prioritize their product backlogs by increasing the understanding of users’ needs. Powered by our partner Brightidea, the leader in ideation and innovation systems, Rally Idea Manager is honed for product marketers and product managers working with Agile teams.

That launch was a result of Rally’s own Agile product management experience. When I started at Rally in the summer 2007, we had just launched Agile Commons with a “Feature Requests” hive to discuss product ideas. Three years later (last October) we adopted Rally Idea Manager, and branded our site “Rally Ideas.” With Rally Ideas, we have been learning how to effectively leverage a user community to drive innovation in our products and to account for user input into our brutal prioritization process.

This month, to celebrate the first anniversary of the Rally Idea Manager launch, we released a bunch of added value for product managers to keep their user community vibrant, including things like:

• A user reputation system and leaderboard: to monitor and incentivize user participation in the community
• Customizable idea tabs: for users to easily locate their favorite ideas and for product managers to highlight special features in this week’s discussions
• Improved search: to minimize the creation of duplicate ideas
• Rally integration enhancements: to link new ideas to existing Rally stories and update idea statuses based on any Rally story states
• Better idea status change notifications: to keep users informed of specific status changes
• A “idea interest report by company” report: to better understand the specific needs of a given customer

The below demo highlights some of the new additions. To learn more, read the Product Blog from Rally’s site owner, who is blazing new trails with our own deployment of Rally Idea Manager (Rally Ideas), so we can improve the offering for you to engage with your own end-users.

And because launching a user community site is new to many organizations, we decided to consolidate our 4 years (and counting) of learning into a 2-day workshop where you can learn how to set up your very own Rally Idea Manager site. The workshop covers how to setup your site (frankly, that’s the easy part), how to market your site, who to involve in your organization and how to keep your site vibrant so user input keeps flowing into product backlogs. Interested? Contact rim@rallydev.com for more information.

Catherine Connor is a Product Marketing Director and product owner for Rally Idea Manager. She loves Colorado summers (which finally arrived this year), for all the camping, hiking, biking and sailing opportunities!

In last week’s blog “Rationale for Project Stratus”, Ryan stated “The model articulated in Dean Leffingwell’s newest book, ”Agile Software Requirements: Lean Requirements, Practices for Teams, Programs and the Enterprise“ is clearly one of the patterns of agile strategic planning.”

In this post, I want to expand on how we reached that conclusion.

I’ll start by introducing Chad Holdorf, Agile Coach and earlyvangelist for Project Stratus. Chad has been guiding Project Stratus in support of Dean’s model. Take a look at what you get with such customer collaboration: http://www.scaledagiledelivery.com/2011/04/22/agile-portfolio-planning/

Now on to how we got there:

As mentioned in the “The Making of Project Stratus” blog, we have been diligently following a customer development process based on Steven Blank’s model. Because the book focuses on startups, we adapted the model to existing companies (like Rally) wanting to deliver new solutions to their market, but one aspect that applies to both is a ruthless search for a handful (3 to 5) of what Blank calls “earlyvangelists”.

Earlyvangelists are customers that have these particular characteristics:

1. Has a problem
2. Is aware of having a problem
3. Has been actively looking for a solution
4. Has put together a solution of piece parts
5. Has or can acquire a budget

#4 and #5 are of key importance: Earlyvangelists have more than just the problem. They have it, want to solve it, already are trying something less than ideal, and have the availability and organizational authority to garner the resources to do something more about it.

With Project Stratus, we found many many customers have the problem (unrealistic roadmaps, poor visibility into development status of marketable features, lack of alignment between business goals and feature work). There is no doubt Rally has a responsibility to the market to produce an agile strategic planning solution. The challenge is finding earlyvangelists that can guide a successful solution to that problem.

We have been grateful to locate a handful of earlyvangelists: customers who have installed the Stratus preview application with their roadmap data, run their planning process for real with it and kept my inbox interesting with plenty of “Catherine, this is great but I need X to really make it work for us.”

If you are attending our RallyON conference on May 10 and 11, you’ll get to meet Chad. If not, track the Scaled Agile Delivery videos he has posted on his site. Thanks Chad for contributing so actively to Project Stratus!

As you can tell, it takes a while to get to the commercial product the right way to ensure the product will be a success for both Rally and its customers.

As we work at delivering the first release of our agile strategic planning product to support the first identified pattern, we are working with other Chads – Nina, Jeff, Dale, and others – to further our study of strategic planning patterns that would warrant product support. Please stay tuned.

Catherine Connor is a Product Marketing Director at Rally Software. She focuses on leveraging agile and lean values for the product manager role. She is the lead for Project Stratus.

I love the leverage  you get when strategic planning is working well.

At Rally, I run our strategic planning process with help from Jean and others in our organization. We have experimented with many agendas, internal facilitators and guests, but we’ve found the most success when Jean facilitates these meetings and I lead them. It is challenging work and we try really hard to create a setting that leads to magic and allows the best to emerge from the group.  As you might imagine, if you know Jean and me, we never stop trying to improve the process. In addition to our desire to keep advancing, the context at Rally keeps changing. Whether from growth, hiring, market changes, maturation of agile, or changes in customer demographics; our overall setting for strategic planning keeps shifting. It is a difficulty that we wrestle with, but knowing it is ultimately unsolvable, we have learned to embrace the dance.

I do not recall what was the chicken and what was the egg, but we started working on strategic agile topics last year and it launched two efforts and blog series: N Levels of Planning, and Scaling Agile to the Strategic Level. In this post I am bringing the two series together to explore tooling the process of strategic planning in an agile context with Catherine and Ronica. Larger Rally customers and past employers have shown that managing a strategic plan in a spreadsheet creates vacuums. Through our efforts at Rally, we have learned that trying to maintain strategic alignment with our development teams without a single source of record to visualize variances on plan versus actual is challenging. (HINT: Slides are not a very capable source-of-record :)

It is difficult to integrate big-bang, waterfall planning/stage-gates and traditional budgeting with effective agile teams who keep learning and adjusting. It is even more difficult to stay on course as an agile organization without effectively closing the feedback loop on roadmap/strategic planning efforts. In the first instance, it is easy to simply be driven by a naive plan. In the latter, it is easy for the development effort to drift apart from the goals and direction.

These well-validated difficulties led to the birth of Project Stratus and the N-Levels of Planning efforts at Rally. These two initiatives are intended to help increase the effectiveness of strategic planning in an agile context.  They are helping us balance the need for forecasting delivery while also benefiting from the fast feedback that flows out of agile teams and programs. We like to talk about this process as steering realistic roadmaps to maximize the delivery of value.

To explore this problem space, we diligently carried out discovery and validation exercises that led to a working application (Project Stratus) and a service offering (Agile Strategic Planning) that we use to ensure the delivery of a Whole Solution. Through our customer interviews, we found that the most common strategic planning solution when doing agile development is a strategic planning person holding the plan of record in an Excel spreadsheet. This spreadsheet holds some form of a roadmap of releases, programs and resource allocations. It is updated on a regular cycle, typically quarterly. However, two major problems exist with the spreadsheet approach.

1. The plan is outdated as soon as the work starts because there are two sources of data; one for planning and one for tracking progress
2. Planning in a vacuum happens as correlating the empirical data into a highly customized spreadsheet leads to outdated data which tends to erode trust

As a result, this most common solution is horribly disappointing with human translations that lead to over-aggressive estimates and/or status updates progress reports. Bringing agile values into this faulty process will shorten feedback loops and bring real data effectively into the cycle.

In exploring the space, we are discovering multiple ways that organizations manage the strategic planning process. As we are still making sense of these patterns, it is early to report on our findings.  However, one approach does stand out.

The model articulated in Dean Leffingwell’s newest book, ”Agile Software Requirements: Lean Requirements, Practices for Teams, Programs and the Enterprise“ is clearly one of the patterns of agile strategic planning. You can see a snapshot of this method on his blog, but if you really want to learn it, you should get his book. It is a clear articulation of how to manage your strategic priorities as series of releases. The book breaks the problem into three agile requirements management areas: the team, the program and the portfolio. The beauty of this approach is how it trains all levels of product owners, product managers and portfolio managers to run in agile unison. Dean developed this model starting with the teams and working systematically up through the enterprise portfolio level (ie bottom to top). And, importantly, Dean worked this iteratively through a number of his consulting customers over the past decade (see the Big Picture section of his blog to the incremental progress laid out over time).

In addition, in Agile Software Requirements, Dean has described a “business epic kanban system” which he uses to make the work in process visible, understand the state of epics as they transition to development, and to get the portfolio planners on a similar agile page as are the agile development teams. He and a number of our customers have used this system effectively in a number of large enterprises, so we know it makes a good starting model for portfolio/strategic planners who run portfolios as a sereis of releases.

As a result, this model of strategic allocation and roadmap planning is proven to work well for agile teams that ship code series of releases. Here is Dean’s model from that book and his web site.

Big Picture: Scaled Agile Delivery Model by Dean Leffingwell

We have a number of customers making very good progress in developing strategic roadmap steering capabilities using this approach and Rally’s Project Stratus. If you are interested in this approach paired with Stratus, consider contacting Dean or Ronica, our services owner, directly or through your Rally Account Manager. (See Ronica’s contact information below.)

We will continue to explore hybrid waterfall/stage-gate, other hybrid agile (scrum/kanban), and continuous flow techniques for strategic planning in the coming months. Please stay tuned.

Finally, to fully explore the problem and solution space, we created the RallyON conference. We will host this conference in Boulder on May 10th and 11th. We limited the conference to 150 attendees and it has sold out quickly to our most active users and champions. Don’t worry if you are not attending as there are a number of ways to engage in the conversation including:

• Responding to this post with your challenges, ideas and comments on strategic planning in an agile context
• Sharing your opinion or challenges related to topics that Rally Coaches, Technical Account Managers and Product team members are posting for the conference on our new Coaching Blog.
• Posting your agile, scrum, kanban and xp questions on pm.stackexchange.com or programers.stackexchange.com to have a the community formulate answers to your questions prior, during and after the conference. We will have expert users from both of these stackexhanges on site at the conference to help us leverage this rapidly growing community.
• No matter what choice you make, please tweet your efforts with the #RallyOn11 hashtag. It will get the attention of the Rally coaches, technical account managers and product team, in addition to all the physical and virtual RallyOn attendees.

Please join us online before during and after the conference to explore the topic of strategic agile.

About the authors:

Ryan Martens is a member of NRDC’s Environmental Entrepreneurs,  founder/CEO of the Entrepreneurs Foundation of Colorado, and Founder/CTO at Rally Software Development.

Special Thanks to Catherine Connor, the lead on Project Stratus at Rally and Solutions Evangelist Ronica Roth, who owns our Services strategy at Rally.You can reach Ronica at ronica[at]rallydev.com

In Boulder Colorado, it has been freezing cold and bright blue on the first day of both January and February. These 2 clear and crisp days have formed a meteorological metaphor for me about the year ahead. Let me give you some examples:

Back at 3333 Walnut in Boulder

• In early February, Rally moved our offices to one of our previous Walnut street addresses: 3333 Walnut street in Boulder. This time we are inhabiting the entire building, not just the first floor. The bright paint, open floors, wonderful art and huge windows are providing a clear and crisp view of the Boulder Flat Iron Mountains as well as Rally’s future.
• After a year of working on our Rally 2020 shared vision, starting with individual employees, moving up to groups and then into departments, that vision has now been incorporated into our 3-5 year planning. This long-term visioning has informed our 2011 planning in a way we couldn’t have imagined.  It is amazing how that shared vision exercise has put a clear and crisp focus on our planning.
• The 10 year Agile celebration that Alistair Cockburn held last week in a bright blue Snowbird Utah provided a clear and crisp view of what our industry needs to tackle in the coming 10 years. In Mike Hugo’s post on the event, we gained a clear, crisp of view of our mission: “Maximize value creation across the entire process.”
• Dean Leffingwell just published his Agile Requirements Management book.  I believe this will be the critical Agile requirements text in Universities around the world for many years to come.  Dean’s clear, crisp writing style and big picture model provide a promising vision of the value of Agile for the future of large organizations.
• Our Corporate Social Responsibility (CSR) team has recently received internal funding from Rally due to some great ideas and hard work. The CSR team’s January planning efforts will become public next week.  This is exciting. Thanks to this team’s perseverance, my early visions in this area of social responsibility are now starting to become a clear and crisp realization.
• We recently hired a new VP of Engineering and Operations, promoted our VP of Products to also be a CTO with me, and promoted a Director of Product Marketing to VP of Products.  With these promotions to support our growth and my upcoming sabbatical, 2011 is definitely looking clear and crisp for me.

What visual metaphor is becoming clear and crisp for you in 2011?

Ryan Martens is a member of NRDC’s Environmental Entrepreneurs, founder/CEO of the Entrepreneurs Foundation of Colorado, and Founder/CTO at Rally Software Development.

(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

(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.

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.

I’ve been pretty passionate about collaboration and knowledge flow throughout the decades of my technical life. This passion led me to author Collaboration Explained. Now I value playing with and applying a variety of visioning, planning, and learning models in Agile organizations. My reading has focused on models for individuals and organizations in how they create flow of value in 21st century businesses. For me, there could be no better place than the Agile context in which to apply these models of rich knowledge sharing. Complex Agile organizations need to consider diverse models that can effectively guide how they plan and deliver.

Agile planning helps us scale and mature across the organization

With this in mind, I’m excited to announce a new series about N levels of Agile planning. I’ll be co-authoring the series with my Rally colleagues Ben Carey, Zach Nies and other Rally folks. Ben, Zach and I want to share some of our informal conversations around Enterprise Agile planning, knowledge creation and knowledge sharing. That means we’ll be blogging about various models we think can be useful for capturing and tracking Agile business value up and down the organization.  Our suspicion is that useful scaling and maturing models coupled with overall team practices bring great value at a variety of levels within an Enterprise Agile organization.

In this series, we’ll share direct experience in applying our models both within Rally and with Rally customers. That means we’ll share some insights about collections of practices at the various levels of Agile planning. We’ll also provide guidance around the Rally services and tooling we believe support planning in continuously innovative, value-driven organizations. Also, be sure to check out Ryan Martens’s series about Scaling Agile to the Strategic Level. Ryan and others will be providing on-going guidance about Rally’s “Project Stratus” tool for road mapping and other strategic practices specifically for Enterprise Agile beyond Release planning.

Ben, Zach and I don’t believe we are the sole experts on this topic!

We’re exposing our frank conversations in hopes of gaining your reactions, insights and feedback. You probably already know about some of Rally’s existing guidance on Agile planning. We just want to dig a little deeper, play a little more with these perspectives and some new approaches that could help you innovate your own Enterprise Agile adoption. While we do this, we’ll be reporting on how we are experimenting with these models here at Rally in our own practices using our own tools and our own services as well as new practices.

Look for our first blog in the next few days describing the overall model of  “Why, How, and What” in positioning the value of Enterprise Agile planning. How many levels of planning will emerge in our exploration, and what will they look like? We aren’t yet prepared to declare in a definitive fashion. Instead, we’ll peek into that together with your input.

Join us as we go into N levels of Agile planning and beyond. We’re looking forward to great dialogue with you through the comments you bring.

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