Scaling Agile Adoption


Yesterday, we kicked off Rally’s Roadshow announcing the industry’s first Agile Portfolio Management solution. What an incredible opportunity to tell the Rally story, hear an inspiring presentation from Geoffrey Moore on how to escape the pull of the past, listen to the real-life story of aligning strategy and execution from Nina Schoen at Getty Images, and moderate a panel so lively that the panelists starting asking each other the questions.

Catch the Next Agile Portfolio Management Roadshow

Panelists Geoffrey Moore, Nina Schoen, Todd Olson, Dave West, Ronica Roth

The best way to learn more about this new solution is to tune in to our Agile Portfolio Management roadshow. Although we kicked it off this morning in the Bay Area, you can still catch Dec 8 in Boston (with Dave West from Forrester Research, Chris Haley from The CBORD Group, and Rallyers Todd Olson, Ann Konkler, Rick Simmons and others) and Dec 13 in Dallas (with author Dean Leffingwell, Chad Holdorf from John Deere, and Rallyers Todd Olson, Isaac Montgomery, Julie Chickering and others). If you can’t attend in-person, sign up for the virtual event where we webcast nearly the entire event from keynote to panel presentation, and incorporate online questions.

Self-Serve Materials to Learn More

Below are a few additional materials if you’re the self-serve type. The recorded webcast and slides of the above roadshows will be posted soon as well.

Next stop of the roadshow is Dec 8 in Boston, MA. We hope to see you there!

Ryan Martens is CTO/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.

40 preview customers, 34 builds, 3 launch events, 1 product. That’s what it took to launch our Agile Portfolio Management solution. Following Rally’s latest customer development project (see Ryan’s Lean Startup post), here’s how it all happened and Rally’s gift to you for the holiday season…

40 Preview Customers

A year ago, we put a call out to the Agile community. We knew to get it right, we had to first learn how customers currently managed their strategic plans, and the challenges they were encountering. So we scheduled many, many interviews talking to development managers, product managers and program managers currently working in large Agile development organizations to identify our “earlyvangelists”: those feeling the pain and feeling it badly enough that they crafted a way to solve it. We found most of the earlyvangelists were using Excel as their strategic planning solution – quite a flexible option for planning, but very tedious and manual to track development status of these plans.

As we dug deeper, a common set of needs quickly emerged from these interviews:

  1. Highly customizable - Every organization seems to use different terms to refer to their strategic levels (features, projects, themes, epics, SAGAs, etc.), and how many strategic levels they tracked. There is often a strong attachment to that taxonomy.
  2. High-level development status - Too much time is spent in Excel collating development status information to inform audiences outside of development. Questions such as: Did we start that initiative? Will we be able to deliver that work by this date? How much time have we spent so far working on this thing?
  3. Tracking marketable items – As Agile has scaled in development, the business is drowning in user stories and needs a way to track additional information such as: value, risk, high level size, cost and sometimes unique information like the name of the product manager accountable for delivering a feature.
  4. Realistic roadmaps – Roadmaps are mostly created in PowerPoint without accounting for actual development capacity. That results in overly optimistic plans and missed expectations. The challenge is exacerbated when teams cannot be fully cross-functional because the value to deliver requires specialized skills, often with limited yet high-demand capacity.
  5. Alignment reports - There is a need to report back to the business that development is on track with the strategic goals. Most often those are created in Excel by manually and tediously pulling information from existing tools.

From that list of identified needs, we created our backlog of features to build in our MVP (Minimum Viable Product), and took names of customers willing to install it. What was in it for them? Helping us build a supported solution to their current challenges.

We also engaged with Rally coaches and industry experts, like Dean Leffingwell, to ensure our solution would support practical and proven ways to scaling Agile.

34 Builds

Our very first MVP was actually provided to us by one of those preview customers who had been trying to solve the problem on his own – a true sign of an earlyvangelist! Thank you, Stephen, for your contribution to this project.

