Agile Development Blog

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.

• Strategy Meets Execution web site - Learn about the full solution, including Rally Portfolio Manager, Agile Portfolio Steering Workshop and educational resources.
• IDC case study – Pay special attention to the great case study written by Melinda Ballou that highlights the work of Nina Schoen and her team at Getty Images on getting alignment through Kanban portfolios. Nina spoke about her real-life experiences at this morning’s Bay Area event.
• Press releases – Check out the Agile Portfolio Management press release, and also another announcement made today on our new board members Tim Wolf and Mark Carges.

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.

This post has been a long time coming. I’ve started and restarted it at least a half-dozen times.

Quality – there may be no more multi-faceted and powerful attribute in successful software development. Quality is central to everything we do and seek.

• Higher quality leads to greater productivity, throughput and velocity
• Higher quality leads to increased responsiveness, reduced cycle-times, shorter lead-times
• Higher quality leads to improved customer satisfaction, employee satisfaction
• Higher quality leads to better predictability, reduced risk, improved decision making

Or at least that’s my hypothesis…

And that hypothesis is widely shared amongst the Agile and product development communities.  We’ve developed numerous principles, practices and techniques intended to improve quality:  Test Driven Development; Continuous Integration; Automated Build and Deploy; Pair Programming; Customer Demos; Behavior Driven Development; Acceptance Test Driven Development; and Set-based Design techniques are all at least partially focused on yielding quality improvements.

But quality can’t simply be viewed as a set of tools and techniques – independent variables/levers which we hypothesize will lead to improved business outcomes. Quality is also a business outcome unto itself.

This series emphasizes the need to focus on business outcomes (success) first – methods and practices second.  So, putting aside the methods and good practice assumptions of Agile, and focusing solely on the business outcome of improved quality:

Quality = Fewer Defects in Production

We apply Agile quality practices and techniques, because we believe that doing so will yield improved business outcomes – quality (fewer defects in production) being one of those outcomes – along with productivity, predictability, responsiveness, customer and employee satisfaction.

Large, manual, end-of-cycle execution of formal testing by an independent QA organization is also a method aimed at improving these business outcomes. I hypothesize that it is less effective than alternative Agile techniques. But I don’t take that on faith, and neither should you. We must test our hypothesis.

How Do We Measure Quality?

There are innumerable quality metrics that have been devised over the years – each with its own strengths and weaknesses.  In my experience, it’s important to keep metrics simple, and to not let great become the enemy of good enough. In other words, if you have a metric that does a good job of providing insight into the quality of your product/solution, and is simple to collect and interpret; that is likely better than chasing after a metric that will do a great job, but would be more complicated.

For my part, I’ve had success over the years using a couple relatively simple metrics:

• DEFECT DENSITY – # Defects / KLOC
• DEFECT ARRIVAL – # Defects Identified / Month

What Do We Consider a Defect?

In both cases, I include only defects in the production system.

Measuring defects found and eliminated during the development cycle may be useful for managing your development and quality processes.  But from a business outcomes perspective, our focus is reducing the number of defects that make it to production – not making assumptions about how or when to achieve that.

Not All Defects Are Created Equal

Any good metric should drive in more questions than answers.  I find it useful to tag defects with information about type and severity, so that we can consider some of those questions more deeply.

• Our defect density is high; but our severity 1 & 2 density is low. What is the impact on other outcomes (productivity, customer satisfaction, etc.) if we were to invest in reducing our low severity defects?
• Our defect arrival is very high immediately following a major release. But the defects are mostly Type = Usability. Why are our customers having such a tough time using our new features; and how can we ease them through the learning curve?

You may have some hypotheses based on these questions. Perhaps those hypotheses involve application or improved use of Agile tools and techniques. What experiments would you run to prove or disprove your hypothesis?  What new questions will those results yield?

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

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

