Agile Development Blog

It’s Agile 2011!

In my post last week, Agile and Rally – We’ve come a long way, I mentioned that Rally has a special commemorative activity at our booth this year. Now that the conference is here, I wanted to share more about this cool activity and let you know how you can participate with us.

Illustrating Agility

Starting today and throughout the conference, Rally will be illustrating, literally, the past, present and future of Agile’s exponential growth from the Agile Manifesto through mainstream adoption, and beyond. We need your ideas to help shape this illustration! If you are attending the conference, please stop by the Rally booth during exhibit hours and tell us about your Agile adoption, your most important milestones and the trends you think will shape the future of agility. If you’re not at our booth, or not even at the conference this week, you can also tweet your submission #roadtoagility. Then be sure to stick around and see our performance illustrator Bryce Widom drawing submissions in real-time.

We will be sharing photos of the illustration throughout the conference. Join us on Twitter (the #RoadtoAgility hashtag), Flickr, Facebook, and through the comments below to contribute your ideas, share your thoughts and see how the illustration evolves.

Jean Tabaka is a frequent flyer on no particular airline, an author and Agile Fellow at Rally Software Development. You can follow Jean on Twitter at @jeantabaka

In our Agile Tooling for High Assurance Software Development series we’ve looked at a prescribed user story structure for requirements traceability and we dove into how tooling is important to maintain relationships needed for traceability to other artifacts in the system (defects, test cases, etc.). Given this, how do we automate a traceability matrix from Rally?

First let’s review the why. Why do we spend so much time and energy creating traceability matrices?

There are a number of sources that I could cite but I’ll go back to the Design Control Guidance for Medical Device Manufacturers, where section F Design Verification states:

DOCUMENTATION OF VERIFICATION ACTIVITIES. Some verification methods result in a document by their nature…

Another self-documenting verification method is the traceability matrix. This method is particularly useful when the design input and output are both documents; it also has great utility in software development. In the most common form of the traceability matrix, the input requirements are enumerated in a table, and references are provided to each section in the output documents (or software modules) which address or satisfy each input requirement. The matrix can also be constructed “backwards,” listing each feature in the design output and tracing which input requirement bears on that feature. This reverse approach is especially useful for detecting hidden assumptions. Hidden assumptions are dangerous because they often lead to overdesign, adding unnecessary cost and complexity to the design. In other cases, hidden assumptions turn out to be undocumented design input requirements which, once exposed, can be properly tracked and verified.

Although this is only a guidance, it is pretty clear that the FDA is encouraging the building of traceability matrices, that might be “why” we all create them. In order to automate the creation of this matrix Rally has offered two Rally Catalog apps in the product, the Iteration Traceability App and the Release Traceability App. The screenshot below shows an example of the Iteration Traceability App that displays Stories with their associated Tasks, Test Cases, and Defects for an Iteration.

In the spirit of the work that Dean Leffingwell and I have been doing I persuaded one of Rally’s awesome App Developers, Charles Ferentchak, to help me build an additional trace matrix app based on an example shared by a customer. This app is not bound to an Iteration but instead allows the creator to select from their list of tagged PRD’s and creates a trace report showing all of the features associated to the PRD along with test cases, results, design outputs, and etc.

Both of these traceability matrices are examples of possible automation that can be easily achieved by adding tooling to your Agile practice.

To submit your own idea for a Traceability Matrix to Rally’s Product Team visit Rally Ideas for Regulated Industries and the next time you are on LinkedIn be sure to join the Agile in Regulated Environments LinkedIn Group.

And, as always, I encourage your comments on this post or email craig@rallydev.com.

Craig Langenfeld is a Technical Account Manager with Rally Software Development who has been working closely with many Agile Practitioners in the Healthcare Industry to define best practices.

Dean Leffingwell is an entrepreneur, executive, author and consulting methodologist who provides agile transformation consulting services to large software enterprises. Between consulting engagements and keeping up with his Blog Dean managed to publish his latest book, Agile Software Requirements.

Are you challenged with trying to map Agile Software Requirements to a traditional requirements model for the documentation required during internal or external audits?

If you answered “yes”, you are not unlike many of Rally’s highly regulated customers who want to reap the benefits of Agile but struggle to find good tools for creating and managing system documentation. For the next two posts in our Agile Tooling for High Assurance Software series, I will provide an overview of the material that I presented to a small sampling of customers in early May at our inaugural RallyON conference in Boulder. This work is a continuation of the project that Dean Leffingwell and I have been working on over the past year.

Let’s start by reviewing Dean’s post, Agile Software Requirements in High Assurance Development, which provides us with a traceability model as well as a medical device example to follow. From there I’ll demonstrate how Rally can be used to support traceability from what we traditionally think of as a PRD, a document detailing the system’s intent, to user stories that are commonly used to implement the features of the system.

An important part of the verification effort is to assure that every feature traces to one or more user stories (or other forms of software requirements expression) as is illustrated below. But first we need to begin with a PRD that defines the overall behavior and intent of the system. This will serve as design input in FDA terms. The PRD is going to be decomposed into individual features that will be implemented by many Software Systems Requirements, which we’ll also refer to as User Stories. Take a moment to review the illustration.

With regard to managing these requirements, many of us have encountered or even created spreadsheets with thousands of rows of requirements and tens of columns of attributes that described the system we intend on building.

As part of the introduction to Agile practices we will trade-in the spreadsheet for an Agile Lifecycle Management (ALM) tool that will provide us with better traceability to the real system being implemented. An ALM tool, like Rally, allows us to create a high level user story that will represent system intent and maintain those items that we said were important to document such as a PRD. In Rally the system, intent, features, and user stories will all be tightly coupled by creating a family of user stories through parent/child relationships.

The screenshot below shows the EPAT example that Dean Leffingwell described in his post, extrapolated in Rally. Notice that our EPAT Device Enhancement has been broken down in a way that will allow us to trace each child user story back to the PRD (represented by a parent user story). Another convention being used in this example is that of tagging. Rally users often tag stories to represent requirement types like PRD, SRS, functional, or non-functional stories for better reporting on specific story groups.

Being prescriptive and consistent when structuring our Agile Software Requirements (User Stories) in Rally provides us with the unique capability to create our own custom document exports, such as the Product Requirement Document that I will highlight in a post next week.

In summary, Rally helps us to transform individual user stories that each implement a small increment of value into a aggregation of stories that represents the intended product.

To learn more about Rally’s User Story Hierarchy watch this informational video.

To submit your own ideas to Rally’s Product Team see Rally Ideas for Regulated Industries and the next time you are on LinkedIn be sure to join the Agile in Regulated Environments LinkedIn Group.

And, as always, I encourage your comments on this post or email craig@rallydev.com.

Craig Langenfeld is a Technical Account Manager with Rally Software Development who has been working closely with many Agile practitioners in the healthcare industry to define best practices.

Dean Leffingwell is an entrepreneur, executive, author and consulting methodologist who provides agile transformation consulting services to large software enterprises. Between consulting engagements and keeping up with his Blog Dean managed to publish his latest book, Agile Software Requirements.

This is the second post in our blog series, Measuring the Impact of your Agile Investments. The series focuses on measuring the impact that Agile practices have on business outcomes.

For many leaders, increasing the productivity of the development organization (delivering features the business needs and generating improved ROI) is their primary and over-riding goal. ‘Doing more with less’ is a mantra they preach to their teams continuously, and which colors every decision they make.

Yet few have a clear and consistent definition of productivity or an effective means of measuring it.

Productivity: a relative measure of the efficiency of a system in converting inputs into useful outputs.

Productivity: the ratio of the real value of outputs to the combined input of labour and capital.

Productivity: a measure relating a quantity and quality of output to the inputs required to produce it.

So, in simplest terms:

Productivity = Valuable Outputs / Costly Inputs

Be Careful What you Wish For

While I am a ardent believer in the value of metrics, it is important to keep in mind the potential for unintended consequences. Individual and group behaviors will evolve to meet your measures – not necessarily your goals. So ensure that the measures you use promote the behaviors you desire.

Most documented productivity metrics in software development define a unit of output as either a KLOC (thousand lines of code) or as a Function Point. Both have significant disadvantages.

KLOCs are generally favored for the simple reason that they’re unambiguous and easy to measure. However, they can unintentionally promote poor design and coding practices. Elegant, efficient, maintainable software takes more time to write, and takes fewer lines of code. Therefore, a KLOC metric inadvertently creates a disincentive for building high-quality software, and rewards poorly thought through designs and shoddy craftsmanship.

While Function Points don’t necessarily promote poor design and craftsmanship, they have their own unique challenge – they are famously difficult and expensive to calculate and measure.

Perhaps even more importantly, both KLOCs and Function Points ignore the core aspect of ‘Value’ inherent in our definition of output – and therefore productivity.

It has been stated that 64% of the features and function in the typical software system are rarely or never used (Standish 2002). Calling the code that delivers these features and functions “productive” may be a mischaracterization.

Similarly, those features and functions that ARE commonly used are generally not of uniform value. The Pareto Principle would suggest that 80% of the value is delivered by 20% of the effort. Yet KLOC and Function Point-based metrics treat all features and functions (and code) delivered as interchangeable. This promotes focusing on the easiest and lowest technical risk; rather than the most valuable, most innovative and greatest business risk…

Output is a measure of the value delivered, not the effort expended.

A number of people in the Agile community have written about an alternative unit of output measure – Value Points.  While the simplicity and value focus of this model is appealing, it has challenges when scaled beyond a few teams. In order to be meaningful at the organizational level, you must normalize the relative value point scale across teams and programs – which can be difficult and expensive.

Also, the Value Point approach does not easily translate to initiatives and/or divisions that may not be delivering in an Agile manner. Having a common measure of output, and therefore productivity, is critical to measuring the impact of your Agile investment.

So, the approach we recommend is to associate a percentage of the total value of a given initiative to each Minimally Marketable Feature (MMF) or production release. These percentages can then be applied to a any monetary business justifications (ROI, NPV, Discounted Cashflow, etc.) to arrive at an expected dollar value realized from each release.

Hence,

Productivity = Total Value Realized (delivered to production) /  Total Cost of production (labor)

Using this approach, your organization (be it a Scrum team, a multi-team Agile program, a waterfall project, or even an entire product development group) base-lines their productivity for a period of time and monitors the change over time.

Example:

The division has 3 initiatives in progress:

• Initiative A:  Total Expected Value $5MM; being delivered by a Scrum team with an iteration run-rate of $70,000.
• Initiative B:  Total Expected Value of $25MM; being delivered by 5 Scrum teams with a combined iteration run-rate of $400,000.
• Initiative C:  Total Expected Value of $50MM; being delivered according to a project plan and resource matrix that charges $2.5MM to the project in the 1st quarter.

In Q1:

• Initiative A: Released to production monthly and delivered a total of 60% of Expected Value; or $3MM. 25% of the backlog has been burned-down in terms of story points. Total Cost $210,000. PRODUCTIVITY = 14.29
• Initiative B: Released to production quarterly and delivered a total of 65% of Expected Value; or $16.25MM. 35% of the backlog has been burned-down in terms of story points. Total Cost $1.2MM. PRODUCTIVITY = 13.54
• Initiative C: Completed requirements definition and is 50% done with Detailed Design, and delivered 0% of Total Expected Value. Total Cost $1.2MM. PRODUCTIVITY = 0

*undelivered work is WIP, and therefore not yet productive.

Aggregate Division Productivity for Q1 = 7.38

As you can see, it would be relatively straightforward to predict Q2 productivity – at the initiative as well as division levels – by assessing the various product roadmaps and traditional project plans. Those projections could then be used to:

• drive discussion about trade-offs on where to allocate limited capacity and maximize productivity
• staff and fund initiatives where productive potential is high, and to cancel successful projects whose greatest productive potential has already been harvested
• inform intelligent business decisions – which is WHY we’re measure outcomes

By understanding the productivity of the development organization (its efficiency in delivering features the business needs and delivering improved ROI), leaders can effectively drive improvements and business decisions that maximize productivity – Doing More with Less.

The next topic I’ll address in the Measuring Impact series is Quality. Most organizations claim to have a Quality focus, yet few take a holistic view of Quality or appreciate the strong correlation between Quality and our other Outcome Metrics – Productivity, Responsiveness, Customer Satisfaction, Employee Satisfaction and Predictability.

How are you measuring the impact of your agile investments? Please share your ideas and feedback in the comments.

Isaac Montgomery is the harried father of twin sons, the adoring husband of Angie, a frustrated hack on the golf course, and an Agile Coach at Rally Software. He blogs at Leading Results, you can follow him on twitter at @iwmontgomery

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

Welcome to our new blog series, Measuring the Impact of your Agile Investments. This series focuses on measuring and quantifying the impact that Agile practices have on business outcomes. We’ll explore how putting comparable metrics in place allows organizations to steer improvement efforts in the right direction and realize the biggest payoffs of Agile.

“How do we measure the success of agile?”

It’s one of the most common questions we hear from senior leaders.  And it’s a critically important one for agile evangelists working to justify the organization’s investment in agile and maintain momentum as other priorities compete for leadership attention. The agile community’s typical response to this question has been some form of an agile maturity assessment – such as the Nokia Test. These tools are clear, easy to use and can be extremely effective in helping organizations assess their adherence to good agile practices.  Yet, when used in isolation, they can leave senior leaders unfulfilled – and miss an important opportunity for aligning agile to fundamental objectives.

For business leaders, the question isn’t how well are we doing agile?  The question is how well is agile doing for us?  What impact is agile having on business results? These are the questions senior leaders really want answered.

My response has typically been: “How did you measure your impact on business results before Agile?”

Which is generally met with awkward silence and a muttered admission of: “Not very well.”

The conversation then moves toward why measurement is expensive, why you can’t show progress if you don’t have a baseline, and why you need to be very careful about what and how you measure – lest you create unhealthy behaviors and unintended consequences. Someone ultimately quotes Einstein, we nod our heads thoughtfully, and finally move on to other topics. Crisis averted!

But the question remains: “How do we measure the success of agile?”

And, if Agile Success = Business Success, then the real question is: “How do we measure business success?”

Which is the question we’re beginning this blog series to address.

While every organization will have their own unique objectives and priorities, most can be encapsulated as some combination of these:

• Productivity
• Quality
• Responsiveness
• Customer Satisfaction
• Employee Satisfaction
• Predictability

In the posts to follow we will examine each of these Business Outcomes and look at:

• How can we measure the business outcome?
• What agile practices are effective levers in improving the business outcome?
• How can we measure our agile levers as leading indicators of improved business outcomes?

The first topic I’ll address in the Measuring Results series is Productivity, because for many leaders, increasing the productivity of the development organization is their primary and overriding goal.

Isaac Montgomery is the harried father of twin sons, the adoring husband of Angie, a frustrated hack on the golf course, and an Agile Coach at Rally Software.  He blogs at Leading Results, you can follow him on twitter at @iwmontgomery

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

Does your current tooling environment provide traceability paths for User Story Verification within an Agile Iteration? My last two posts in this series described how Agile tools, like Rally and Quality Center, are used to achieve this very objective. In this post I will bring the User Story Verification conversation to a close by elaborating on the last two points of Dean Leffingwell’s proposed Traceability Paths for High Assurance Software Development.  The final two points are:

• User story to code – path to the SCM record that illustrates when and where the code was changed to achieve the story
• User story to code-level unit test (the “white box” test which assures that the new code works to its internal specifications, also maintained via path to the SCM change set)

Dean provides us with a nice illustration of the Traceability Paths Model to review before we hop into a tooling example:

Let’s start with User Story to Code!

(more…)

I’m excited! Next week is shaping up to be something of an epic little timebox for me: 3 keynotes in 3 different cities in 3 days. I love it! Sustainable pace? Well, maybe not every week. But next week has me fired up. I’ve got a definition of Done Done Done that has me flying high.

Here is what’s on the agenda for my 3-day extravaganza:

April 5th finds me in Chicago, an old haunt of mine.

I’ll be part of one of my favorite events with Rally and its partners: “Agile Comes to You”. The keynote? “12 Agile Adoption Failure Modes.” I’ll be talking about negative patterns for Agile adoptions. Yes, I know there are more than 12 ways to ensure an Agile adoption fails. But I only have 30 minutes to speak :-) Heading back to Chicago, I look forward to making new friends and meeting up with old friends, especially one of our panelists, Brendan Flynn of PointRoll. I’m eager to find out what Chi-town is up to with the move of Agile onto “main street” (or is that the Magnificent Mile?) Want to join us? Sign-up here, come say hello at the Chicago Marriott Downtown, and share some of your experiences and queries.