The MVP – named Project Stratus – was a rich client application connected to the Rally platform.  That separate application allowed us to clearly separate our development resources – those focused on our current product roadmap – from our customer development resources, and to iterate quickly to incorporate earlyvangelists feedback. We produced 34 builds in that period, about 3 each month.

Once it became obvious that we were on to something of great value to the Agile community, we started allocating core development resources to implement the critical features in our flagship product, Rally ALM.

Our hypothesis of providing a separate application well integrated with Rally was invalidated. Earlyvangelists were clear: they expected to have both strategy and execution solutions in one single environment, so the strategy was visible to development teams and execution information was available when building strategic plans.

3 Launch Events

After 34 builds, we are ready to launch the product to all customers! To unveil our entire Agile Portfolio Management solution, we are getting on the road and rallying software and business celebrities to share their knowledge on the need for businesses to join the Agile curve. We will launch our solution in the Bay Area, Boston and Dallas. In-person attendees will have the opportunity to:

  • Meet industry experts such Geoffrey Moore, Dean Leffingwell and Dave West
  • Meet preview users, from Getty Images, The CBORD Group and John Deere, to learn how they used the highly-functioning MVP to help steer their Agile portfolios over the last year
  • Participate in breakout sessions to get up close and personal with our Agile Portfolio Management solution

Not to foreshadow too much, this launch signals a major advancement for the Agile community, one that links the business and technical parts in agility. Now that is what we like to call – Scaling Agility.

1 Product

On Dec 6, we will launch the first increment of our Agile Portfolio Management product. That increment will address the most critical needs identified above. As 2012 unfolds, we will continuously deliver additional increments of the product roadmap that we validated in our customer development effort.

Don’t miss the chance to kick off Agile Portfolio Management in your organization!  We are sending quite a crew of Rally folks to each launch event to answer questions and demo our solution. We hope you will jump on that opportunity!

To sign up, register at www.rallydev.com/rpm for your preferred city. If you cannot attend live, sign up for the webcasts that will broadcast a portion of the live events.

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

Catherine Connor is Product Marketing director at Rally Software, with a passion for bringing Agile to product management. She loves hiking the Colorado foothills and cheering on the University of Colorado women’s basketball team.

I just played our fourth Agile portfolio planning game with a team of executives. First they had to rank and plan a portfolio of new product ideas, enhancements, architectural refactorings, and other work. It’s tough to balance competing priorities against strategic financial targets. Then we simulate a monthly steering council that must react to new learnings, development mishaps and market changes, all while maintaining strategic alignment.

I’ll give you a hint to winning the game:  Turn that waterfall team into Scrum teams early, and pay attention to quality.

Wagged by Plans: Is It Time to Change?

Do any of these problems sound familiar?

Execs play an Agile steering game

  • The organization funds all or most proposed projects, and expects to make progress on them all simultaneously.
  • Teams adjust each iteration based on new learnings, but the annual plan for the organization does not change.
  • Teams adjust, but it’s hard to know whether the adjustments throw the portfolio off-goals.
  • Projects are managed within silos; trade-off decisions are not made across the portfolio. As a result, some silos are under-capacity and others are overcapacity. Or, the whole doesn’t add up to the strategic objects for the organization.
  • Teams are judged on their ability to deliver value; the portfolio is judged on its ability to meet plan.

If these scenarios apply to you, you’re probably ready to bring Lean and Agile principles into your portfolio management process. Especially if you have already solved these problems:

  • Your Scrum teams are cross-functional and persistent and have learned to deliver consistently on iteration and mid-range commitments.
  • Your Kanban teams have reduced significant waste in their value stream and consistently deliver to service level agreements.
  • Agile teams have achieved a fairly consistent velocity/throughput (amount of work delivered per timebox) while delivering against quality goals.
  • The Product Owner group elaborates requirements just-in-time, feeding teams a steady stream of high-value work.
  • You have added the structures that enable multi-team programs to coordinate dependencies and deliverables within a closely related group of teams.

