Agile Development Blog

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.

In a continuation on my last post on Eric Ries and The Lean Startup, I wanted to share how these concepts continue to ripple through Rally. (Learn more on how to apply these topics in your business at our upcoming in-person and virtual Portfolio Management Roadshow featuring Eric alongside an awesome line-up of speakers.)

Three weeks ago while in Denmark, I had a deep dive with customers on the topic. While in Copenhagen Denmark and talking with 40 European customers at Rally’s Agile Open Forum, one of the top 5 questions that group proposed was:

“How can we develop features that give the maximum long-term value and the minimum long-term cost?”

Vist Custdev.com for this "Cheat Sheet"

I believe you will find the answer to this question in Steve Blank’s customer development approach to differentiating new products or simply in the build-measure-learn cycle of Lean Startups. For Agile teams that can already build right and build fast, this answers the question of what to build!

By focusing on the concept of creating “validated learning,” a Lean Startup team does not provide solution development teams stories that are not validated or constructed to validate a hunch.  As such, the Agile backlog becomes prioritized by learning and risk.  The result is a team that couples Agile product development cycles with customer problem discovery and customer solution validation. What is great about this approach?  It works at the whole business or product-line level, and you can also slim this down for use with A/B testing of enhancements too. Your level of application only depends upon your scope as well as the scale and maturity of your Agile efforts.  The more Agile your enterprise is the more leverage you can have with these techniques.

The result of this work allows you to determine, if there is desirability for this solution before you commit to ship it.  As a result of understanding the intersection of feasibility, effectiveness and desirability, you can be sure to deliver features that have maximum value.  And, by working with a minimal viable product (MVP) concept, you can be sure not to overbuild that solution too.  In this way you can be sure to build the features with maximum value and minimal long-term cost.

To me, Lean Startup is a method to drive continuous innovation and brutal, entrepreneurial prioritization. But taken to the extreme, Lean Startup is a way of being and acting and can become an attribute of culture. In addition to speaking and teaching on the topic, we have had some customers and partners come to learn, teach and do with us. The following efforts demonstrate how these activities can become cultural.

Act like a scientist, not a fire fighter

In a tradition of Lean companies, we had one of our largest customers come visit our office in early October.  He and his company have adopted and scaled Agile very well.  Now, they are focused on creating validated learning to do concurrent set-based development on their toughest problems. He pointed us toward this HBR Article on Decoding the DNA of the Toyota Production System.  You will notice the Lean rules and principles from Toyota support the Lean Startup approach.  This customer’s hope was to share his learning to help make us a better partner.  His trip was a true gift.  Thank you, Pat.

Two weeks prior to our customer visit, our friends George Kembel and Scott Dorsey, from Stanford’s d.school were here in Boulder. The principles and method of design thinking are clearly wrapped into the Lean Startup.  In design thinking, the iterations include practices to empathize, ideate, prototype, and test/reframe. Typically, these cycles are used to create the initial design of a new product or service, but not at the d.school. In the d.school, students take these concepts into more of a continuous cycle to help shape emerging services or social startups. Like Lean Startup, the d.school is learning to run people and teams through fast and continuous cycles of build-measure-test to create a “continuous innovation to create radically successful” efforts.

In a serendipitous way,  I taught a seminar on customer development and business model canvas approaches to fellows at the  Unreasonable Institute.  In September, Zach did a crash course on “Why Lean Startup Approaches Work” for 120 folks at the Silicon Flatiron’s portion CU Law School and Boulder/Denver New Tech Meetup.  Like my first post said, it has truly been Lean Startup everywhere at Rally.

If this post was not concrete enough for you, my final Lean Startup post is on “How to Apply Lean Startup to Your Agile Rollout.”

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.

Last week, in Copenhagen, I had my first ever taste of moose. I also had my first taste of cowberries.  Both different and tasty and new to my palate. And so I suppose you could say my palate matured a little as a result. That alone could have been enough to make for an interesting week. But what do moose and cowberries have to do (if anything) with my passion around Agile transformations

