Agile Development Blog

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, Zach and I enjoyed the incredible opportunity of engaging in a video interview with Geoffrey Moore on his new book, Escape Velocity.  First things first, for those of you who didn’t attend live, the archived webinar and slides are now available.

The book really hit home for me because, at its core, its really all about steering the Agile business. It provides both the new portfolio models and the specific stories for executives, as well as Product and Development teams to escape the “pull” of the past successes and set yourself up for the next success.  Specifically for development teams making the transition to a more Agile execution model, Geoffrey describes ways to work the budget/portfolio process to invest in the further development of the companies crown jewels.  With this kind of strategic investment, you can work to create your unmatchable offer power that wins customer market while increasing company power necessary to become a top tier play in your category. Geoffrey really connected the topics from the book with his perspective on the value of Agile development:

“Agile puts you in the problem state with the end user, live in that problem state and drive backwards on how to get there.  If there is an opportunity for a breakthrough, you will find it before anyone else does.” – Geoffrey Moore

Take the next step
I highly recommend buying the book, if you haven’t already.  In addition to standard e-book, hardcover and audible versions of the book, Geoffrey has released a real innovations for his new and 20 year fans. With Escape Velocity, he created an enhanced ebook on Amazon with embedded videos and an enhanced ebook for the Ipad/Ibook with links back into past books and models. There is now one source for everything Moore!
Geoffrey’s book has specific strategies for transforming vision and strategy.  These strategies should be easier for Agile teams that can support fast learning. If  however you are looking to first transform execution power to enable your escape velocity, don’t miss some of our great content to support your Agile adoption:

• If you currently use Agile at the team or multi-team level or are brand-new to these concepts, share one of our online Agile toolkits with your team:
  • Iteration Planning Toolkit
  • User Stories Toolkit
  • Multi-team Release Planning Toolkit
  • Project Managers Toolkit
• If you want more education in this webinar format, sign up for our ongoing Agile Webinar Series. Our next topic is Agile in High Assurance Environments, led by author and methodologist Dean Leffingwell and our own Craig Langenfeld.
• If you want to make the case for Agile development in your organization and learn why it’s becoming the norm, get the Forrester report on Agile development trends and tools.

Please let us know what you thought of the webinar by commenting on this post.

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

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 a part of our series on Scaling Agile to the Strategic Level, I have invited our product lead on this project, Catherine Connor, to tell us about her experience in creating Project Stratus. Thank you for the great work and help on this series Catherine.

Project Stratus was conceived over a year ago from numerous customer discovery interviews geared at understanding the challenges of strategic planning with agile execution. From these interviews we started to form an idea of what an agile strategic planning tool could look like, but we also knew that we would need to do serious customer validation before getting to productize a solution.

We’d already selected a disciplined approach to customer validation based on The Four Steps to the Epiphany – Successful Strategies for Products that Win by Steven Blank. Although the book focuses on startups, many of the ideas, such as diligently conducting customer validation and creating a sales roadmap (i.e. a repeatable process to sell your product) can also be applied to new products in existing compagnies. The basic premise of Blank’s approach is that if you solve a problem for customers (called “earlyvangelists”) who are so acutely affected by that problem that they are willing to build a solution themselves, you are more likely to deliver a product that will solve that same problem for many more customers.

Four Steps to the Epiphany © Steven G. Blank

Project Stratus was drastically accelerated in April 2010 at the LeanSSC conference in Atlanta, when one of our customers unveiled the agile product portfolio scheduler application they’d built to solve their own strategic planning needs. Not only did the application visualize where we were heading, it also happened to be built on the Rally Platform. We’d just found our first earlyvangelist.

Four months later, at Agile2010, we privately introduced Project Stratus to a handful of industry analysts and customers to gauge their reaction. Based on their overwhelming excitement, we proceeded in identifying additional earlyvangelists from past customer interactions. An earlyvangelist is like a P1 defect, when you find one, you know right away. These customers are so excited to see a provider like Rally think up a commercially supported solution to the problem they have been trying to solve themselves, they are anxious to guide you, and some are even irritated by the fact that the product is not out yet; when all along we’ve been thinking not to deliver such a thing! I could tell when I first engaged with Paul, Dale, Nina, Christophe and others, that they would be partners in shaping Project Stratus to become a valuable product. The beauty of Blank’s technique is in its reciprocity. We, the solution provider, get to build a product that solves real needs, earlyvangelists get to shape a supported solution to replace their manual solution, and customers get to benefit from their peers’ expertise.