In working with earlyvangelists to develop our Agile Portfolio Management solution, we learned that in most organizations the portfolio is managed under the old, plan-driven paradigm, which is at odds with the Agile practices at the team and program level. However, it is equally clear that we cannot begin to challenge that paradigm before we’ve reached a certain level of Agile maturity.

It is too hard to engage the business before development has a track record of success.

It is too hard to build a realistic roadmap before teams have developed a steady velocity.

It is too hard to emphasize steering before teams have the discipline to deliver iteratively and incrementally.

Advance Your Agile Practices: The Agile Enterprise
Our early work delivering the Agile Portfolio Steering service has been exciting.  Fellow coach Isaac Montgomery and I have watched a room simply buzz as a group of leaders begins to imagine and employ the paradigm shift from plan-driven to value-driven portfolio management.

The buzz begins because of the people in the room; namely, a cross-functional group of leaders (directors, VPs, SVPs) from the business, product/portfolio, and technology. Together, we explore and understand the current challenges around building realistic roadmaps, tracking the progress of initiatives, and leveraging the agility of teams without losing focus and alignment. Sometimes this group has never built so shared a view of the organization.

There can be a moment of frustration when we’ve made the challenges so clear. But then the energy gets high as Isaac and I begin to provide possible solutions in the form of Lean practices. Together we dig into redesign their portfolio processes, to inject the visibility, feedback, governance and focus that enables Agile to work at scale.

Rally has already begun to see patterns in the Lean practices that implement more adaptive portfolio management.

  • Map the value stream from concept to cash, and build a Kanban board to represent those states. “In Development” is just one state.
  • Limit work-in-progress on that board. Fewer initiatives in play means better throughput, productivity, time to market, responsiveness, and reduced risk.
  • Emphasize value and budget over cost estimates. This requires new data and a new mentality.
  • Provide clear strategic objectives  and constraints, and then let the people closest to the work (the teams) plan the work. Use clear visualizations and data to verify the results align back to the strategy. Help teams adjust as necessary to remain aligned.
  • A rolling wave cadence of planning and steering helps your leadership be both strategic and adaptive.
  • Effective portfolio management will require planning and learning at different levels of the organization, on different levels of abstraction and strategy, and on different cadences.

The Service: Re-Tool for Agile Portfolio Management
Built on those early deliveries, I’m excited to now offer more generally our Agile Portfolio Steering workshop. I think it provides a powerful benefit through focused work.

Inspired by the lessons of the portfolio planning game, the leadership group works with an Agile coach to begin to redesign its portfolio management process:

  • How could we have better value data on proposed projects?
  • How can we decide our investments rather than be wagged by cost projections?
  • How could we fund fewer projects?
  • How could we commit to goals rather than to lists of features?
  • What data would we need to be able to steer the portfolio effectively?
  • How often should we steer the portfolio? A project? A program?
  • Could we reorganize our teams to enhance flexibility?

The outcome might be a new planning process, new data requirements, new progress visualizations, new planning and steering councils, and more.

The service is listed as “2 days”. In reality, we have learned that a leadership group might not spend two whole days in a room with us, but the hours they commit will be intense, with short breaks and working lunches, because this work matters. Dollars are at stake; business success is at stake. We will work together to design the right on-site session.

Stay tuned for more details during our Dec 6 and beyond launch events. We look forward to working with your organization, to understanding your context, and what challenges you have to align the work of your Agile teams and your strategic goals. What prevents you from delivering all the value you could to your business?

As Rally’s “Solutions Evangelist”, Ronica Roth promote solutions for our customers that combine product and process. She also promotes fun that involves mountains and snow.

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

Roadmap

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.

Why How What drawing

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

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.


Stratus2












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.


Catherine 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 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).

scaling

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:

kanban

  • 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 Booth

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