Several weeks ago, I posted about my pending Agile Europe Road Tour . In that post, I mentioned that I’d be on an Agile grand tour in Europe for 6 weeks. And so here I am. The trip started in London, moved to Copenhagen Denmark, Aarhus Denmark, back to Copenhagen, and then on to Stockholm where I am right now. I’ll soon have a brief trip to Estonia, back to Sweden in Malmo, and the a final stop in London as the punctuation of the tour before heading home to Boulder.

Lucky for me, the variety of Agile conversations has been delightful everywhere. At the Agile Business Conference in London, it was wonderful to bring my “Community of Thinkers” message as a keynote. (And yes, for those of you keeping score, I delivered it barefooted :-) The keynote afforded me opportunity to once again promote my conviction about our actions as an Agile community. That is, as Agile matures and as Agile transformations are going mainstream, we must invite dialogue, inquiry and artistry in how we bring our “genius selves” to the continued healthy growth of Agile.

At the GOTO conference in Aarhus, I suspected that the very technical community gathered there wouldn’t be powerfully driven by Agile conversations. And yet, there was a full day of an Agile track. In that track I talked about Simon Sinek’s  ”The Golden Circle: Tell Me Why” with regard to Agile Adoptions. (The talk received a nice write up in Danish here.) Both in this track and in my keynote the following day, I found people clearly eager to be transformative agents in their organizations based on their Agile passions. My keynote on “Complexity Theory and Design Thinking in Agile Adoptions” helped further these discussions and even invited several people to approach me afterward to talk about how they now understood they work they really wanted to do in Agile. They agreed. Agile was more than just a set of engineering practices and more than the Scrum framework; organizational Agile and its growth are now moving beyond just a level set with IT disciplines. And it wasn’t too shabby to get to play Pong using my Smartphone, or to watch the annual Lego Mindstorm competition!

Liv, Jean, Aino, and Helene - GOTO Aarhus Denmark

Another part of my GOTO positive experience were the great people of Trifork : tireless volunteers and selfless sponsors of GOTO throughout the organization including their energetic CTO Kresten Krab Thorup. I was grateful to meet so many Trifork people, to enjoy their enthusiasm, intellectual curiosity, passion and knowledge. In particular, it was such a pleasure to meet Aino Vonge Corry, Helene Simoni Thorup, Janne Jul Jensen, Liv Beswick Skov, Marlene Staunstrup Hyldborg, and Simon Hem Pedersen. Also from Trifork, Jesper Boeg was kind enough to provide me with a copy of his book on Kanban, as well as a book on Personal Effectiveness by his colleague Troels Richter. And Jasper Bjergard Arildslund sponsored me in speaking at a Copenhagen ScrumGroup gathering. Such great enthusiasm around Agile and its growth in software development communities worldwide.

But the pinnacle to date of discussions about complex challenging Agile transformations has been during my time at Rally’s Agile Open Forum in Copenhagen October 19th. Why? Because, in that day of tutorials and interactions, we engaged as a community of executives looking to bring Agile success out of the IT group. We created dialogue about the challenges organizations face when we move Agile upstream from the IT work into the business, and downstream into Agile practices for deployment and maintenance. Besides the session presenters from Rally (Ryan Martens in a surprise appearance, Karl Scotland, Wanda Marginean, and me) we were very fortunate to have the insights of Peter Holmelin of NetOp regarding his experiences in adopting Agile and creating significant organizational change.

I feel so fortunate to have engaged as a sponsor, a speaker and a participant in this event. In Copenhagen, During that one day, we concentrated on seeking the next level of maturity with regard to Agile practices  effective scaling, and organizational change. I loved it. The level of engagement and the variety of conversations were definitely different than any other Agile event I have attended in the past.

Karl Scotland - Agile Open Forum, Copenhagen Denmark