With earlyvangelists on hand, we sat down to define the set of hypotheses to validate. This is an important step to ensure that interviews provide meaningful outcomes. Nothing is more deflating than spending an hour with a customer only to find yourself with no good answer to “exactly what did I learn from this call?” Listing hypotheses is also a great way to communicate to yourself and others in your company what you are trying to find out and what you are purposefully setting aside for another time. This is very much like “theory-based decision making”, one of Rally’s corporate core values.

Since August, we have been incrementally evolving Stratus, one weekly build at a time, diligently validating our hypotheses one at a time.  Earlyvangelists’ real-life experiences combined with our coaches yearning to apply agile and lean principles to the strategic level are informing the direction of Stratus. I feel really good about where Stratus is going.

As an agile product manager who has seen several projects being productized prematurely, I am truly enjoying following Blank’s rigorous Customer Development approach and definitely would recommend it to my product manager comrades. You do need executive support which thankfully Rally provides me. Following Blank’s technique is no small feat however, it is hard and diligent work with no guaranteed productization plans until you pass his customer validation final exam: “you have proven you have understood customer problems, found a set of earlyvangelists and delivered a product that customers want to buy, developed a repeatable and scalable sales process and demonstrated you have a profitable business model.”  Then, and only then, will we graduate to Blank’s customer creation step, aka the delivery of an official Rally offering for Strategic Planning.

The customer validation step for Project Stratus is going full steam. We welcome more earlyvangelists to partner with us in this exciting endeavor. The more input we receive, the more valuable the product will be. If you have strategic planning challenges and a passion for applying agile principles for solving them, I invite you to reach out to us at stratus@rallydev.com. – Catherine Connor

The work done by Steve Blank on this method is fantastic. In addition to Project Stratus, I have used it with our large on-premise customers and with TechStars companies in order to keep from leaping to conclusions and trying to by-pass the customer creation stage. I hope many of you can empathize with the discipline required to do both of these things in the world of product development.

Ryan Martens is an Epic Pass holder for 2010, a school board member at Friends’ School Boulder and CTO at Rally Software Development.

Catherine Connor is a Product Manager at Rally Software Development. She focuses on the product manager role in our customers’ agile transformation endeavors.

Brad Murphy, CEO of Gear Stream, gave a keynote presentation at last week’s Agile Success Tour. Brad’s vision includes helping organizations transition from project-driven governance to Lean, continuous flow, product line execution. We sat down with Brad to ask him 5 questions about Agile.

1. What’s the most valuable thing you’ve learned by helping organizations adopt Agile practices?

The dynamics surrounding the adoption of Agile practices are changing in ways that are very different from even two or three years ago. In parallel with implementing Agile practices and establishing effective Agile teams, we’re helping organizations connect Agile philosophies and values to vital stakeholder groups. We’ve recognized that actively involving all stakeholders early in the process is key to ensuring that core Agile teams are able to achieve expected results. Gaining the support of all collaborators in the organization dramatically helps core Agile teams successfully transform and deliver outcomes. Involving the following stakeholders is vital, including:

• The core Agile team
• Tooling, Infrastructure and Release Management – the architecture side of the equation.
• Governance and PMO groups – more than half the time, this group builds the roles of the project managers, Agile teams and the Scrum Master. They consider how Agile teams work off backlogs. There’s huge potential for misalignment here.
• Product Management – since this is frequently a group that doesn’t exist, the responsibilities here aren’t well defined. Loosely, I’ll describe this as a group of individuals responsible for defining business value. This group has to be aligned with the way Agile works.
• Executive Management – all of the focus on Agile change with the groups listed above must be explicitly aligned with the strategy and values articulated by senior executives. Too often, Agile is pursued based on “generic” benefits like speed, responsiveness, quality… while these are “good,” they’re not explicit enough.  We must challenge executives to express exactly how they will measure/recognize their own corporate goals and then map these back to the things we choose to emphasize in an Agile transformation.

Responsiveness would be #1. Having the ability to course-correct and change directions quickly in light of new mandates and directions. A close #2 is innovation.  A distant #3 is productivity.

Gear Stream’s clients are realizing compelling organizational realignment by refocusing the entire value chain on external customers, as opposed to the often dysfunctional inward focus of many organizations.  By aligning the entire value chain on external customers, our clients are able to more predictably influence customer satisfaction and marketshare objectives.

I’ll give the advice I’m most passionate about. Agile teams need to challenge the rest of the organization to rethink and reconsider how work happens up and down-stream to them in order to fully exploit what they’re capable of achieving. It’s really about how Agile teams can actively promote, influence and change an organization beyond just what they do as a team. They really can – and do – influence and engage the rest of the organization. The failure pattern of Agile is almost always the same: we’ve built an Agile team, but failed to build the adjacent stakeholder teams in the process – then, the Agile team gets frustrated and the organization loses momentum and enthusiasm for Agile. Agile teams must have the ability to influence stakeholder teams, and ultimately, the baseline infrastructure of the entire organization.

