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
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.
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:
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.
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?
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.
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.
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.
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.
Writing or receiving a break-up letter can be fairly daunting or shattering, depending on which end of the letter your name appears. That letter puts a pretty hard stop to a relationship. It’s communicating detachment and finality. It can create a lot of pain whether intended or not. In contrast, a love letter is uplifting. The endorphins fly! Someone is revealing their attraction for you, and their hopes and wishes for a future with you.
Now, there is a reason I have these letters on my mind. I’ve just returned from Rally’s Agile Leadership Forum – a great gathering of people eager to lead successful Agile transitions in their organizations. The event included a lively presentation from Forrester Research’s Senior Analyst Dave West: “Agile Adoption – Research Findings on the Adoption of Agile.” (You can find some of Dave’s data in the “Forrester Wave: Agile Development Management Tools, Q2 2010″). We also enjoyed an inspirational talk from our CTO Ryan Martens, called “Moving Agile Beyond Software.” These great presentations were followed by breakout sessions and a panel discussion about Agile challenges. Now, how to end the event?
As emcee of the forum, I not only kicked off the event, but it was my job to bring closure to the gathering as well. How can we have people walk away with thoughts about Agile? Why are they interested in the first place, and where do their concerns lie? I was inspired by a video I recently saw about “breakup letters.” The Breakup Letter is a design research tool that Smart Design uses to understand the emotional connection between people and their products, services, and experiences. One person broke up with his cell phone, another, her single-cup coffee maker.
Now, just how does this relate to the Agile Leadership Forum? I liked the concept of the breakup letter, but I decided to entirely flip the idea and close the event by asking everyone to write love letters instead. In the spirit of Cyrano de Bergerac, I asked each table of participants to work together in crafting a “Dear Agile” letter. In this letter, they were to convey their attraction to Agile. And, they were to reveal where they were concerned about as well. All letters were to be from a secret admirer :-)
Once the groups began to read their letters, I knew we were on to something. Though I don’t have the reading of the letters on video, here are a few examples of our “Dear Agile” love letters.
Run this exercise in your own group to find out what the Agile “lure” looks like and also what the “turn-offs” might be.
Breathlessly awaiting your comments,
Jean
p.s. If you want to read some of the transcribed texts of the love letters, read on!
__________________________
Dear Agile,
I have admired you from a distance for some time. Waterfall and I are in the process of an ugly breakup. There is so much about you I need to know. My friend says great things about you. You are so simple and straightforward– no mind games like Waterfall.
This won’t be simple. Waterfall still has clothes at my place. My Facebook status is confused.
In the relationship as we get to know one another, we will have to know each other carefully– co-locating right away? Are we sprinting too fast?
Be gentle with me.
Looking forward to a rapidly developing future.
xoxoxo,
Secret Admirer
__________________________
Dear Agile,
I love you because you offer quick cycles, better quality, and better teamwork. From the first time I saw you, I thought I could begin saving money and add business value.
But, fair Agile, you are not so simple. I’ve heard you are a micro-manager. I don’t totally understand you. Some people are confused by you. On the surface, you sound so perfect and simple, but the more I get to know you the more questions I have.
But, among all my choices, I choose you. You promote collaboration, and allow me to turn things around quickly. You’ve helped me trim weight and stay lean. Don’t disappointment me, I trust you!
With all my love,
Megedá
___________________________
Dear Agile,
I loved you from the first moment I saw you, I loved your fast, speedy releases and that you don’t come with a lot of baggage or documentation. You’re simple and down to earth. You are a great communicator. I always know where you are and my friends love you, too.
I am, however, a bit concerned that not everyone accepts our relationship. I am worried that as my job continually grows and my needs scale up, whether you can handle the increasing challenges. And I’m concerned whether I can afford you… Our relationship and your attachments are what intrigue me the most.
Looking forward to spending more time with you and getting to know you better. – Your secret admirer.
___________________________
Dear Agile,
We love you, we think you are awesome – for the following (bulleted) reasons:
Agile accepts changes and encourages frequent changes
Agile can start implementation before full requirements are known.
We do however have a few problems with you agile –
I have always answered the question “Where does Agile not work?” with the answer: “We have customers in all forms, geographies, and technologies working in Agile. It works everywhere!“
Of course that is my Agile Convert persona coming screaming through…
In his article “Agile Processes Go Lean” on the Dr. Dobbs portal, Forrester analyst Dave West does a great job illustrating the true challenges and roadblocks in successful Agile adoption beyond the team. His research across numerous sources, collaboration with Tom Grant and ability to synthesize these concepts makes this article a must-read for executives in software development organizations.
Dave sums it up nicely:
“The problems, broadly, tend to be technical, cultural, or organizational. Technical problems relate to infrastructure, tools, and architecture, and are often the most visible of the changes involved. But many companies find the cultural and organizational issues are the hardest to resolve.”
“When a development organization uses the approach to transform itself, it often runs into problems with other parts of the company that haven’t undergone similar transformations. Clashes come with the business operations, governance, and organizational structures, among other areas. For example, hierarchical organizations may struggle with agile development’s quick, iterative review cycles and decision making.”
In the past few months, I’ve talked with Dave and Tom about the opportunities and success of large-scale and successful Agile adoptions (beyond single teams and beyond simple flow) using examples from our customers and even our own internal processes. I’m excited to see analysts tackle the meaty topic of scaling Agile and Lean with real data and customer stories.
Jean and I made a commitment this quarter to go deep on Lean software development. We have been working with Lean and Agile for years, and really want to engage you in a dialogue to help explore the topic of how they relate.
Jared from Subway on his exploration of a different type of "lean"
To help focus our research, tell us, what are your favorite resources for Lean and Agile?
I don’t want to bias your feedback too much, so here are a few of our current favorite resources as a jumping off point:
Lean.org – Jim Womack’s site about Lean across industries
DW – Dave West from Forrester RAM – Ryan Martens from Rally
To work with the business to become Lean, who is an effective champion? Who is an ineffective champion?
DW – Lean businesses have to come from the business. I have seen effective leadership in many places, but always in the business. This might be a Business Unit or a division or it might be across the whole company – But the change needs to come from the business and be expressed in their terms.
RAM – Nothing to add here.
Do groups/departments/teams outside dev typically resist the adoption of Lean activity because of the perception of “loss of control” or authority?
DW – It is true to say that change is always difficult and that any change to undermine the existing power structures in an organization is a problem. I have seen successful implementation of Lean thinking in the following situations. Firstly, there needs to be a reason to change. At the organizational level that can be market forces, cost, and competition. At the BU or project level, failed projects or new products are always a good lead in. Add to the reason a clear plan around the change where power and career are considered. Answer questions like ‘what does this change mean to x ?’
In general the adoption of Lean thinking makes sense, but even if people see the value if it adversely affects them, it is hard to get buy in. Make sure it does not !!
At Rally, we often get questions about how Agile fits in with a variety of other practices and processes, so the below questions about Agile and CMMI, Agile and RUP, and Agile and Architecture come as no surprise. Stay tuned for the final Q&A on Agile champions.
DW – is Dave West from Forrester
RAM – is Ryan Martens from Rally
How can Agile be integrated in a CMMI certified application in regards to the tremendous amounts of required CMMI artifacts (documentation)?
DW – The flippant answer is it can’t. ☺ But actually I have seen some great systems integrators use CMMI to help check list their processes of which some of those processes are Agile. Agile development works really well at the team level, but it needs to be surrounded with other processes. CMMI makes sure you remember those processes, some of which are inside the Agile team, others are not. The PA’s always seem to imply lots of documentation, but they do not have. You can keep the documentation to a minimum, but still deliver them. Do not, however, burden the Agile team with proving their compliance – Use the checklist, build the software and get others to prove they did what they said they did.
RAM – I am not quite as negative as Dave on this topic. CMMI and Agile combine just fine. There are a number of proof points that are easily found from past Agile conferences and by searching “Agile and CMMI.” The problem is that many folk misinterpret CMMI and are convinced that it mandates waterfall, heavy process and heavy documentation. According to SEI, it does not. Most teams would not adopt CMMI without a specific business need.
We received lots of great questions and shared them with the webinar attendees, but thought they would also be valuable to other Agile practitioners. This first series of questions tackle the obstacles of adopting Agile. Stay tuned for the remaining questions in later posts.
What are the biggest blockers you see to good Agile?
DW – My pet peeves are people that resist change without really thinking about it. That treat software like car production and think that you can plan, deliver in that manner. These same people often lament the ability of the software teams to deliver good code at the right price. Software is a fundamental part of business change – If you need a new part to your business it will most likely require software, which may require development and integration. Connecting up their development with the people who have the problem is the first step to success, empowering teams to try new things and question the status quo in support of those business needs is key. Organizations that put artificial walls between the problem and the solution are the biggest blockers. These may come in the form of planning processes, business access, travel budgets, governance models, standards or culture.
RAM – Good Agile development is a mindset change like Dave is describing above. Overly aggressive or passive plans are the biggest blockers to “good Agile.” You need to think about this change as incremental and iterative with a strong focus on continuous improvement and learning through inspect and adapt feedback loops.
In this week’s webinar, I am going to share a set of models that I keep being asked about. These slides show the changes that happen in the enterprise stage gate model as your Agile adoption moves up and matures in the organization. To hear the explanation behind these slides and see Dave West’s work on Lean, please join us on the webinar. The full slide deck will be available after the webinar.
Not to steal all of my thunder, but there are two things that interesting about this transition.
The Agile stage gates of 3.1/4.1 actually provide more governance control than the old gates.
The first and last gate are not going away in large organizations anytime soon. You just don’t start projects without budget and you do not make a gold master for production without blessing from operations or overall system testing.
Lastly, Dave’s observations about how these stage gate models require a Lean organization approach, should make for a great conversation. I hope you will join us.
Several weeks ago, in an interview with Dave West of Forrester Research, Dave posed a provocative question to me.
“Do you have to be smart to do Agile?”
In retrospect, Dave’s question reminded me of an old joke: “Have you stopped beating your wife?“ In this “deeply philosophical” question, there is really no good answer. “Yes” looks bad; “No” looks worse. Answering the question about Agile and smartness could be the same. For me to answer “Yes” could be interpreted as, “Gee of course; look how brilliant I am!” To answer “No” could be interpreted as, “Gee of course not! Look at me! I’m as dumb as a doorknob!“
All jokes aside, I answered “No,” to Dave’s question and here is why.
The real question is not about individuals. The real question is, “Do Agile TEAMS have to be smart?” And to that question, I would answer “Yes.“
Agile relies on the collective wisdom of the team, not on the brilliance of one individual. I learned a lot about this, not just in my research of Katzenbach and Smith’s The Wisdom of Teams. I also have experienced it in the variety of teams in which I have worked and with the teams I have mentored. High team E.Q. (emotional quotient) is what makes Agile really hum. In fact, high team collaboration, their ability to invite and manage conflict, and their ability to create consensus, actually is the fiber that weaves the cloth of a high-performance team. High-performance teams have a collective high goal for which they hold themselves mutually accountable. It is about the team and its commitment to one another and their goal.
So, back to our title math question.
7 + 2 = 5 if your team mistakes collaboration as working in a “dumb down” or “group think” mode. That is not the intent of Agile collaboration or consensus. We’re an Agile team because we intend to increase our collective wisdom.
7 +2 = 9if you are not gathering all the insights of all the team members to inform your decisions in your work. You are not quite yet truly Agile.
7 + 2 = 11 is where the collective wisdom of the Agile team raises its team I.Q. That is, the Agile whole team is indeed greater than the sum of its parts. And besides, as Spinal Tap says, it’s great to, “Go to 11!”
RallyDev.com
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. 
depending on which end of the letter your name appears. That letter puts a pretty hard stop to a relationship. It’s communicating detachment and finality. It can create a lot of pain whether intended or not. In contrast, a love letter is uplifting. The endorphins fly! Someone is revealing their attraction for you, and their hopes and wishes for a future with you.
the archive of this webinar as well as the other webinar in the series, 