All in all, you might say that, as I have been on this tour, I see that the Agile community is primed to stretch the “knowledge discovery process” posited by David Anderson in his blog based on his application of Michael Kennedy’s work in Lean Enterprise guidance. In the discussions in London, Aarhus, Copenhagen and now Stockholm, we’ve been challenging ourselves to expand the definition of knowledge and the definition of discovery as Agile expands: when does the discovery begin, and when does it end (if ever)?

To that end, I’ve been listening to these leaders of large Agile adoptions. And I’ve heard the need to create greater understanding around the value and disciplines of Agile Portfolio Steering. (In fact, Wanda Marginean led a great afternoon session game on Enterprise Steering based on work by Rally colleagues Isaac Montgomery and Ronica Roth.)

Now I am in Stockholm. Thanks to a colleague from the LSSC community, Joakim Sunden of Spotify, I have been invited to a number of additional Agile events here. The level of discussions of Agile transformations continues to concentrate on organizational issues. I’m excited about my upcoming talk at the LESS2011 conference on Systems Perspectives in Agile Adoptions through Visioning and Learning Models.  I can’t wait to hear the participants’ experiences and challenges, to engage in all the interactions and, perhaps, to continue to expand my palate as well.

And so my Agile Europe Trip continues. As for my taste in food though, I know right now I won’t be tasting the specialty found on my dinner menu in Stockholm last week: “Långhalsar” in Swedish. Or if you prefer English: “Barnacles”. Gotta draw the line somewhere.

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

October and November for me are going to be months of travel. Specifically travel in Europe. I’m excited about the opportunity to bring my passions in and around the world of Agile to some great conferences in London, Aarhus, Copenhagen, Stockholm, and Malmo. So, I offer this video as view into where I’ll be, when I’ll be there, and what I’ll be talking about. As you’ll hear me say in the video, I hope to see you there!

For more information on the conferences:

Agile Business Conference, London UK

GOTO Conference, Aarhus Denmark

Oredev, Malmo, Sweden

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

As larger organizations are diving into using Agile methods, we hear a lot of questions about how teams integrate various specialities and skill distributions. One common question that is frequently asked by traditional UX departments is “How will our work and focus change?” Moving from traditional design practices to agile design practices is a big step and requires a significant shift in both thinking and approach.

Jeff Gothelf is the Director of User Experience at TheLadders.com and is at the fore-front of the Lean UX movement. Jeff is also active in the Lean Startup community and posts frequently to his blog and twitter (@jboogie).

I first ran across Jeff at a talk that he gave at the SXSW conference this past year called “Lean UX: Getting Out of the Deliverables Business.” Jeff’s talk was excellent, extremely well-received by the audience and heavily discussed across the Lean UX and Lean Startup communities for quite a while after the conference. I frequently send copies of his Smashing Magazine article (written to accompany the SXSW talk) when UX teams enquire about the shift to agile thinking.

In this post, Jeff shares his experience in addressing the top 3 reasons that designers initially object to agile and ways that we can help introduce alternative thinking to traditional practices.

———-

When first introduced to Agile thinking and processes, user experience designers often balk. Years of software projects and interactive agency-driven initiatives have built strong waterfall muscle memory. Successfully integrating these designers into Agile teams and, more importantly, Agile thinking requires allaying their most important concerns. The three objections below are not the only obstacles to Agile and UX integration but they are the biggest ones. I’ve provided ways to overcome these issues that have worked with my team at TheLadders. Succeed here and you’ve taken a significant step towards creating a higher-performing team.

Objection #1: No more BDUF
BDUF stands for Big Design Up Front. It is what’s known in the waterfall world as the “Design Phase” – a period of time that can last anywhere from a couple of weeks to a couple of months where designers can take the project’s requirements and ideate, at length, over how the solution will manifest in interactions and aesthetics. Designers will typically explore various workflow options, data collection tactics alongside aesthetic, layout and typographical treatments. Even with the addition of a Sprint 0, which allows designers one sprint to get “ahead” of the development team, BDUF vanishes. Designers new to Agile will protest that they are not given enough time to think about the solution and that in no way can they turn around a design in the given timeframe. This resistance alone can quickly kill the momentum of an Agile team.