In the first part of this two-part series, I talked about deploying Scrum to parts of the larger organization without starting in development (“Can you deploy Scrum to a test team?”).  This article looks at another kind of “ScrumBut” – the most commonly meant kind:  deploying only parts of Scrum to an organization.

half-moonIs it half-assed to skip practices in adopting Scrum in your organization?

Lots of sources appear to say that it is.

Ken Schwaber gives a short presentation on ScrumBut in this video (you may have to click the “Download Optimized” button to play this).  I’d paraphrase his position as saying that the Scrum practices fit together to create more value than they do individually. So if we punt on one or more of them, he sees potential value being left on the table, and potential organizational weaknesses becoming more entrenched.  He sees Scrum as best adopted as a whole without deviation.  Consider this excerpt from his book “The Enterprise and Scrum,” about the medium-term issues in Scrum adoption:

“… many people in your enterprise are probably advising you to change Scrum because it needs some tweaking to be compatible with your enterprise.  My advice is this: Don’t Do It.”

Later in the same book, he suggests developing an organizational audit function to independently assess the degree of success in adopting Scrum:

“… the ScrumMaster and the team often get so embroiled in their work that they lose perspective on themselves.  For this purpose, having an audit capability is useful.  Someone who knows Scrum and is from outside the team needs to have a way to measure how well the team is using Scrum.”

That can be viewed as an organizational-wide commitment to avoiding ScrumBut.

This article from Mitch Lacey, “Practicing ScrumBut: Ensuring Project Failure,” captures a workshop delivered at SQE Agile Development Practices 2009.  I think the title here says it all in terms of the expected value of ScrumBut.

This article from Michele Sliger covers a particular pattern of ScrumBut that’s near and dear to my heart, failing to meet sprint commitments.   The thing I liked most in this article was the notion of “we suck less” Scrum adoptions.  Michele is encouraging us to strive for more than “we suck less” – in large measure, saying to at least aim to suck less.

Process change in large, traditionally structured organizations is hard

These authors are stressing the value of Scrum in its entirety, which is difficult to argue with.  The question for me is: “What if doing vanilla Scrum is too hard right now?”  As I noted in the first article, a big chunk of my career has been spent in larger organizations with very strong functional silos and long histories of plan-driven, waterfall lifecycles.  If you look at what you’re really asking an organization like that to do when you ask them to try Scrum, it’s clearly pretty easy for them to say “no.” Scrum sticker shock

Even on pilot projects, this may be too much to ask for from them – especially so if they’re doing reasonably well with their current processes.

Certainly the value of the practices of Scrum together is greater than their sum individually but does that mean that the value of the practices goes to zero if we don’t deploy them all together?  Can the adoption of Scrum be something that is tackled incrementally with an eye towards creating value with each incremental change?  If that last question sounds a lot like how Scrum advises us to approach the creation of value on our projects, that’s no mistake.  Sometimes, and particularly so in the kinds of large, slow-to-change organizations I’m referring to above, I think it’s sensible to ask Scrum itself to deliver its value incrementally.  In scenarios like these, I think it’s important to keep in the forefront of our minds Mike Cohn’s advice in “Succeeding with Agile” about the difficulty associated with viewing Scrum adoption as a traditional change initiative:

“… unlike other change initiatives, with Scrum there is no end state.  There is no point when you’re done.  Instead, Scrum requires continuous improvement …”

The key thing here from the perspective of assessing the value of a ScrumBut adoption is that it should not at all be viewed as any kind of finish line, but rather a potentially useful step along the path of organizational improvement.  If we’re on a path of continuous improvement, do we have to start with a big bang introduction of all of the Scrum practices?

Schedule pressure, estimation and the “Release Train” – a real-life example

