Agile Development Blog

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…)

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

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

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

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

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

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

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

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