To understand how to resolve this issue, we need to examine its root causes first. BDUF allows designers time to think about the entire experience the team is building. The expectation is that at the end of the design phase, the entire product is designed and spec’ed out. In addition, this is typically the first and last time the designer will get to spend a significant amount of time on the project so everything must also be right as there’s no (significant) going back.

When introducing Agile to designers, it is imperative to stress that they focus on only a sprint’s worth of design work. In fact, they should hesitate to design too far “ahead” of the development team as priorities may shift after each incremental release and that additional work may go unused. Focusing on a sprint’s worth of work dramatically reduces the workload for the designer. All of a sudden, turning around a much smaller amount of design work becomes much more realistic in the given timeframe.

Second, Agile is iterative. There will be another sprint and it will provide another opportunity to refine and build on the work currently being implemented. The waterfall designer’s mindset doesn’t expect that. The expectation is that the work will be launched never to be touched again. By convincing your designer that this is the first iteration of the implementation, that learnings will be collected and that subsequent iterations will give her opportunities to update, improve and resolve the UX you begin to alleviate the concern that a less-than-finished piece of design is released to customers.

Objection #2: Minimum Viable Product
Designers don’t design Minimum Viable Products. They design robust experiences that demonstrate years of training and skill. The idea of putting out an experience that is “good enough” is antithetical to a designer’s mindset. To her, it feels like half-assing the project.

“Yes, I can lay out a simple, grayscale grid that displays the data but with a few more days I can create color-coded representation of that same data complete with hover states and interactive menus.”

This is a variation on a common refrain from designers new to Agile thinking. The idea that each iteration is being used as an experiment to prove a hypothesis runs counter to the on-the-job training many designers receive at companies and agencies they’ve worked with in the past. In those scenarios, there was typically a “big idea” conceived by a high-ranking stakeholder and the team executed that idea to its fullest. There was no opportunity to get a lightweight version of the idea out, validate it’s potential and iterate from there. This is the true power of the MVP.

A good UX designer is well-aware of the benefits of customer research. Couch the MVP as just that – a way to ensure we’re meeting customer needs. What is the least amount of product we can design to prove this approach is valid or not? Using the MVP as a research tool puts it neatly within a familiar UX toolkit, demystifying it and increasing the designer’s level of comfort with the technique.

There’s a second challenge with the MVP – who gets to define what is minimally viable? In many organizations it’s the development team. In others it’s the product owner. As the responsible party for the User Experience, the designer wants a say in this decision. By including the designer in this decision, you, again, increase their comfort level with releasing what they feel is an incomplete product. Because they had a say in it, they can reconcile the experience in their minds as “complete enough” for this iteration.

Objection #3: Collaborating with non-designers
Agile espouses collaboration and conversation. Designers are comfortable with these tactics, as long as their collaborators are other designers. When asked to discuss their unfinished work with their teammates, defense systems are engaged. At the root of the problem is the designer’s sense of uniqueness and value derived from a belief that only designers can design. Hence, why should she consider the opinions of a software engineer regarding the informational hierarchy or layout of the page? This objection is exacerbated by the other two mentioned earlier. The lack of up front design team and a drive to release minimally viable experiences early on leads to what designers perceive as “unfinished” work. It’s one thing to show rough sketches (both literal and digital) to another designer but a non-designer will likely misunderstand it, provide feedback on the wrong elements and critique elements that aren’t fully baked.

To mitigate this, focus these conversations with non-designers more on functionality and feasibility rather than design elements. Review the rough work for the interactions and data requirements and set those expectations up front. Stress to your designer that discussing these directional sketches earlier in the process provides the developers with a better idea of what they’ll need to do, especially on the back-end, to bring this experience to life. If done well, these initial conversations will build a level of trust between designers and others on the team paving the way for more open discussion and the ultimate contribution of everyone to the design.

