Agile Development Blog

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

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.

I love games! Especially games that help teams grasp Agile principles and practices. There is nothing like a good game to help build some solid muscle memory around core aspects of how Agile impacts teams and organizations.

In the next couple of months, I have the very good fortune to be involved in several Agile game events. I’m lucky enough to try out new games, bring in some systems thinking and design thinking games, and help others apply games.

To learn more about Agile games, check out the AgileGames Google group, Agile 2011 Salt Lake City in August and Agile Games 2011 in the Boston area in April.

And watch my little video to find out what’s happening and why I am so excited!

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

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.

Of course!

Back in October, Rally started a project led by Craig Lagenfeld, one or our great Technical Account Managers, and Dean Leffingwell, see more on Dean below, to take the FUD (Fear, Uncertainty and Doubt) out of this application of agile methods.

If we hit this out of the park, we will be delivering guidance to the Agile Community that describes the best practice for developing high assurance software in highly regulated environments. The primary guidance will be a detailed “how to” whitepaper that will include examples of organizations who are already utilizing one or more of the practices and tools that we describe. Other deliverables will include a blog series, webinar, and tool validation guide. In short, the Agile Community will change their question from “can we utilize Agile to create high assurance software and still be compliant” to “how soon can we get the process and tools implemented to take advantage of Agile”.

Now two months into the project, we are trying to broaden the audience and collaborators for this work. We’re excited about this project and the great feedback we are getting from the Agile community. The blog series is generating a lot of interest, with people either wanting to know more or offering to contribute. Heck we even have quite a few emails from the Compliance Community wanting to help us out. Keep the emails coming- or better yet, start directing all of your support, questions, and feedback to the blog posts (and comments on this post) so that we can keep this building in a public forum. In the end Dean and I plan to deliver much more than a series of blog posts. We want to deliver guidance that Rally customers and Agile Practitioners can use to educate themselves and their organization.

The purpose of the project is to bring together Agilists who know that Agile is a better way to produce safe, reliable innovations but are unsure of how to accomplish this within a highly regulated environment. In our second post, Dean and I decided to use medical devices as the focus of our work, providing real examples of how medical device companies are confidentially using Agile practices today (see our recent posts on Abbott Labsand GE Healthcare). My part in the project focuses largely on ensuring that we provide a best of breed tooling suggestion to support the process that Dean and other experts in the field are developing. – Craig Langenfeld

Dean Leffingwell is a great friend, author, and entrepreneur. Before starting Requisite, the orignal makers of Req Pro, Dean ran a company called Rella that manufactured medical devices. Not only does he know software, agility and lean, but has many stripes from medical device certification and compliance. We are thrilled to be collaborating with him again; if you do not know his work, he is the author of Scaling Software Agility: Best Practices for Large Enterprises and the soon to be published Agile Software Requirements: Lean Requirements Practices for Teams, Programs and the Enterprise.

Again, if you are in this field please join Criag, Dean and your peers in the High Assurance and Regulated category of Dean’s blog.

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

Craig Lagenfeld is a Technical Account Manager at Rally Software Development.

Dean Leffingwell is an entrepreneur, executive, author and consulting methodologist.

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

I am excited to say that this week we announced, at the Gartner AADI Summit and Agile Development Practices East, the availability of a new service offering and product from Rally. To support this launch and amplify the feedback loops from the community, we are starting a blog series on this topic. All of the blog posts in this series will show up in the blog, but also get linked into a summary page focused on Scaling Agile to the Strategic level (above release level, including roadmap and vision level for products, programs and solutions).

If managing Agile at the strategic level is something you are expert at or struggling with, you will want to follow this series. It is going to be written by a team of folks from Rally including myself, Jean, two internal Coaches at Rally, eighteen external Coaches at Rally and product experts.

In the last year, we have read a ton on strategic execution and lean, blogged on many of those ideas, experimented with talks and exercises and worked with a number of our customers. In addition, we ran our fellow Rallyers through many of these concepts. As a result of this work and the rapid development of our supporting product, code-named “Project Stratus,” we feel that we are ready to offer some value in the form of professional, product and community services to educate, enable and explore these concepts, methods and tools with our customers.