I once had a client whose group followed what they called “the Release Train.”  In it, they prioritized higher-level features and other work items in a big list and then worked on a few at a time in priority order.  They did not use fixed time boxes for this work but rather used a Definition of Done to help them decide when a given work item was complete and another could be started.  In sum, a process that resembled a kanban system perhaps more so than it did Scrum.  The problem he brought to me was this:  stakeholders wanted estimated dates of completion for the items on the release train. He worked with his team to come up with these dates, but they knew that the overall project goals were heavily influencing their estimates.  For example, if a project was intended to hit a market window six months out and was to be defined by a handful of key features, the team felt considerable pressure to estimate dates for those features that met the release timelines.  We discussed the possibility of trying story points – instead of asking the team to forecast the completion date of each item, ask them to estimate each item’s size using story points and then measure the team’s progress in completing the work (in terms of story points delivered per unit time) to derive estimates of completion for future items on the release train.  We agreed that would be an interesting approach to solving the problem they were most concerned with.  Now in fairness, we had a pretty wide-ranging discussion over the course of which he talked about other problems they had – among them difficulties in establishing priorities, nailing down what the release train items actually meant, and getting inputs his team needed from other groups in a timely manner.  He expressed interest in adopting Scrum “somewhere down the line” but was unwavering in his desire to fix this one problem – improving his team’s ability to estimate release train item completion – as soon as possible.

From Estimating Duration to Estimating Size and Deriving Duration


As a Certified Scrum Coach (CSC), I suppose you could make a case that I should have pushed him harder in the Scrum direction.  In private conversations with other CSCs and Certified Scrum Trainers, my approach has been questioned as perhaps overly complacent.  In all honesty, I’m not sure.  As a coach do I strive to challenge my customers – to push them to want more than they come to me wanting. Or, do I try to solve the problems they actually ask me to solve?  For better or worse, I tend to do the latter.  I can say that it doesn’t feel complacent per se, but rather doggedly determined to make progress that provides value to my customer as quickly as possible.  In the example above, just improving their estimation practices would go a long way to improving their lot.  Why not help them do just that?

A view from the perspective of another process improvement approach – the CMMI

Much of this discussion puts me in mind of the CMMI and the difference between maturity levels and capability levels.

The CMMI defines a staged approach to organizational process improvement – very comprehensive about the order in which different aspects of the overall processes (“process areas”) has to be done.  For example, achieving maturity level two implies improvements in the following process areas:  requirements management, project planning, project monitoring and control, measurement and analysis, configuration management and process and product quality assurance (also supplier agreement management, if that makes sense in the organization).  The remaining maturity levels, three through five, are defined in a similar manner.  That prescription of a process improvement path frankly seems like the kind of approach calling for all of Scrum to be deployed in one go.CMMI Staged Representation and Maturity Levels

But the CMMI defines another approach (technically another representation) – the continuous representation, which leaves the ordering of improvement to process areas to the organization to decide, while still offering some guidance on how to go about it (the specific and generic goals and practices).  That guidance is supported by the notion of the capability levels, which define a path for improvement for the individual process areas.  In the continuous representation, an organization would be free, for example, to focus first on improving how they approach project planning practices – estimation perhaps – if they believed that was going to offer them the greatest value.

CMMI Continuous Representation and Capability LevelsSuddenly, insisting on deploying all of Scrum right away starts to feel perhaps a bit too prescriptive.

So is it half-assed to deploy part of Scrum to your organization?

Scrum is one useful assemblage of Agile practices. XP is another.  There are others.  So it’s not unreasonable to think an organization could skillfully define their own set of Agile practices or an incremental path through adoption of the complete set of Scrum practices that would provide decent value, tailored to their organization’s needs over time.  At the end of the day, if you held a gun to my head and made me winnow down Scrum to the absolute minimum I’d really not be willing to part with in any initial adoption, it would amount to just these two practices:

  • Iterate:  define a window of time in which the team commits to delivering some potentially shippable increment of working software
  • Reflect:  gather the team together at the end of each iteration just prior to planning the next iteration and ask them how they can improve

Mind you, if you do just those two for a while, you’re likely to end up inventing many of the other common Agile practices :)