While there are other reasons designers struggle with Agile adoption, these three are the hairiest ones to overcome. Each one is a challenge and can take many months to get through. The mitigation tactics laid out in this article are techniques that have worked well for TheLadders. They are, by far, not the only way to bridge these gaps and bring teams closer together. What’s worked well for you? What other objections do you think should be on this list?

Ben Carey is an Agile Coach with Rally Software. You can find Ben on Twitter at @bencarey

Rally was founded shortly after the signing of the Agile Manifesto, the document created at a 2001 meeting of leading software developers at Snowbird, Utah, that gave rise to the Agile movement. Since then, Rally has taken what we’ve learned from leading countless enterprise Agile transformations and funneled our collective experience into a formula that includes our Agile ALM platform and products, our expert coaching services, a vast library of educational resources, and a supportive community for asking questions and sharing advice. In celebration of the 10-year anniversary of the signing of the Agile Manifesto, Rally had a special commemorative activity at the Agile2011 conference.

Bryce Widom, chalkboard artist and painter, joined us and literally drew, in real-time, the history of Agile. Rally team members and conference attendees collaborated on the stories that made up this “Road to Agility” starting with the Agile Manifesto, and continuing with important milestones such as Dr. Dobb’s Agile adoption survey, Forrester’s Agile ALM Wave report and the formation of the PMI’s Agile community of practice. Bryce also drew colorful stories that illustrated benefits of agility from companies like Betfair, John Deere and McKesson.

Announcements

The announcements we made at the conference are a culmination of Rally’s experience in helping organizations expand Agile practices to maximize value across the entire organization, along with strengthening support for multi-process development (check out these video interviews on SSQ’s blog to hear more). Our first announcement highlights Rally’s support for multi-process Agile. As Agile moves deeper into new functional areas, Rally’s Agile ALM platform, products and coaching services have been evolving to meet these diverse needs. When Scrum is not the best fit, we include support for other Agile methods such as Kanban and high-assurance methods to ensure that we can be the go-to partner for all enterprise Agile roll-outs. We announced:

• Enhanced Kanban support, including support for Class of Service highlighting and reporting. Read this product blog post for more details.
• Support for new customizable defect reports that support all processes.
• A new Iteration Summary Panel for Scrum teams that provides in-product coaching assistance. The panel guides teams based on their performance and offers coaching-authored best practices.
• Apps that support traceability and documentation in Rally within High Assurance organizations (check out this blog series on High Assurance Software Development).

Our second announcement signifies the bridging of Agile into the Project Management Office (PMO). In its 10th year, Agile’s mainstream appeal has broadened its reach from the technical to the business parts of the organization. We recognize the trend and are helping to ease the transition for all parties. We announced:

• Unmatched integrations with industry-leading Project and Portfolio Management (PPM) vendors like Oracle Primavera, CA Clarity, Daptiv, and Planisware.
• An update to Rally Idea Manager, the leading Agile ALM demand management solution. This release bolsters the integration with Rally and provides a new leaderboard to drive end-user engagement.
• Availability of a new Agile Portfolio Steering services offering. This offering represents the next frontier of Agile and includes an interactive simulation to facilitate collaboration between Agile teams and business stakeholders.

Field Guide

At Agile2010, we provided vuvuzelas in celebration of the World Cup and, while I’m sure that many of you annoyed your families with these, we decided to leave you with a lasting educational giveaway at Agile2011. We assembled a content guide written by our coaches on Agile best practices. We hope you find this field guide useful in your day-to-day activities – download your copy here.

Thanks to everyone who contributed to the “Road to Agility” illustration, whether you were at Agile2011 or were following our progress on Twitter, Facebook and Flickr. In addition to celebrating the 10-year anniversary of the Agile Manifesto with the community at Agile2011, Rally also embraced the opportunity to reflect on how much we’ve learned from helping some of the world’s largest organizations apply Agile practices. We look forward to making continued meaningful improvement in our industry, and leading the next 10 years of Agile innovation.