5. How do you define Agile success? (Can you do it in 113 characters?)

Building, delivering & sustaining outcomes that customers r continually thrilled by, driving profit & value 4 all

I’m traveling this week to Rally’s Agile Success Tour in San Diego.  I love attending these events because they’re a lot of fun and participants seem to get a lot of value – getting out of the office for a half day is a great way to learn and think about how you can get started or get better with Agile.  Plus, the Rancho Bernardo Inn is pretty nice place to spend a day.

The site of Rally's Agile Success Tour - the Rancho Bernardo Inn

But my day job is as a Product Owner, so I’m still trying to keep up with my team while on the road.  And this trip has been a good reminder of the challenges of working remotely.  Here are seven things I’ve remembered that make a big difference if your team has remote members:

1. Actually log in to your chat client. 
Instant messaging is a great way to quickly make contact with people on your team, but if everyone isn’t actually logged in to chat, you often can’t reach the best person.  If I want to talk to Fred, but I can’t reach him, I’ve got to make a decision – do I wait, or do I interrupt Jason, a developer on his team?

2. Dial in the bridge. 
If you’re having a meeting, and you have remote team members, make connecting to the conference bridge a habit, even if you don’t think anyone remote is going to be attending.  Plans change; something comes up such that someone who was going to be in the office is out.  If you don’t connect the conference bridge, remote employees will either give up, or frantically try to catch local participants on IM in the hopes that someone brought a laptop to the meeting.

3. Check in and out on the phone. 
Assign someone in your meeting to remember the remote team members during the discussion.   And make sure you check in with the people on the phone before you hang up at the end of the call.  (Give them a few seconds to unmute before you assume they’re gone!)

4. List your cell numbers.
At Rally, we have a Google spreadsheet that lists office and cell numbers for everyone.  I’m rarely at my desk during the workday, so cell is the only reliable way to reach me.

5. Skype your standups.  
In our team room, a couple of the machines have Skype running.  When you’re remote, video goes a long way to improving connection with the team.  Showing some video of the absurd furnishings or the view outside the hotel room makes it fun.  This morning, I had some bandwidth issues and could only use voice – it didn’t work nearly as well.  Also, with a team like mine, a remote employee who doesn’t enable video for an early morning Skype session will invariably be subject to baseless accusations of not wearing pants.

6. Leave Skype running for a few minutes after the standup is over. 
Often interesting conversations pop up in the 30 minutes following this meeting.  As a PO, I often overhear useful bits of information at this time, and it makes it easy for people to ask me questions they might have forgotten during the standup.

7. Update your stories. 
This morning, when I logged into Rally, it looked like a ton of work was in progress.  Turns out, my team just hadn’t updated their tasks and stories.  Often Rally is the window your remote team members have into what’s going on.  If you don’t update stories, you can end up with unnecessary confusion.  Fortunately, we cleared it up in our daily standup meeting.

These were the things I remembered this week.  So what tips do you have for making life easier on remote team members?

“You learn more quickly under the guidance of experienced teachers. You waste a lot of time going down blind alleys if you have no one to lead you.” -W. Somerset Maugham (1874 – 1965)

Filmed at Rally’s Agile Success Tour events, these videos detail the real-life agile implementations of software/IT executives who have taken the enterprise agile journey and are now realizing the benefits of enterprise-scale software Agility.

Our coaching and technical account teams (including Jean and myself) provided guidance to many of these panelists during their initial steps in their journey.  It gives me great pleasure to see them now become the teachers and share their expertise with the new generation of practitioners.

Don’t pass up this great opportunity to learn from the experiences of others!

click here if video player is not loading in your RSS reader

Catch the next Success Tour events in Boston, Seattle, Chicago and London this Fall
These events are free, but registration is required.

Never back down from an intelligent debate - or whatever these idiots are doing

The question over product management vs. product ownership is a huge issue that many companies face as they try to scale Agile. Dean Leffingwell just finished up a great series on Agile Journal in which he makes the case that the Enterprise Product Manager is Likely NOT the Agile Product Owner.

The Agile Journal article series is a great place to jump into the debate, but his blogging on Scaling Software Agility is also excellent and very deep – what Dean tends to call “pithy.” I am sure some of you will call foul with some of Dean’s points, but his methods have proven to be very effective with large-scale agility. I’d ask, are you skeptical based on personal bias or real Agile principles?