From sharing our experiences, we have learned that managing above the release level, at the roadmap and vision level, is different than project or program-level management. It is NOT:

• as focused on the big epic feature as the desired outcome
• an extension of the integrated agile release train as much as management of flow and contention

These offerings are brand new; we know they will change with more feedback and experience; as a result, they are being released now with less packaging and polish. The service offering starts with a two-day assessment and training effort, but then moves into a custom statement of work. The Project Stratus product offering will remain in preview status for the short term. We assume that focused work with 15 to 20 key customers will shape these solutions for all.

If you think you could be one of those customers, please do not hesitate to contact your account managers, coaches or customer success representatives. We are anxious to share these breakthrough concepts with customers who are willing to co-develop them with us.

With regard to the blog series, we see the following topics getting explored over the next three months:

• Introduction
• Our Theories and Why Project Stratus?
• Our Agile Strategic Planning Service offering
• The making of Project Stratus
• Prediction in Kanban versus Scrum commitment
• Enterprise Kanban and AgileZen
• Others, based on your comments and feedback

If you have topic ideas or comments, please post below. Again, don’t forget to subscribe or share the RSS feed or email feed for the blog to be part of this discussion. We want YOU to participate in this Community of Thinkers!

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

It’s shaping up to be a busy November for us here at Rally with conferences on both coasts. We’re a Silver sponsor of Gartner’s Application Architecture, Development & Integration (AADI) Summit November 15-17 in Los Angeles. For Agile Development Practices (ADP) East November 14-19 in Orlando, Rally is the Conference Sponsor and once again I’m honored to be presenting. We’re coast to coast, and we’ve got discount codes for both conferences (see below).

Rally on the West coast with AADI

Rally is excited to be a part of Gartner’s AADI Summit that focuses on powering the Agile enterprise. The summit includes a key conference track on Agile and highlights three critical building blocks of a successful applications strategy—Cloud, SOA and the overhaul of existing Applications. Stop by the Rally booth to talk with one of our Agile coaches or other team members to learn how we can help move your organization into the next phase of Agile adoption.

In addition, one of Rally’s high-profile, enterprise customers will be speaking about how their adoption of Agile practices in an 800-person development organization (within a $15 billion division) has delivered:

• 3X better throughput
• an 89% bug reduction
• the elimination of over 180,000 hours of development time in one quarter

For more news and information about the summit, follow the #GartnerAADI hashtag on Twitter. Also, stop by the Rally booth (F) to pick up a hat, register for a chance to win an iPad, and to learn more about how we can partner with you in achieving Agile success.

Rally on the East coast with ADP East

Once again, Rally is proud to be the Conference Sponsor for ADP East. This conference is a great opportunity to dive into both Agile basics and the latest trends in Agile. Participants will gain guidance in testing, development and organizational best practices.

I always love the ADP conferences because of the energy of the participants and the variety of topics. The conference is a great venue in which to share new ideas and experiences. This year I’m excited about exploring new trends in Kanban as well as revisiting Agile basics such as story writing.

Be sure to check out my two sessions on Monday and Wednesday along with these other opportunities to join with us at the conference:

• Monday, 11/15 at 8:30 am – Writing Great User Stories 1/2 day tutorial
• Tuesday, 11/16 at 4:30 pm - Welcome Reception, sponsored by Rally
• Wednesday, 11/17 at 12:45 pm – Lean, Kanban and the Art of Flow regular session with Bill Wake, Senior Coach at Industrial Logic, Inc.
• Wednesday, 11/17 at 2:45 pm – Agile with the Right Tools can Maximize Developer Productivity with Collin O’Brien, Technical Account Manager and Sean Billow, Major Account Manager at Rally Software
• Visit the Rally Software booth # 7 & 8 to chat with Agile coaches and other Rally team members about how we partner with organizations through tools, coaching and community to help achieve Agile success. Rally is also contributing an iPad to the conference Passport game, so be sure to stop by to get your passport stamp.

For more information and updates about the event, follow the #ADP10 conference hashtag on Twitter.

If you’d like to join us for either of these events, use the following registration links and discount codes: Gartner AADI use code ADRD to save $300; ADP use code RAAV to save $200

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