Todd Olson is VP of Product at Rally Software. He is a marathon runner and cake baker. Find Todd on Twitter at @tolson.

Ryan in the cockpit with Tim the ISG System Tester

The Intelligent Solutions Group at John Deere recently confirmed that they have been engaged in a large-scale Agile transformation since 2010. Chad Holdorf, Scaled Agile Coach at John Deere, has been sharing news about agile in his blog, Scaled Agile Delivery, since 2008. Chad’s blog is packed with useful information and fun videos including recent posts about Deere’s tool selection process and teaching Scrum with Legos. Deere’s Agile experience is also included in Dean Leffingwell’s new book Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise Requirements and on Dean’s blog.

At Rally, we are proud to be a part of John Deere’s successful Agile rollout, and I just retuned from a visit to Deere’s facility in Des Moines. I want to give a huge shout out to Chad and thank the entire ISG team for hosting me for two days. I especially want to thank them for letting me see their cool work in action. (see photos of ISG controllers steering the 8 wheeled tractor that I was driving!)  These guys are working hard on solutions that help us build more agile farming and construction solutions to help feed our growing planet.

On the trip, I got to ask Chad a few questions to highlight their blazingly fast rollout efforts.

1. When people think about John Deere, they likely picture big tractors, not software. Why Agile?

The Intelligent Solutions group designs the technology that runs our vehicles. This includes things like displays and receivers, guidance systems, field and crop management, and information and logistics systems. About a year ago, we were faced with a hard deadline for shipping a new display in a very short timeframe. It was a do or die situation. We knew then that what we had been doing wasn’t going to work for this effort. We really had no other choice but to go Agile then, and we’re still reaping the benefits now.

ISG video controllers in the tractor above

2. I know you made the deadline, but tell me more about getting 600 people to go Agile in a year?

We took an “all-in” approach. We wanted to get everyone on the same page right away, immerse them in training and Agile concepts and kick off our effort at once. Sure, it was a lot of heavy-lifting, but it really paid off when we saw the results. We moved a huge project through our pipeline in a third of the amount of time it would have taken otherwise.

3. So did the other shoe drop? How did people react to transformation? What’s different now?

We have smart, talented people. We knew that if could figure out how to get out of their way, we would improve. Since going Agile, we’ve seen huge buy-in and ownership from the teams. They have embraced the collaboration, creating team names, ribbon-cutting ceremonies and even mascots. Physical spaces have also changed. Walls have come down and work spaces are more physically open and collaborative. It’s all part of letting people do the right things. For the first time ever, we didn’t have anyone working over Thanksgiving or Christmas — and that’s even with a big end-of-year deadline. Efficiency has been huge. What would have taken us two months before, now we deliver in two weeks. I figure if John Deere can test working software every two weeks on a tractor in a field, then Agile will work anywhere.

4. You have told me about your “OSM,” can you share more with others about this key event?

After our release planning, we have an “Oh $%it Meeting.” We use that meeting to help give visibility to and cover all the contingencies and gotchas. We’ve found that it helps to refine our next iteration and make sure that we have covered everything and are ready to start the iteration.

5. I look forward to my visit this month, but give me a heads-up; What’s your next mountain to climb?

We have a few. We’re always measuring our success to make sure we’re delivering what the business needs. We’re also working to keep learning and growing our technical understanding and to encourage a culture of innovation by empowering our people to get their ideas on the table. It’s really about continually working to assess our efforts and understand how we can improve. We’ve had a great deal of success, but we’re always looking to get better.

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

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 2001, the Agile Manifesto was created with 17 signatories from around the world. Following on the heels of the first XP conference in Sardinia in 2000, the Manifesto fired its shot of agility across the Waterfall bow. A year later, at XP/Agile Universe 2002, I found myself standing at a folding table with Janet Danforth of Facilitator4Hire. We were selling facilitation services to the members of the Agile community gathered at a Courtyard by Marriott in Lincolnshire, Illinois. Approximately 80-100 people had come together in that steamy summer venue to continue Agile discussions and to define ongoing growth of methodologies, practices and frameworks.