Here are four other resources that are great at analyzing product management and product ownership:

1. Enthiosys – I highly recommend their “Product Bytes” newsletter (Luke, Scott and Rich’s leadership here)
2. Pragmatic Marketing – They are shutting down my favorite Tuned In blog, but the others are also good and Tuned In has excellent archived topics
3. On Product Management – I love their lens on product management overall, not purely Agile
4. Accidental Product Manager – Very pithy blog on product management and timely topics

Final note to readers: Dean is a good friend of mine, and he helped me start Rally.  He is an investor and worked for us between 2003 and 2005.  Now he does his own consulting on large-scale Agile and continues writing for Prentice Hall.  I cannot thank him enough for his personal support in shaping my thinking around large-scale software development, building a network into some of the world’s best practitioners, and coaching me as an entrepreneur.  He is a passionate software craftsman.

Thanks, Dean, and very nice work on this critical topic.

Okay, that wasn’t exactly how it was said. However, the title of this post reflects a comment I overheard recently while facilitating an operations and architecture team’s retrospective.

We first looked at basic facts about how their quarter had “gone”: what events stuck out in their minds, what the basic acts and information were that surrounded their day-to-day work. Just the facts. From there we checked out the impact of those facts, that information, those events, on them. Was this a good thing? Was that a bad thing? Were these helpful things or challenging things? We were seeking reflection on the quarter to then help draw out some insights into trends or recurring issues and themes.

After this, I asked the group of 8 people: “What still puzzles you?”

No one had ever asked them that before. They leaped at the opportunity to express frustration about where they sit (or don’t sit) in the Agile development approach. Did they have “a seat at the Agile table” or not? Here they were, the operational experts. They held grave concerns about the operational scaffolding upon which prioritized features were being built across the multiple application teams. And yet they felt that the collective Product Owners could not see this. ‘Tis a puzzle.

Once the group had aired their puzzles and concerns, I then asked for their recommendations. And that is when, verbatim, one of the team members said, “Well, we need to push it up their backlog!” Now, as a facilitator, I am asked to write what is spoken and also to not comment. But this was priceless!

In any case, how DO we push something up someone’s backlog? And why is PUSH even considered the only way to get onto a backlog or backlogs. Here are some ideas that then swarmed around in my head:

• how do we articulate the value of operational and architectural items?

• who do we articulate this value to?

• how do we convey that value across multiple teams’ backlogs (i.e. influencing multiple Product Owners)?

• how do we then coordinate operational items being completed for the next major release across all backlogs?

So, maybe pain is the only sometimes way to help articulate the value of operational work: “It will cost our customers this much pain if we don’t do this.”

The moral of this story: Pushing things up your (or someone else’s) backlog sounds painful; find another way.

If you have ever wondered what to do with the growing number of features in your software applications, you are not the only one. There is some useful guidance from The Standish Group survey quantifing that only 20% of all delivered software features are “often or always used.” For a team under the pressure of today’s economy to do more with less, here is a way to conceptually cut 80% of your effort and still deliver the high-value essentials. But wait it gets better. If you do not completely elaborate, build, test or document these features, you save once. But you also save again: with the future maintenance costs, the training users, the bug fixing and the regressing these features would have required. This is clearly the biggest lever for cutting software development costs using Agile. And yet it seems to be the hardest to attain.

Features used in Commercial Software - Reported by Jim Johnson of the Standish Group at XP2002

This pairing back to the simple, important few takes tons of discipline and that level of discipline is only be made easier as your agility maturity increases. Most agile books and coaches will call this the discipline of “Brutal Prioritization.” The folks from 37Signals call it: “Getting Real.” In either case, brutal prioritization means two things:

1. Not letting the fat slip into the backlog
2. Keeping the backlog prioritized by value and risk

First, lets talk about fat or wasteful features. Please note, fat or wasteful features come from all directions from the business and customers, but also from developers, support, and product owners. Your features may be fat or wasteful if they:

1. Do not help the most important user persona in your domain achieve breakthrough results or competitive advantage
2. Have not be proven to work and are based on a hopes and prayers
3. Look like pets that someone is protecting
4. Are weak features that degrade the product because they are not complete enough to meet minimum expectations

Photo © Tristan Savatier - http://loupiote.com/ - Used by Permission

So if you are in the customer role or customer proxy role such as the Scrum product owner role, the technical product management or a business analyst role, it is your job to control yourself and help the team to keep the fat off the backlog. If you are on the agile team, it is your job to keep these roles honest about WHY these features are so valuable. This leads right to ranking the items into a prioritized backlog. (A few comments in this area would be really helpful – let’s hear what you use to spot fat features?)

(more…)