With the publishing of Eric Ries’ book, The Lean Startup, I can barely go a day without talking to someone about it. Eric clearly executed a lean startup on himself and this topic – by focusing on learning. Eric started much of his work a couple of years ago with his blog Startup Lessons Learned and by publicly speaking on the topic. I saw him first at Return Path, a local Rally customer, in May of 2010.  Since that time, he has continued to refine the principles and collected great stories for this book that speaks equally well to an new entrepreneur as a seasoned business professional.

The book is just a fantastic and hard-hitting summary of this approach to business, as well as a manual on how to teach entrepreneurial behaviors.  If Eric was a seasoned author, this would be a great book, but given the fact it is his first effort – it makes the book astonishing.  It debuted at #2 on New York Times Bestseller list!

If you do not know Eric or The Lean Startup model, it works by developing product/service in parallel with the customer in a market.  The method can be summarized by three words executed repeatedly; Build, Measure, Learn.  These cycles continue to help you assess whether to stay the course, pivot or stop.  The Lean Startup is a combination of applying Agile Development, and Customer Development methods, but draws on Lean, crowd sourcing/social and complexity to create a true collection of thinking and acting tools for today’s complex world.

Eric’s sub title really sums the book up well –

How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses

… as these ideas and thinking apply equally as well for venture-backed tech startup, impact investing, social startups or internally funded intrapreneuring efforts.  If you read his blog, you will see he A/B tested about 20 sub-titles to come to this one. So, not only is a great sub-title, but it is one that attracts the right market.

Have you clicked on the book image to buy it yet?  No?  Let me try one more thing!

For Agile teams, programs or enterprises, the message from this book should be clear: you need to start applying customer development approaches to the front-end of your Agile efforts. You can read about Rally’s latest customer development in the Making of Project Stratus; and you can see the results of these efforts at our Agile Portfolio Management launch in December.

As part of this launch effort, Zach Nies and I have been given a great gift in the last month of continuous lean startup (more on that in later posts). Last week, I found out that Zach and I will have the opportunity to interview Eric live on February 2^nd.  If you don’t buy the book, you should at least register for the 1 hour video event.

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

In summer, the Entrepreneurial Thought Leaders series at Stanford released their video podcast with Geoffrey Moore on his new book “Escape Velocity” As soon as we saw it, I contacted Geoffrey to see if I could get an early copy of the book. Geoffrey was very happy to share and subsequently talk to me about how Rally could help promote this great new book and web site, Escape Velocity, which launches today.

I highly recommend the book, buy it today, and see the video. As you can see from my collections of his books, I love his work. His command of English and simple models always makes reading his books a real pleasure. I got “Crossing the Chasm,” when I was in school as an engineer back in the 1980′s.  I enjoyed working with him and The Chasm Group back in 2000 while I was at BEA. But, now this newest book has hit while Rally is working with customers that struggle with escaping the “pull” of the past. As Geoffrey describes, this is “A better vocabulary to talk about power versus performance.” I see many customers describing why they invest in Rally – to transform their execution and offer power.

As a result, this book is not just interesting for product management, but for the executives in engineering, marketing and sales, as well as the whole executive team. Because my team was so excited about this book, we were able to get our marketing team excited too. I am thrilled to announce that Zach and I will be interview Geoffrey live on September 22nd. Please consider joining us for this webinar.

Now to helping us make this interview work for you. Zach and I are going to run this interview based on our understanding of this book and our experiences, but we are also very interested in your questions. We will support chat and Twitter during the webinar, but your comments on this post would be even more appreciated. Here are some of the our draft questions:

• Most Agile development teams have fixed the execution power level – what is next and why?
• I have read all your books – can you reflect on this book in relationship to past works? Is the really the capstone?
• For a recent graduated from college, what order would you have him read your books?
• Do you assume engineering needs to be Agile to pull off this approach?
• You mention it’s important to separate differentiation, neutralization and optimization efforts, why?

What is top of mind on this topic for you?

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

Zach Nies is the co-CTO at Rally Software and passionate about building successful software products and a proud member of the Boulder/Denver Agile community for the last ten years. You can follow him on Twitter @ZachNies.

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

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