But if you started even at that modest point, would you be pursuing a half-assed deployment of Scrum?  Maybe so.  But maybe a half-assed deployment of Scrum is like “half an eye” that provides value all by itself but also represents a step along the path to something amazing.

So can you deploy part of Scrum to an organization?

Sure, why not?

What do you think?

I’d like to thank Selaine Henriksen for her help in developing this post.

About the Author: Ed Willis has been a ScrumMaster, Product Owner, Scrum coach and trainer.  He is currently a developer in the telecommunications industry.

half moonThis post will be split into two parts so that it, itself, will be half-assed with the suggestion of an additional half-ass to be delivered later :) And, in keeping with that spirit, the post mistakenly went live before it was ready for prime time. This time, I meant to push the ‘publish’ button…

Can you deploy Scrum to a test team?

Scrum is at its heart a product development process.  How can you leave the part of the organization – development – that actually makes product out of any Scrum deployment? Does it even make sense for other parts of the organization to be “doing Scrum” if development is somehow doing something else? Wouldn’t you be working towards what would be, at best, a half-assed deployment of Scrum?

Craig Larman and Bas Vodde in their wonderful book Practices for Scaling Lean & Agile Development certainly agree: “…a so-called test team Scrum is a contradiction in terms.” Ken Schwaber in The Enterprise and Scrum doesn’t seem to admit the possibility of deploying to functional groups – it’s projects he’s envisioning deploying to. For example, consider this advice for early goers of an enterprise-wide adoption of Scrum: “Establish preconditions that must be met before a project can use Scrum.”

The last 10 or so years of my career have been spent in big companies with very traditional structures: functional organizations with clear separation between development, test, usability, product management, etc; running projects that are very much plan-driven. Lots of agile practices that seem relatively straight-forward in other contexts aren’t in companies like this. Consider Schwaber’s notion of organizational deployment of Scrum again – this from the introduction of The Enterprise and Scrum: “This book is for those who want to use Scrum throughout their enterprise for product development.” It’s an awfully lucky convergence of thought and opportunity that would make such a deployment possible in large, traditionally organized companies. These sets of wholly distinct sub-organizations need to be both willing and able at essentially the same time. You might get a chance like that, but I wouldn’t hold your breath waiting for it.

You can start to see why that opportunity would be rare when you look at it from their perspective.  In taking a project-by-project focus in deploying Scrum to organizations like these – and assuming you’re holding firm to deploying every part of Scrum straight away – you’re essentially asking them to:

  • Reconfigure their teams
  • Change how they define and manage product scope
  • Empower a single person to make scope decisions on each project
  • Change how they plan their work
  • Change how they approach their work in areas like development and testing
  • And so on …

The point is that, even if limited to the context of a small set of pilot projects, they have to do all of this stuff first before they can realize the benefits of Scrum.

To me, this is exactly the same argument that we, as agilists, are very much accustomed to facing from development teams:  “We can do that feature but first we need to re-engineer the infrastructure to support it, which will take six months.”  We encourage teams making that argument to find ways to do just a bit of the refactoring to allow just a bit of the value to become realizable, rather than predicating all of the value on all of the refactoring.  Why can’t we make a similar argument in support of deploying Scrum to just a part of the organization?

What would Voltaire say?

VoltaireOne of my favorite lines – frequently quoted in optimization discussions but applicable equally well here – comes from Voltaire:  “Le mieux est l’ennemi du bien” (the best is the enemy of the good). “Best” is hard to define in any complex system like a large company but “good” seems a little more tractable. We should not let an inability to approach some notion of perfection prevent us from getting better.

A colleague was presented with this exact scenario a while back.  Representatives from a test group came to him asking if he would work with them to try Scrum.  He and I spent some time talking it over.