April 6th I hop over the border to one of my favorite Canadian cities, Toronto, Ontario.

Here again, I’ll have the honor of bringing my keynote perspectives on how Agile adoptions fail. I’m eager to learn with attendees what they have seen in this great city and the surrounding technology area about their Agile adoptions. And, I look forward to our discussions on how we can truly succeed in adopting Agile for great, sustainable business value. If you are in Toronto on the 6th, join us in this “Agile Comes to You” event at the Toronto Grand Hotel and Suites by signing up here.

April 7th I return home to Denver, the “Mile High City.”

And yes there is another event in store. I’m very honored to have been invited to be the keynote speaker at the inaugural “Mile High Agile” event. This is going to be a particularly special event for me. My colleagues Rachel Weston and Zach Nies will be co-presenting on “Using Agile Principles to Solve Tough Problems in Your Business.” Rally as a Platinum Sponsor is investing in our great Agile community in the Denver area. The air may be thin up here but the interest in Agile is deep and passionate. We are extremely fortunate to have a group of wonderful, hard-working organizers from the Agile Denver group: Brad Swanson, Somnath Ghosh, Walter den Haan, Tom Smallwood, Eric Cussen, Jim Turosak, Jan Beaver, and Jon Archer. Brad has worked with me to engage in one of my favorite topics for the keynote, “Elevating the Agile Community of Thinkers.” This talk affords me the opportunity to continue to share my passion about community as thinkers and thinkers as community in our Agile world. To all my friends along the Front Range here in Colorado, I look forward to seeing you at The Plaza at the Denver Merchandise Mart.

Coming full circle, my “3 strange days” will move through Agile failure modes to the great community of thinkers we gather in our Agile growth and success. As Captain Picard would say, “Warp One! Engage!

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