Where we were

At the same time I was at my folding table in Lincolnshire in 2002, Ryan Martens was at a whiteboard in Boulder, Colorado. Ryan was brainstorming ideas about how he could use Agile practices to create a Software as a Service platform in the Agile domain. His goal? To provide zero-waste, low-carbon emissions applications and services for this growing, vibrant community.

In 2003, the Agile community gathered in Salt Lake City for the Agile Development Conference. This was my first time presenting at an Agile conference. Janet Danforth and I conducted a workshop: Collaboration 4 Agile Projects. And, unbeknownst to me, Ryan was also in Salt Lake City for his first Agile conference. As Ryan was busy engaging vendors about how they were supporting the adoption of Agile, I was busy networking with Agile thought leaders and helping to found “The Freaking Flock” (you’ll have to ask me about that in person!) Our paths were set and Agile was on the move.

Fast Forward to 2011

Now, in 2011, we are 10 years on from the Manifesto signing, 9 years on from the first sighting of me at the folding table, and 8 years on from Ryan’s first foray into the conference.

The Agile 2011 conference is an exciting one for both Agile and Rally. We are pleased once again to be a Title Sponsor of the conference. This year, August 8-12, Rally has 11 speaking sessions on the wonderfully vast and diverse program.

• Jean Tabaka and Julie Chickering: Enterprise Agile Visioning and Learning
• Aaron Sanders and Carlton Nettleton: There’s an Agile Game for that
• Karl Scotland: Dr W. Edwards Deming’s Famous Red Bead Experiment – For Software Teams
• Ken Clyne and Eric Willeke: Putting the Fun Back in Your Retrospectives
• Aaron Sanders: Ten Tales of Positive Change
• Ken Clyne and Julie Chickering: Risk Management Game
• Karl Scotland and Eric Willeke: Flow Games
• Jean Tabaka: Tell me Why: The Golden Circle of Agile Transformation
• Steve Adolph and Philippe Kruchten: Reconciling Perspectives: How People Manage the Process of Software Development
• Shane Hastie and Steve Adolph: Agile Thinking for Business Analysis-Going Beyond User Stories
• Karl Scotland: Designing a Kanban System for the Enterprise

We’ve also participated behind the scenes in advance of the conference as producers, co-producers and reviewers for various conference stages. And, once again, we’ll have a booth where you can come to meet our Agile coaches, talk with our technical gurus, and see the latest that is happening with Rally’s Agile ALM platform and services. Plus, you won’t want to miss our special commemorative activity at the booth this year. Stay tuned to the blog and follow our Twitter hashtag #roadtoagility for more details on how you can participate with us!

Going back to my history of Agile and Rally and the conferences

Ryan and I never met at the 2003 conference. But in 2004, as the conference moved into the northern Rockies in Calgary, Alberta, 4 of us stood together at a folding table in a small hallway. Rally’s representation at that Agile conference was Ryan as President of the company, Richard Leavitt as our VP of Marketing and Sales, Brad Norris as our sole sales person, and me as the sole Agile Coach. At that point, none of us were speakers. However, Rally has had one or more speakers at each conference since: Denver in 2005, Minneapolis in 2006, Washington DC in 2007, Toronto in 2008, Chicago in 2009, and the 2010 event in Orlando. Additionally, Ryan served on the Agile Alliance board during the years of the Washington D.C. and Toronto conferences.

From the folding table to now

Some things have changed in Rally’s Agile journey. We’ve grown from a 20-person company in 2004 to over 250 people and counting. Ryan is now the head of the office of the CTO. Richard is now the Executive Vice President of Worldwide Marketing. Brad is our Vice President of Field Operations. And I am an Agile Fellow in the Office of the CTO.

From a Manifesto, a whiteboard, folding tables, and a single speaker to title sponsorship with multiple speakers, producers, reviewers, and booth presence in a true exhibit hall at a conference with over 1,600 attendees, we’ve indeed come a long way!

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.