Things like product owner, product backlog and potentially shippable product increment looked like a tough fit for a test team, to be sure. But still, we thought of goals like “verify feature X” where the challenge to the team is to find a way to work together to get that done within the time-box of the Sprint. That might be a liberating shift in thinking after heavy doses of planning of the form: “We have a bazillion manual tests to execute. At 5 per hour, that’s bazillion/5 staff hours. With 20 FTE, that’s a bazillion/(20*5*40) weeks of testing.” Looking ahead to subsequent Sprints, we envisioned helping the test team bring some of their development partners into their Scrums – perhaps through broadening the notion of the verification goals to include “hardening” – finding and fixing bugs as a cross-functional team. And from there to the odd small feature, slowly working our way towards aligning the work of the test and development organizations in cross-functional Scrums. Even with such an odd scope of initial deployment, we could see potential benefits, including improved productivity through the iterate and reflect cycle, better planning and estimation and higher morale.  Not surprising, these are the same benefits we would suggest lay before any team looking to try Scrum.

Isn’t this the good that Voltaire would caution us against passing on?

deployingScrumThroughExpandingToDiferentPracticesLarman and Vodde have some great advice about how to go about ever more closely approaching the “potentially shippable product increment” goal of the Sprint through expanding the Definition of Done (DoD below):

“In general, these are the ways of expanding the DoD:

  • Automate – for example, performance testing is automated
  • Expand team cross-functionality – for example, a person with technical-writing skills joins the team”

That latter idea suggests a path to improvement that starts in development and then spreads over time to the remaining functions.  If we view Scrum deployment as being something we do in the context of projects and products, this is both natural and reasonable.  But, if we view deploying Scrum as something we do in the context of teams of people or if we view it simply as “transforming the world of work,” then why would we believe we have to start with any particular set of people?  Why not start with testing and grow our way towards development?deploying Scrum through expanding to new teams

Would that be a half-assed approach to deploying Scrum?  Perhaps, but like Richard Dawkins’ half a wing or half an eye, maybe half an ass may prove a more useful incremental improvement than may be apparent at first glance.

So, can you deploy Scrum to a test team?

Sure, why not?

What do you think?


About the Author: Ed Willis has been a ScrumMaster, Product Owner, Scrum coach and trainer.  He is currently a developer in the telecommunications industry.














Description: C:\Users\ewillis\Desktop\Subversion\articles\Half-Assed part 1\half_moon.jpgI’ll split this post into two pieces so that it, itself, will be half-assed with the suggestion of an additional half-ass to be delivered later J

Can you deploy Scrum to a test team?

Scrum is at its heart a product development process. How can you leave the part of the organization – development – that actually makes product out of any Scrum deployment? Does it even make sense for other parts of the organization to be “doing Scrum” if development is somehow doing something else? Wouldn’t you be working towards what would be, at best, a half-assed deployment of Scrum?

Craig Larman and Bas Vodde in their wonderful book “Practices for Scaling Lean & Agile Development” certainly agree: “a so-called test team Scrum is a contradiction in terms.” Ken Schwaber in “Enterprise and Scrum” doesn’t seem to admit the possibility of deploying to functional groups – it’s projects he’s envisioning deploying to. For example, consider this advice for the early going of an enterprise-wide adoption of Scrum: “Establish preconditions that must be met before a project can use Scrum.”

The last ten or so years of my career have been spent in big companies with very traditional structures: functional organizations with clear separation between development, test, usability, product management, etc; running projects that are very much plan-driven. Lots of agile practices that seem relatively straight-forward in other contexts aren’t in companies like this. Consider Schwaber’s ideas of organizational deployment of Scrum again – this from the introduction of “The Enterprise and Scrum”: “This book is for those who want to use Scrum throughout their enterprise for product development.” It’s an awfully lucky convergence of thought and opportunity that would make such a deployment possible in large, traditionally organized companies. These sets of wholly distinct sub-organizations need to be both willing and able at essentially the same time. You might get a chance like that but I wouldn’t hold your breath waiting for it.

You can start to see why that opportunity would be rare when you look at it from their perspective. In taking a project by project focus in deploying Scrum to organizations like these – and assuming you’re holding firm to deploying every part of Scrum straight away – you’re essentially asking them to:

· Reconfigure their teams

· Change how they define and manage product scope

· Empower a single person to make scope decisions on each project

· Change how they plan their work

· Change how they approach their work in areas like development and testing

· And so on …

The point is that, even if limited to the context of a small set of pilot projects, they have to do all of this stuff first before they can realize the benefits of Scrum.

To me, this is exactly the same argument that we, as agilists, are very much accustomed to facing from development teams: “we can do that feature but first we need to re-engineer the infrastructure to support it which will take six months”. We encourage teams making that argument to find ways to do just a bit of the refactoring to allow just a bit of the value to become realizable, rather than predicating all of the value on all of the refactoring. Why can’t we make a similar argument in support of deploying Scrum to just a part of the organization?

What would Voltaire say?

Description: C:\Users\ewillis\Desktop\Subversion\articles\Half-Assed part 1\voltaire.jpgOne of my favorite lines – frequently quoted in optimization discussions but applicable equally well here – comes from Voltaire: “Le mieux est l’ennemi du bien” (the best is the enemy of the good). “Best” is hard to define in any complex system like a large company but “good” seems a little more tractable. We should not let an inability to approach some notion of perfection prevent us from getting better.

A colleague was presented with this exact scenario a while back. Representatives from a test group came to him asking if he would work with them to try Scrum. He and I spent some time talking it over.

Things like product owner, product backlog and potentially shippable product increment looked like a tough fit for a test team, to be sure. But still, we thought of goals like “verify feature X” where the challenge to the team is to find a way to work together to get that done within the time-box of the Sprint. That might be a liberating shift in thinking after heavy doses of planning of the form “We have a bazillion manual tests to execute. At 5 per hour, that’s bazillion/5 staff hours. With 20 FTE, that’s a bazillion/(20*5*40) weeks of testing.” Looking ahead to subsequent Sprints, we envisioned helping the test team bring some of their development partners into their Scrums – perhaps through broadening the notion of the verification goals to include “hardening” – finding and fixing bugs as a cross-functional team. And from there to the odd small feature, slowly working our way towards aligning the work of the test and development organizations in cross-functional Scrums.

Even with such an odd scope of initial deployment, we could see potential benefits, including improved productivity through the iterate and reflect cycle, better planning and estimation, and higher morale. Not surprising, these; they’re the same benefits we would suggest lay before any team looking to try Scrum.

Isn’t this the good that Voltaire would caution us against passing on?

Description: C:\Users\ewillis\Desktop\Subversion\articles\In Defense of the Half-Assed, part 1\deployingScrumThroughExpandingToDiferentPractices.pngLarman and Vodde have some great advice about how to go about ever more closely approaching the “potentially shippable product increment” goal of the Sprint through expanding the Definition of Done (DoD below):

“In general, these are the ways of expanding the DoD:

· Automate – for example, performance testing is automated

· Expand team cross-functionality – for example, a person with technical-writing skills joins the team”

Description: C:\Users\ewillis\Desktop\Subversion\articles\In Defense of the Half-Assed, part 1\deployingScrumThroughExpandingToNewTeams.pngThat latter idea suggests a path to improvement that starts in development and then spreads over time to the other functions. If we view Scrum deployment as being something we do in the context of projects and products, this is both natural and reasonable. But if we view deploying Scrum as something we do in the context of teams of people or if we view it simply as “transforming the world of work”, then why would we believe we have to start with any particular set of people? Why not start with testing and grow our way towards development?

Would that be a half-assed approach to deploying Scrum? Perhaps, but like Richard Dawkins’ half a wing or half an eye, maybe half an ass may prove a more useful incremental improvement than may be apparent at first glance.

So, can you deploy Scrum to a test team?

Sure, why not?

What do you think?

Next Page »