In my first post I said that agile adoption reminds me of my personal experience in competitive sports. The pain was so intense at times, it left me physically and emotionally spent. But with a bit of determination, the gain was always much bigger. These experiences are much like my own experience transitioning to agile development. Here’s the rest of my story:

Here I was a Project Leader at a new company.  My leader walks up to me and says, “So,
there’s this new thing called agile development and we want to try it.  Are you up for piloting it with your project?”  Being the newbie and not wanting to start off on the wrong foot, I said “sure.”   He handed me the book, Agile and Iterative Development: A Manger’s Guide by Craig Larman, an introduction to the different agile methodologies such as Scrum and XP.  From that book and the Agile conference in Calgary that year, I was off to see if this thing was worth its weight in gold.

A year later our entire dev group converted to agile development…we were on our way to the promise land!  I’m sure this is no news to you… it was painful.  I’m here to tell you the gain was worth it!

At first it was great. We had this new-found vigor and vitality that agile development was going to be the “silver bullet.”  No more late projects; the business was going to be completely involved, and all the team members would rise to the occasion and be overly zealous to try this new thing.  And then reality set in.

The pains…

• The agile bus left the station but not everybody was on it; and some who were should not have been
• When people get “set in their ways” it’s hard to change them or convince them to change; change is hard
• The business could not always give us 100% of their time; they had day jobs
• We floundered around for a bit before we got our footing… no one is perfect right out of the gate
• Did I say change is hard?

The Gains….

• Delivering valuable/quality software to the business early and often – once they get a taste, they want more!
• Collaborating with the business to ensure you are delivering the right things…having a prioritized backlog and knowing what absolutely had to be done was pretty cool
• Coming together as a team to figure out how to work and deliver; we were free!  Not “cowboy” free, but able to decide how to get the work done
• Infusing quality throughout, not just at the end… our testing folks were ecstatic to be included from the start
• Releasing incrementally because we could!
• Having Fun! Let’s face it, we spend a lot of time at work and if you can’t enjoy
  yourself, it makes for a long day

Not everyone is going to experience the same “pains” and “gains,” but I’m here to tell you that I have no intention of ever going back to life before agile development.  I’ve seen too many positive business gains, and I’m here to stay!

Read Part 1

I love sports and any chance I get to relate it to what I do for living, I get pretty jazzed!  So, hang with me on this… I hope this either reinforces what you already know about
agile development or gives you some encouragement if you are thinking about agile adoption.

In the good ole days where coaches could coach and parents were truly spectators, the “No Pain No Gain” mantra was used quite a bit to motivate individuals and teams to higher levels of achievement.  In its simplest form, it was a saying that got you up at 4am to get to practice, through rehab for an injury and back on the court/field, and through
grueling practices and conditioning which left you – well let’s just say – sick and puking.

As an athlete and coach, I came to realize this statement wasn’t just for sports.  I learned early on in life that pain could be a lot of things: loss of a loved one, divorce, loss of a job, changes in an organization, your teenager going through a heartbreak, etc.  I’ve had my share of “pain” in my lifetime so far, and I’m sure there’s more to come.  But experiencing these setbacks builds my character and causes me to do some self evaluation, pick myself up, brush myself off and keep on moving.  That’s the gain part –
growing and learning from the experience to be able to handle the next thing
that comes my way.  Or as Randy Pausch talks about in his book, Last Lecture, “it’s the brick wall you must overcome.”

In the second part of this post (tune in after Tuesday, 2/21), I’ll tell you how moving to agile was no different in my experience… While agile adoption is not as extreme as some of the other life events, it’s still something that requires determination to keep on moving when there are setbacks.

Have you ever been part of a company where your value to the organization seems to diminish as the company grows? Each time I have worked for a growing company, it reaches a point where the early employees leave (or are asked to leave) because no one seems to perceive their value anymore.

My story about a great company and its growing pains

I saw this happen at a highly successful company with a suite of hardware and software products. When I joined, the founder was leading the product management group responsible for about $250M in revenue. His product vision and his code were key reasons why the company held its dominant position in the market. Repeatable large-scale execution wasn’t his passion or gift, but (like most technical founders), he was an amazing innovator.

About a year after the company went public, the founder was asked to step down from his position. His future with the company was in serious question. In the maelstrom of execution as a public company, he was considered a risk. Why? Everyone was focused on removing any obstacle that got in the way of making quarterly numbers. After all, his strength was on future-looking vision and innovation.

Sadly, it seems that every successful company has moments where the focus on quarterly and annual execution can snuff out the future, both future-looking people and future-looking products.

What is this about?

What happens when a company’s first product goes mainstream and is the source of significant revenue?

• It gets more difficult to to be consistently innovative; innovation seems like speculative investment in the future.
• The inertia of success tends to run over anything that can’t prove its value in this quarter or next.
• The culture tends to shift from embracing uncertainty to embracing repeatable execution.
• Urgency shifts from figuring out what’s going to work to executing on what’s working.

In effect, the company moves away from embracing ambiguity and innovative people. Success is measured instead against steady, efficient execution of those products in the company’s portfolio that guarantee quarterly results. This may appear to be great – as long as what has been working in the past continues to work. The problem is that the pull of the past can be a killer. Why? More and more companies are waking up each morning trying to figure out how to disrupt your market to their advantage.

Is there any hope?

Last year, two important books were published to help balance the tension between immediate portfolio execution and long-term innovation: Escape Velocity by Geoffrey Moore and The Lean Startup by Eric Ries. Geoffrey Moore offers guidance on how to manage three investment horizons to ensure your company’s future. A great complement to this view, Eric Ries provides a framework for thinking about the extreme uncertainty inherent in new product and new market development.

Both books give new product and market creators great language for making future-looking business cases to execution-oriented people. They also create a compelling framework for portfolio planning. Their combined wisdom offers great insight into why we need to act differently, how to think about portfolio steering in a new way, and what to do in order to invite innovation back into our organizations. This is powerful guidance for investing in the future of your company and building a culture where your people will thrive.

Escaping the “pull of the past”

In Escape Velocity, Geoffrey Moore introduces us to the McKinsey concept of three different time horizons for a business portfolio strategy. The horizons describe ways a company can set itself up to escape “business as usual” and instead take advantage of, and plan for, present and future opportunities for success.

• Horizon 1: Investments are expected to contribute to material returns in the same fiscal year in which they are brought to market, thereby generating today’s cash flow.
• Horizon 2: Investments are expected to pay back significantly, but not in the year of their market launch. Typically, they are fast-growing from birth, but come off a small base and need time to reach a material size. Moreover, because market adoption is rarely linear, there are often fits and starts before they catch fire. In the meantime, however, they are making material demands on go-to-market resources in the current year without generating corresponding material returns, and so they demand patience.
• Horizon 3: Investments here are made in future businesses that will pay off years beyond the current planning horizon. They are not expected to appear in-market during the current planning year, and while they make claims against R&D budgets, they do not affect the go-to-market operating plan.

Moore suggests that considering these horizons in the steering of your portfolio will enable you to “escape the pull of the past” and drive next-generation growth from new lines of business. I think this is key to being a successful Agile company with both a future-growth product strategy and people who remain proud and engaged.

(To get a good overview of Moore’s perspectives on these horizons and how Agile portfolio steering helps organizations achieve escape velocity, visit our website for the video on his talk from December 2011. To learn more about his perspectives on Agile organizations in general, check out the video of an interview Ryan Martens and I conducted with him last September.)

Inventing the future

A young startup working to put their company on the map lives in Horizon 3. Here, it’s all about learning: learning what the customer looks like and learning what product or service will inspire them to get their wallet out. This involves tremendous uncertainty. People who thrive in environments of uncertainty love to figure this out — knowing there are no obvious answers, and the questions to ask are pretty vague. My experience is that founders and early employees love the challenge and meaning of doing something no one else has done before.

Planning is still important here, but the plan itself isn’t the greatest value. There is something much more important going on. The company and the people are inventing the future, not predicting it. Deviation from the plan is expected. The only form of failure is not learning (or not acting on learning) and instead, sticking steadfastly to the plan. In fact, instead of revenue measurement, internal learning milestones are often a key success metric.

Growing, but not there yet

In Horizon 2, things are starting to work. A product is meeting a market need and has started to generate some revenue, but it hasn’t hit a tipping point yet. There’s still a lot of opportunity to learn, many ups and downs, and moments where it feels as though the company is taking steps backward in the market.

Those who thrive here have a different comfort zone: executing on what’s starting to work. Even though there is still uncertainty, patterns are beginning to emerge, and translating those patterns into repeatable execution plans to exploit what is working is key. Early employees are now surrounded with people who can appreciate uncertainty, but are more comfortable executing. Performance in Horizon 2 is typically measured by some combination of internal milestones, market indicators of tipping points and revenue.

Today’s cash flow

In Horizon 1, it becomes all about executing on the repeatable game plan that was developed in Horizons 2 and 3. The company has shown that by spending more, they can predict marginal increases in revenue. Success is now measured by typical performance metrics: planning and predicting future revenue and executing to results.

The company puts hundreds or thousands of people on money-making Horizon 1 initiatives, and the 30 to 60 people who were highly valued during Horizon 2 and 3 begin to feel lost. In an environment of certainty, those who are passionate about future growth (where learning and discovering is more important than exploiting a repeatable game plan), may only see monotony.

This is a dangerous place. When those who love uncertainty are asked to scale their execution, it can bring varying results – along with damage to their reputations. Many will lose their sense of value as execution and certainty dominate the company. They may feel compelled, for the future of the business, to inject uncertainty into a machine that has been optimized for execution. This is dangerous to Horizon 1 folks and for those around them. It’s no wonder why most of them leave or are asked to leave and return to much smaller, more uncertain environments.

Next-generation growth

Successful companies with products that are generating returns today face a common challenge: creating future successes. This entails investing in and nurturing next-generation products in high-growth markets. Why? Because the portfolio strategy required to sustain a growth company can’t be found only in current business. Here is a worst-case scenario: one day the business wakes up and realizes the game plan they’ve been executing isn’t working anymore. There are no future opportunities that are ready. Nothing has been incubating in Horizon 2 or 3, where it takes time for ideas to move through incubation. And, if the current market shifts and you have no options in Horizon 2 to generate tomorrow’s cash flow, you’re stuck.

A company can invest in its future and its people at the same time

In The Lean Startup, Eric Ries shares the necessary conditions to work on future initiatives within larger, more mature companies. (To get a good overview of Ries’ perspectives on helping entrepreneurs increase their chances of building successful businesses, visit our website for the video interview Ryan Martens and I conducted earlier this month). He argues for three main conditions:

• Scarce but Secure Resources
• Independent Development Authority
• A Personal Stake in the Outcome

Just as important are the people assembled to work on future initiatives. Your star performers focused on current initiatives in established markets may not be wired for this work. They excel at predicting the future and delivering a portfolio plan that consistently meets or beats those projects.

Forward-looking work should be full of people who embrace and excel at uncertainty. Consider the original people who initially led the company through Horizon 3 and Horizon 2 the first time. These are great people to take off of Horizon 1 work. Invest their time and passions instead toward the speculative work of inventing the future of the company.

Improving your odds of success and survival despite uncertainty isn’t easy

Inventing the future isn’t easy and it isn’t without its casualties. Once you make the leap of putting the correct people on future work, then comes the task of improving the odds of their success and survival. Venture-backed startups have a failure rate somewhere between 50% and 90%, but large companies do have one advantage over startups: they have a significant foothold in an existing market.

With this advantage, large companies nonetheless suffer two big disadvantages:

• Horizon 2 and 3 work will be expected to not disrupt any current activity. This can be a hard pill to swallow.
• Horizon 2 and 3 work may be subjected to inappropriate measures of progress based on a skeptical Horizon 1 mindset. The skeptics may view new product development as an unmeasurable art and therefore far too risky as an investment.

Execution-oriented people need to see a disciplined approach to investment

Historically, Horizon 2 and Horizon 3 portfolio investments have been made with a very fragile agreement that goes something like this:

“Give us a chunk of money and an independent corner of the business to operate within and we will invent the future. Trust us.”

This isn’t fair to either side of the agreement. Without an alternative, execution-oriented people will naturally measure the progress in ways that make sense for Horizon 1. But those aren’t fair measures for Horizon 2 and 3. Without a disciplined approach and a specific set of measures appropriate for Horizon 2 and 3 progress, the execution side of the company will become the executioners. The portfolio investment in Horizon 2 and 3 will fail and the failure will place inappropriate blame: on the teams that were engaged in that work.

The Lean Startup process provides a way to show progress and build trust

First, The Lean Startup provides a disciplined way to manage the innovation process within the portfolio steering. Secondly, it describes the innovation process in a language Horizon 1 execution-oriented people can appreciate.

The Lean Startup process allows for a much healthier agreement across the Horizon 2 and 3 teams and the rest of the business. The conversation goes something like this:

“Give us secure resources, we don’t need much. And give us the authority to run the team following the Lean Startup process using Agile development techniques. In return,  we will constantly report on our progress using the metrics of Innovation Accounting. You can see our process and measure our progress. Through our continuous transparency, we will create trust in your investment in our part of the portfolio.”

The key is making sure the execution side of the company understands the process you’re following, because that is how they look at the world. They also need to value the new measures necessary to understand your progress. Even in extreme uncertainty you can be measured by your ability to incrementally learn what customers want and are willing to buy. That is the key shift. Disciplined learning is both the currency and the metrics of Horizon 2 and 3 initiatives in your portfolio, not cash in.

Before Eric’s book and the Lean Startup process, there wasn’t great language to describe this shift in thinking. Most successful early entrepreneurs naturally understand this. But often, these highly successful entrepreneurs couldn’t put it in language that Horizon 1 execution-oriented people within large companies could appreciate. That’s the brilliance of The Lean Startup – it works in early startups as well as within well-established companies.

Prepare your portfolio in a new way right now

The inertia of success can run over anything. You may find yourself having to prove your portfolio investment value every quarter. Your culture may shift from embracing uncertainty to embracing repeatable execution. This is the “pull of the past” articulated by Geoffrey Moore.

Now is the time to act

You need to ensure your future by creating teams focused on Horizon 2 and Horizon 3. You need to embrace this approach in your portfolio steering. And, this isn’t just a funding issue. Find a handful of your early employees and founders who may be trapped executing the known playbook. Bring them Eric Ries’s great work on The Lean Startup process. Get this independent team on the important business of freeing your company from the pull of its past. Give them a sandbox where they can innovate. Compel them with a personal stake in the outcome.

When you prepare to do this, you will give your company and these people the gift of meaningful work, while investing in your future.

Zach Nies is a CTO at Rally Software and a proud member of the Boulder/Denver Agile community for the last ten years.

If you haven’t already heard the buzz, the State of Agile Development Survey 2011 is now out and it is packed full with some great information.   The survey is a helpful resource to quantify what people are doing and the value they have realized or have not realized through their particular agile implementation.  As part of teaching agile methodology and speaking to the delivery methods used, I often reference this pie chart, which shows the Agile Methodology Used, and I just updated my training materials with these latest results.  One thing really jumped out at me and made me go, “huh?”  It was that 8% of the respondents answered “Don’t Know” to the question, “what agile methodology do you use?”  That’s roughly 500 of the 6,000+ respondents.  And like any good agile metric, seeing this only made me ask questions and hypothesize as to why so many folks answered “Don’t Know.”

The first thought I had is training.  Yes, coming from a guy who does coaching, that is the first thing I thought of.  But not for the reasons you may think.  If you think about it, the number of teams applying agile methods is climbing the blade of the hockey stick. As someone who has seen the benefits in product outcomes and overall organizational morale, I think this is great!  But the challenge is, with adopting agile it does require training the team members so that they, the TEAM, can make the transition successful and help adapt, adjust and evolve the agile methods used to fit their development environment.  In agile development, the TEAM owns the process and the TEAM is empowered to make it successful.  This is much different than traditional project management where you can focus training on just the project managers and folks in leadership positions.  The team just needs to know where to report time, and how to write up their status reports.  So, if the team has not been trained on what agile is, and the surrounding methods and processes, then I can understand when you ask them, “Do you do agile?” … “Yes.” “What agile method do you use?” … “I don’t know.”

The second reason I can think of why folks answered, “Don’t Know” is that they are leveraging multiple concepts from the various agile methodologies – including agile project management and traditional project management.  The survey did allow folks to answer “Hybrid” (9% of respondents answered), but in my discussions with teams lately – the application of Agile principles is the beginning focus with the adopting and adapting processes is much more flexible.  Teams are starting with one method and morphing to another, and in some cases leveraging a little bit from everything.  This approach can be good and bad, depending on the maturity of the team and the ability to continuously improve.

Besides the answer of “ignorant blissfulness,” the only other thought I had for the “Don’t Know” response are those that work at organizations that have heard about this Agile thing and decided that they will become Agile.  So they leveraged Find and Replace to put the word Agile in place of whatever methodology they were using before.

So, what are your thoughts?  If you participated in the State of Agile Survey this year, why did you answer “Don’t Know”?

In Part 1 of this post I explained why it’s important for agile development teams to have distinct specialties – very similar to the way a jazz combo works together to create beautiful music. In this post I’ll continue my parallel and explain the value of maintaining these specialized roles within a small, cross-functional framework:

Continued from Part 1 …

And, of course, we also have the rest of the musicians who are like the testers and programmers in that they all have some specialization, perhaps the instrument they play, or the particular way in which they play.  For instance, in the Duke Ellington Orchestra, not only was Cat Anderson known for being a great trumpet player, but he was also known as a high-note specialist. If applied to the agile software development environment, not only are there specializations like programmer and tester, but there are also some folks who are best at User Interface, or at database work. There was never a rule that only Cat Anderson could play the high notes, or that he could only play certain notes. And there should never be a rule that only your “UI guy” can work in the UI. That would lead to a very thin team.  There would be no ability to build a depth of knowledge throughout the team.  Should a particular team member be unavailable, and the skill in which she specializes is required, the team is now hostage to her schedule.

There are many reasons why small groups are desirable. Members of a small combo are best able to work together and play off of each other’s strengths and weaknesses. They can react to changes that might come from the stage dynamics. Whereas many large bands require a hefty amount of coordination and very little room for improvisation, the small combo thrives on improvisation. Everyone adds what fits best, and the feedback from the audience is immediate. The energy builds – not just from each contribution, but also from the cumulative effect. The band doesn’t stop and argue when someone makes a change during a jam session. Band members pick up the new tempo and use this change to make the music better than ever before; the same thing happens in agile software. The team is able to communicate and work together. The different players are not going through some intermediary, but directly to each other. The energy, the pace and the quality of the product all come out through this tight, frequent interaction.

I’d like to take the next few weeks or even months to explore further how we can apply the lessons of our jazz brethren to the world of software development.  We can talk about ideas like how to be successful with duets (pair programming), or perhaps how to conduct a jam session.  Hopefully, this will spark some ideas that can build a strong understanding of how to work in our agile teams.  What other comparisons can we make?  What do we do when a small combo begins to grow into a large orchestra?  What might that mean to us?  The possibilities are endless.

So now picture this: The agile development team comes together for a planning meeting. The director establishes the tempo by identifying, with the help of the team, the velocity for the upcoming work. The product owner then lays down a groove, describing the melody and harmony of the iteration.  She does this by providing a depth of description and acceptance tests, which show not just what we will be doing, but how each story interacts with the others. Now the rest of the team picks up the melody as shown by how the programmers and testers pair up and work on stories together. The team’s energy builds as the code is tossed back and forth in short phrases. Each member employs his strengths, but helps to contribute to the overall outcome wherever he can. At the end of the iteration, the audience expresses their appreciation for another fantastic performance.  Now we can chill for a little while, enjoy our success and look forward to the next gig.

Whenever I use John Deere as an example of a fantastic Agile adoption, I always get looks of surprise. That’s quickly followed by an ‘a-ha’ moment when I share that today’s

From my visit to the test farm in Des Moines - note all of the hardware on top of the tractors

tractors are run by more lines of code than the early space shuttles. Yesterday, ComputerWorld published a great article about John Deere’s Agile adoption, characterized as a ‘big bang’ across their 800-person development organization within a year. It’s definitely worth the 5 minute read.

By 2050, there will be 9 billion people on the Earth.

In 50 years, the world population will require 100% more food. Seventy percent of that food is expected to come from efficiency-improving technology. John Deere considers these their user stories, and they strive to use technology to help solve these global problems. If the ComputerWorld article is worth 5 minutes of your time, then Chad Holdorf’s in-depth talk is worth every bit of 25 minutes to hear John Deere’s bigger vision and how they inspire teams to tackle it at John Deere.

You can work with John Deere too.

I’ve been honored to work with Tony Thelen, director of John Deere’s Intelligent Solutions Group, and Chad Holdorf, their Agile Coach, throughout this transformation. And I share their passion for connecting engineers to solve these potentially disastrous problems. I’d like nothing more than to see some smart folks go to work for John Deere.

With my son in a John Deere plow.

Tractors and Agile? Absolutely. I can’t think of a better example of how software is shaping the world we live in – every single day. Congratulations Tony and Chad and best of luck on your social mission.

Ryan Martens is founder and CTO of Rally Software, a hopeful Citizen Engineer and a recovering Entrepreneur-in-Residence at the Unreasonable Institute. You can follow him on Twitter @RallyOn.

<Adapted from my article in CM Crossroads article titled, “Making Beautiful Music Together”>

Have you ever watched a jazz combo? The performance starts with the leader counting off the rhythm, then stepping away. Then the drummer begins to lay down a beat. Even at this stage, the audience can feel a groove hit the room. Soon, the piano joins and adds both melody and harmony to the piece. Energy is flowing from the chords as the team starts to see and feel the direction of the piece. Now it’s time for the other instruments to join in the fun. A typical combo will have a couple of different instruments, maybe a sax and a trombone or some other combination. Whoever starts off will state the melodic theme for the song, although sometimes the whole group does this together. After that, everyone gets the chance to do a solo, in which they improvise on the main theme, key off of past experiences and apply their musical knowledge. It’s not uncommon for jazz musicians to jibe each other, making jokes and comments while they are playing. The energy in the room builds and builds as the musicians play together, sometimes one at a time, sometimes in tandem. When you watch a jazz combo really swinging, it can be hard to tell who his having more fun – the audience or the musicians.

This metaphor works quite well to understand what makes a small team desirable, and how to be successful with such a team.  In the agile software community, we have asserted over and over again that we need small, cross-functional teams. And yet, what really is cross-functional? Can cross-functional really work? The more traditional view of software creation involves the need for separate, functionally focused teams who are experts in their domain. The teams only interact as they are passing work items from one to the other. When development is done, the teams hand off work to test. Test will find defects and hand them back to development. And the dance continues in this light forever.  The jazz model demonstrates that this can, in fact, work.

In a jazz combo, each member of the team has a specialty. The members play individually, but often together  they create a tapestry of music that becomes much greater than the sum of the individual contributions. A small development team works best this way. We have some set of programmers, testers, documentation specialists and some representative of the business working together. Team members gain their energy from each other. They try new things and get feedback right away from anyone who wishes to listen and share.

The team members don’t need to just focus on their own areas either. A tester can very easily and effectively form a duet with a programmer. They will play off of each other with their ideas. The tester will write a test to express some piece of functionality that the software will have. Then the programmer will answer with the code that will cause the test to pass. So we write another test based on this back and forth interaction. In music this interaction is known as “call and answer,” and it is especially effective with the testing and programming cycle, as it provides a rapid, tight feedback loop.  Communication is instantaneous, allowing for more freedom of action. More often than not, a programmer will pair with another programmer. This duet is very effective and powerful as well.  The programmers can build off of each other’s knowledge; ideas that might “seem like a good idea at the time” are instantly reviewed by a peer.  This type of pairing turns code review from an intermittent, reactive process into a continuous, proactive activity, and should be embraced as often as possible.

Let’s explore some of the roles that are important in a development team. Usually there’s some sort of coach or leader. In the Scrum world, you might hear about the ScrumMaster. Each of these names is meant to describe someone who is both a part of, and to some extent outside of, the team itself; in a jazz combo, this is the director’s role. Not every combo has a director, but many do. Sometimes that director is part of the team, only directing long enough to initiate and introduce a number to the audience. In software development, the director represents the team to the stakeholders, and helps plan the meetings, stand-ups, and the like – essentially counting off the beat. If the rhythm seems to be getting lost, the director can help the team identify this fact and help with corrective actions.

A team also needs an individual who has the ability to identify what needs to be developed. In agile development, this role belongs to the product owner. Now consider a jazz combo’s basic rhythm section… The drummer lays out the shape of what is to develop; the bass takes this one step further, presenting the progression of chords that identify the order in which the chords (which make up the actual harmonies and melodies) will be played. Lastly, the piano comes in with the rich, fully realized chords. Accordingly, the product owner has to play all three roles of the rhythm section, explicitly: identifying the work to be done or the shape of the upcoming work. Ordering the work in order of priority sets the rhythm.  Elaborating the story in terms of acceptance criteria provides the chord structure. And lastly, the constant interaction with the team throughout the development cycle provides the fulfillment of the intention as laid down by the acceptance criteria previously mentioned.

In Part 2 of this post (coming Monday, 1/30), I’ll talk about what other roles are integral to every agile development team and explain how keeping the teams small and cross-functional makes it easier to react to change.

Is it fair to call Quasimodo ugly?

Earlier this year, on the LinkedIn Agile and Lean Software discussion group, someone posted the question, “Is it fair or accurate to malign the waterfall process as is rote when people push agile and Scrum?”  The original question drew a lot of discussion, and then it seemed to die down.  All of a sudden it has reared its ugly head again, and really requires a more thorough response.

When I first saw the post, I laughed.  Here was a guy posting in the Agile and Lean Software group a question which implied that any negative talk about waterfall was “maligning” it.  Needless to say, the wording implied an assumed answer.  My first thought was that this guy was a troll. And the usual folks would quickly send him on his way with scorn and derision.

What surprised me, and somewhat delighted me, was how many people replied with thoughtful discussion.  Folks took the question, wording and all, seriously.  They started to explore the question of whether agile had become dogmatic, or perhaps we were being unfair to waterfall.  The conversation was going to help everyone better understand why the world is moving to a better way of creating software, which is what we are calling agile (and now also Lean).  This is, after all, what discussion groups do so well.  We learned so much through the discussion groups in the early days of agile, as if we were our own Socratic society.

I quickly became disillusioned though.  The discussion was not a serious examination of the pitfalls of the processes known as waterfall management, and how to overcome them by moving to agile development.  Nor was it an open conversation on why – when it comes to software development projects -waterfall is the poorest of choices.  Instead, we saw a lot of folks very nicely saying that waterfall management will work just fine if you have all of the information up front… or if you have a very clearly defined set of goals and a strong understanding of the problem domain.  This would lead one to say, “gee, if that’s all it takes, why learn all these new processes?  Maybe we should just put a lot of time and energy into being able to get all the information up front, or into making sure we have a clearly defined set of goals and ensure they just don’t change during the project?”  Well I’ll tell you why.

***It just doesn’t work!***

This is a good time to remember why agile software practices came into being in the first place.  We didn’t all sit down and say, “You know, everything is going so well and projects are really coming in on time/budget, with high-quality code.  Let’s change everything.”

This all started because folks realized that projects were failing more often than succeeding.  Most of the projects that were considered success on the outside were the result of long hours and dangerous shortcuts.  Change became something to resist, even if the change was the right thing to do.

We spent a lot of time and energy trying to find ways to change this; we usually exhausted time and energy that would have been better spent creating software.  Agile development is about recognizing the difficulties and complexities of the software world, accepting them and working in a way that harnesses the ability to change software at a minimal cost.

So no, everyone doesn’t get a trophy.  Waterfall is not a good way to approach software projects.  That’s ok.  There are many non-software projects that would do quite well in the waterfall model.

Meanwhile, let’s dedicate ourselves to spending this coming year getting the most out of agile, especially finding the time to improve the craft of creating the software. Arguing about whether waterfall is still good is *so* 2011!

I like to participate in discussion groups.  I enjoy the discussions themselves, and I also like “meeting” the folks who are participating.  There are a lot of questions that get repeated in those groups, but I personally feel that the conversations are various enough that this is a good thing.   There is always enough of a twist on each one that I learn something new.

One question that comes up a lot is, “Who should be the Scrum Master?”  Sometimes it is as simple as, “Hey, we are starting to do Scrum, so we need a Scrum Master. Who should we get?” Sometimes it’s a bit more involved.  Many of these conversations really focus on turning Project Managers into Scrum Masters, as a sort of natural step in transitioning to a Scrum Team environment.  While I understand this seems to be a convenient, comfortable step, I’m not sure it is as helpful as it originally appears.  In our never-ending search for metaphors to explain ourselves, I am going to utilize that well known show from the ’70s and ’80s, M*A*S*H.

Consider the role of the Project Manager.  A good Project Manager is responsible for making sure all the variables for a project are identified and categorized.  He/she is also responsible for identifying and mitigating all of the risks in a project.  Most of this is done at the beginning of a project, and will then continue in a reactive manner throughout the course of the project.  Other tasks that are important to a Project Manager are to identify and manage the budget for a project, as well as make decisions along the way as to changes and delivery.  To me, this is Colonel Potter, as played by the late great Harry Morgan.

Col. Potter understood that his job was not to tell the surgeons what to do, or how to fix a wounded soldier.  He was absolutely a figure of authority, but knew when to get involved and when to stay out of it. When push came to shove, if there was a decision that the team wouldn’t or couldn’t make on their own, he was there to either offer some insight to help them come to a decision, or in some cases he knew he had to be the one to make that decision.  One disclaimer here:  the level of authority for a wartime military commander is going to be much higher than in our world, but much of this still applies.  Leadership is not really different; it just becomes that much more imperative.

So in the M*A*S*H series, who represented the Scrum Master?  I see the epitome of a Scrum Master as Radar O’Reilly.  He made sure everything got done.  People got used to relying on him without asking for something in particular, and he really made everything happen.  If something got in someone’s way, he knew what to trade -and with whom – to make that obstacle go away.  I also think it’s worth noting that Radar was a Corporal for most of the series.  He led from a position of no power whatsoever.  He knew nothing about surgery, nothing about the military, but everything about relationships (albeit, not the romantic kind). There was never any doubt as to who really made things happen there; it was all Radar.  He made things run smoothly so the doctors and nurses could focus on healing the sick and wounded.  This is the Scrum Master.

One last comment on the M*A*S*H analogy.  At the beginning of the series, the doctors did all of the surgery and the nurses supported them.  Over the course of the series, you would hear surgeons use statements like, “OK, nurse, close for me.”  Then later, the nurses started doing triage (determining which patients had to be operated on right away and which could wait) and, in some cases, even getting involved in the actual surgery itself.  So while everyone kept their specializations, each was able to branch out and help wherever necessary.

Sound familiar?

In the first part of this post we established a context about Kanban as an agile software tool (not to be confused with the manufacturing term, kanban).  I also explored some of the key myths and hype behind Kanban vs Scrum.  Now I’ll discuss the realities of implementing Kanban and some of the fundamentals that hold back both Kanban and Scrum implementations.

On paper, Kanban is certainly easier to kick-start from a change management perspective because you can leave current roles and processes largely intact; you just need to get commitment from the business to adhere to three basic principles:

1. Provide a high degree of visibility/transparency of the state of all work queued and in progress
2. Establish and respect WIP limits in the value flow
3. Commit to execution in a ‘pull-based’ manner from the prioritized work queue

Yeah, just get commitment and practice of these three things… Much easier said than done in my experience because they are frequently outside the circle of influence of those driving the change to implementing Kanban!

Usually it isn’t that the agile software teams are unable to execute under Scrum; the fundamental issue is that the business isn’t willing to accept a “pull-based” execution model  (required for Kanban and Scrum).

Businesses continue to make irresponsible commitments to customers and investors. This only perpetuates crystal-ball thinking, fixed-date, fixed-scope and fixed-cost projects. It’s the classic sales-driven model we see all too often where the sales arm doesn’t respect the capability of its product development group to produce predictable value for the customer in a timely manner, and with an agreed-upon level of quality. After all, quality is a business decision.

This irresponsible action ends up causing organizations to be unpredictable in their delivery, have lower quality, and to burn out their teams.  These outcomes in turn destroy brands, ruin company reputations on Wall Street,  increase the percentage of each investor dollar serving up technical debt (in lieu of adding new value to products), and causes instability in the organization’s systems due to turnover.

Bottom line, if an organization can’t make the commitment to respect their product development system’s proven delivery capability at the current level, neither Kanban nor Scrum will provide predictability.  But even in the face of this dysfunction, agile methodologies like Kanban and Scrum can still provide faster learning to teams, which allows them to test their assumptions faster and provide more value to their customers by delivering what they actually need.

In conclusion, I leave you with this advice:  ignore the myths and hype about Kanban. Before you can make any decisions on the Kanban vs Scrum debate, you must first evaluate:

• Your organization’s product development and sales culture,
• The nature of the demand for service from product development,
• The competency of your organization to plan and execute change, and
• The degree to which you’re willing to face the truth

Only then can you choose the best agile software tool for the job.

Related topic: What is Kanban? How is Kanban different from Scrum?

It's usually about degrees for true and false

Recently, I heard folks at a few of my clients and at a couple conferences talking about why they are considering moving to using Kanban vs. Scrum.  I have no preference to either method other than choosing the right agile development tool for the job.  My concern derived from what I have heard identifies the beginnings of some myths and also demonstrates some of the hype around Kanban.

First, a clarification; Kanban with a capital (K) is the term David Anderson coined with respect to an agile development approach to driving change based on lean principles.  Kanban with a little (k) represents the idea of the “sign” or “billboard” that provides the signal/visibility in a production line for additional demand for service of a particular station. It is one of the tools that enables just-in-time (JIT) action as described in the Toyota Production System.

Kanban, as Anderson explains in his book, relies on change occurring in more of an optimizing manner (see kaizen culture).

David Anderson's Kanban book

This is the significant difference between Kanban and Scrum.  In a Kanban approach, an organization can begin with their current practices with a few exceptions. Kanban requires:

1. A high degree of visibility into the state of all work queued and in progress
2. Absolute respect for WIP limits
3. A commitment to execution in a ‘pull-based’ manner from the prioritized work queue

Kanban also demands a focus on quality.  In fact, this is Anderson’s first step in his six-step recipe for Kanban.  Quality comes first primarily because of the obvious cause-and-effect relationship to waste — and because it’s generally more in the direct control of technical management.  Working down his recipe, there tends to be less control and influence over the changes by technical management.

Now for the Myths and Hype

Myth:  Scrum has work pushed onto the team while in Kanban work is pulled into the system.  This is incorrect.  Scrum does not have work “pushed through the system.”  It is a pull-based agile development system with work pulled in larger batches (the Sprint Backlog).  A Scrum implementation (as well as Kanban) becomes a ‘push-based’ system when the business doesn’t respect the current proven capability of its teams to produce value and just continues to push demands for service into the system.

Doesn't just apply to Kanban

Hype:  Kanban at its core is summarized by the premise:  ’Stop Starting, Start Finishing’. The entire team’s focus is on ‘getting to done’ for the tasks in progress. This statement is certainly true of Kanban, but the implication that Scrum does not have this focus is not true.  Scrum done right has the same focus, delivering software sooner and doing so in priority order to maximize the value delivered to the customer. I’ve coached to Scrum teams for years that, wherever possible, everyone on the team should work on the highest priority item and get it done first before starting on the next item in the Sprint Backlog.  This implies limiting WIP, as well as focusing on delivering the Backlog in rank order.

If the focus of a Scrum team is to just get everything in a Sprint Backlog into an in-progress state, regardless of priority, then you have a dysfunctional team that’s most likely not working cross-functionally and certainly not focused on delivering the highest-value items first.

Hype: The statement, “The Kanban method is intuitive and is quickly and easily adopted by teams,” to me is a statement that’s used irresponsibly.  It is too often a battle cry of those trying to sell Kanban as a product.  It is the cop-out reason used by many organizations who are failing at Scrum and looking at Kanban.

In part two of this post we’ll continue the conversation about implementing Kanban and some of fundamentals that hold back Kanban and Scrum implementations.

Are you an engineer? If so, our society needs you to apply yourself to the global warming and other global social problems for the remainder of your life.

Just before the Holidays, an article I wrote ran in Fast Company on the call-to-action I believe all engineers need to embrace. Read the article, “Engineers: Why Aren’t You Doing Work For Good?“

Is this a calling that resonates with you? Do you think it’s feasible? If so, how can we get there? I would love to hear from 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.

As it is that time of year, odds are pretty good that you’ve happened upon the Frank Capra holiday classic, “It’s a Wonderful Life.”  Between that, “A Christmas Story” and “National Lampoon’s Christmas Vacation,” it’s a wonder there’s anything else on TV during the holiday season.  I do consider myself a fan of the movie, but that probably has more to do with my appreciation for James Stewart and the funny way he talks than it is for anything else.  Stuttering Jim aside, the movie definitely has its milestone moments, and probably none as culturally indelible than when little Zuzu, upon hearing the ringing of the Christmas tree ornament bell, sweetly states, “Teacher says every time a bell rings, an angle gets his wings.”

Every time a bell rings, an angel gets his wings.  While I’m sure that Clarence appreciated getting his due, I’m not really here to discuss campanology, nor its merits on signaling major life events amongst angels.  Rather, I was recently reading the December 2011 Wired Magazine interview with Jeff Bezos, founder and CEO of Amazon.com, and something he said struck me:

“Every time a customer contacts us, we see it as a defect.”

While certainly not as sweet and innocent as little Zuzu’s proclamation, Bezos’ version does hint at that same sense of childhood naiveté and idealism.  You see, what he’s really saying is that he wants Amazon to be a perfect customer experience.  Not just when a customer reports a missing order or something else unpleasant, but when a customer makes any contact, whatsoever.  In Bezos’ world, a perfect customer experience should be so intuitive, painless and efficient that the customer can barely even recognize that an experience has occurred at all.

It’s a bit of a paradox.  While we all want customers to use our specific brands of software and services, they’re only doing so to solve some other sort of problem.  I’m not using WordPress for the sake of using WordPress; I’m using it to communicate my ideas here to you. We spend lots of time and money building features to make it easier for customers to solve problems using our software. But the truth is, if we’ve really done our jobs right, the customer almost forgets that they’re using our specific brand of software and services to actually solve their problem.  The tool becomes invisible.  I don’t think of the power company when I turn on my lights; why should I think of Amazon when I use them to purchase my, “It’s a wonderful Life” two-disc collectors set DVD?  If the experience was perfect, their role in the transaction would be transparent and forgettable.

Long ago, I had a mentor who suggested that a good employee is one who makes himself indispensable, while a great employee makes himself redundant.  If your job is to solve a problem, and your charter is to make solving that problem as easy as possible – and if your goal is perfection – then at some point you’ll work yourself out of that job.  If our goal as software and service providers is to solve customer problems, and perfection is something we strive for, at some point we should become an invisible part of the equation.  While the idea of invisibility and redundancy may seem threatening, it shouldn’t.  If people can use our software to solve their problems with such ease that they don’t even consciously recognize that they’re doing so, how do you think they’ll feel when they use tools that force them to be aware?

While Zuzu had her rose, Bezos’ petals is the idea behind his words:

1. Focus on the details,
2. Expand your definition of quality, and
3. Never compromise

Striving for perfection may mean that you essentially become invisible. But that’s okay.  Customers may not recognize you when they’re using you, but they sure will miss you when they are not.

It’s almost 2012, a brand new year!  Being an eternal optimist, I am excited with what the year has to bring.  In a short time, the holidays will be officially over and it will be back to “business as usual.”  So as a final adieu, I’d like to offer a toast -

In 2012 may all your builds be good, and all your acceptance tests automated and passed.  May you continue to focus on innovation, quality and user experience.  And may Adrian Peterson of the Minnesota Vikings recover from his ACL and MCL injuries very quickly, as we really can’t afford to have our star offensive player out for the 2012 season over a stupid play from a game that didn’t even matter… er, well Happy New Year!

A new pony, iPad, or driver would be great, but let’s keep jolly old Saint Nick focused on agile.

I’ve interacted with companies large and small, and people from entry-level to the executive ranks about their agile intentions.

Here are the Top 5 ‘Agile Adoption’ ideas that I’d like companies to consider in 2012 (let’s call it an early Christmas present):

1. Start small. Agile methodology doesn’t need to be a scary, hairy, intimidating concept. Change is hard; yet there’s a way to start with one project today.
2. Ask around. More than likely there’s a colleague in your office who has practiced scrum or Kanban in his/her professional career. Ask that person how he or she got started.
3. Understand that ‘lack of control’ is a myth. If done right, agile adoption brings you, your team and your organization unparalleled visibility and transparency. Agile is not the Wild, Wild West. There are rules and best practices.
4. Team first. Your teams will like the collaborative, communicative culture that agile introduces. With everyone ‘in the loop,’ you’ll see high levels of performance.
5. Fail fast. Agile methodology, or any process for that matter, DOES NOT encourage failure. Agile does, however, allow the team to iterate and get to the best way to solve a problem, while learning from those paths that don’t meet objectives.

If you or anyone you know has an interest in starting an agile team or raising an existing initiative to a different level, seek out VersionOne. We can help.

Happy New Year!!

Yours in agile,

Dan Naden

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.

How many times have you found yourself facing the same problems of getting your team to work as a team, getting buy-in from stakeholders, improving your CI capabilities, understanding requirements,…? Agile development teaches us to stop trying to figure out all the angles.  Focus on the action, commit yourself, and act with purpose.

Recently, while flying home from spending time with a customer, I found myself knocking back a few cocktails (bourbon if you really must know), staring out the window and contemplating quietly from 36,000 feet.  As one is apt to do after having had a few drinks, I began reminiscing on my past.  You see, in a previous life I was a thespian.  That would be actor for all of you folks who spell it theater instead of theatre.  Anyhow, for much of my early life, I was almost completely immersed in acting.  I performed in dozens of amateur and professional productions, graduated from an arts high school and attended one of the most prestigious theatre conservatory programs in the country.  Somewhere along the way, as is typical for people in their 20s, my interests changed.  Although my wife still insists that I’m the biggest drama queen she knows, I haven’t stepped foot on stage in many, many years.  As this piece isn’t really about my penchant for melodrama, I digress.  Rather, the thing that struck me most on this particular flight was just how relevant one of the fundamentals of my acting training is to my current life in coaching, training and development.

In my time, method acting was the primary technique that acting students were expected to learn.  Famous method actors include Dustin Hoffman, Marlon Brando, James Dean, Sean Penn and many others.  For those in the know, there are really two main types of method acting.  There is the American Method and the Stanislavski Method, devised by Constantin Stanislavski, of which I was a student.  The goal of method acting is rather than simply pretending, the actor physically becomes the character by experiencing a psychological and emotional response based on the character’s circumstances.  What makes the two methods different is that while the American Method focuses on recreating the emotional and psychological conditions in which the characters exist, Stanislavski focused on creating the emotional and psychological conditions through purposeful physical action.  I realize that though the difference here may seem subtle, the application is profoundly different.  For the sake of argument, let’s say that you are asked to play the character of a recently widowed, elderly person who has lost his much beloved spouse of many, many years.  It’s the holidays, and even though you are still very much in grief, you are trying to reclaim some normalcy by decorating the Christmas tree.  In this scene, as you are unwrapping the tree ornaments from last year, you come across the very ornament that you and your spouse bought to celebrate your first Christmas together, all those years ago.  An almost overwhelming wave of conflicting emotion washes over you as you place the ornament in your hand.  You feel sadness for the loss of your dearest friend, loved one and confidante, while at the same time an intense joy over the memory of your life together.  With a tear in your eye, but the glimmer of a smile on your face, you slowly yet purposefully walk over to the tree and proudly hang your ornament for all to see.

If you were a student of the American Method, you would attack this scene by carefully drawing upon your own emotional and psychological memories in the attempt to place yourself in a frame of mind, similar to that of the character.  As a student of the Stanislavski method, your approach would be very different.  Rather than calling upon your own memories, or any memories for that matter, you would instead focus on how someone who was in that state of mind would move and physically act.  How would the character physically hold his head and move his hands as he unwraps the ornaments?  How would he physically hold his shoulders with the weight of the ornament in his hands?  How would he walk to the tree as he prepares to hang the treasured keepsake?  Stanislavski believed that by focusing on recreating the physical actions of the scene the actor would, through his subconscious, naturally create the emotions and psychological state of the character.  As any actor will tell you, this technique is incredibly difficult to master.  To this day I still fondly (although I couldn’t use that same word at the time) remember one of my acting coaches screaming at me to “Stop Acting! Just Do!” as I tried to think up the emotional state of the character.

By this point, I fully expect that most of you who are still reading are wondering what in the world does this post have to do with agile development.

Stop acting, just do!

How many times have you found yourself facing the same problems of getting your team to work as a team, getting buy-in from stakeholders, improving your CI capabilities, understanding requirements, etc.?  The list goes on and on.  Humans are funny creatures.  When presented with problems, we like to think about all the different ways that we could solve them, all the possible causes for them, and all the things that go wrong in between.  We feel a need to be able to cognitively understand and comprehend the situation, analyze our options and then attack.  The problem is that for most of us we spend far more time thinking than actually doing.

Stop acting, just do! That’s the idea of agile development.

If you ever see actors in rehearsal, you will know that they practice by repeating lines and sequences over and over again, making both subtle and radical changes in delivery, timing and intent.  They experiment with a multitude of variations before arriving at an approach that works.  This is inspection and adaptation at its finest.  While it goes without saying that the problems faced in software development are far different from preparing for another staging of “That Scottish Play,” the lesson is still just as valuable.  Agile development teaches us to stop trying to figure out all the angles.  Focus on the action, commit yourself, and act with purpose.  By doing so you will find that meaning and intent will emerge.  When the results aren’t exactly what we hoped for, change and try again.  The more time we spend doing, the more we will learn, and the more we will grow and improve.

Now, where can I find another one of those bourbons…

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.

Geoffrey Moore, a leading high-tech strategist and author of the bestselling Silicon Valley bible Crossing the Chasm, is speaking at Rally’s December 6th launch event. His new book, Escape Velocity: Free Your Company’s Future from the Pull of the Past, offers a pragmatic plan for established enterprises to move beyond past successes and drive next-generation growth from new lines of business.

We chatted with Geoffrey last week about the focus of Escape Velocity, his thoughts on how companies can capitalize on their portfolio of opportunities, and why he’s excited to speak at Rally’s Dec. 6 launch event. Watch highlights of our conversation below, and join us next Tuesday to hear Geoffrey talk about how established companies can create and sustain next-generation business growth.

Geoffrey is speaking at the first of three Rally launch events that bring together authors, technology thought leaders and industry peers to discuss how to bridge the gap between development execution and business strategy. Sign-up to join us in-person or via live simulcast:

• December 6, 2011, Menlo Park, CA, 9:00am – 12:00pm (PST)
• December 8, 2011, Boston, MA, 9:00am – 12:00pm (EST)
• December 13, 2011, Dallas, TX, 9:00am – 12:00pm (CST)

Tune-in to our December launch events to hear Rally’s big news on the future of portfolio management, and thanks to Geoffrey Moore for giving us a sneak-peek of his keynote.

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.

A while back I stumbled upon a clever blog post that showed the Top 10 of Top 10 lists and given my lack of creativeness today, I thought I would put together a Top 10 of Top 10 Agile Lists. I took this on and felt it would be an easy task given the amount that folks are talking and writing about agile. Well, it really wasn’t that easy, but I did find 10 Agile Top 10′s that are worth a read. Check them out, and please share your thoughts and links to other agile blogs that you feel are good ones:

#10 10 Misunderstandings About Agile Development. Written by the folks that maintain the Scrum Project Management blog, this is a clever and funny blog that tries to dispel some of the misgivings of agile. My favorites are “We do not want testers in Agile Development” and “Agile will likely be too chaotic to track progress.”

#9 Top Ten Agile Analogies. Damon Poole (founder and CTO of Accurev) is a funny guy without writing this blog, but he of course delivers with this one on Do it Yourself Agile blog. My favorite from this one is an anonymous quote, “Agile is like being pregnant, either you are or you aren’t.”

#8 10 Contracts for Your Next Agile Project. This is not really a top 10 list; however, it is a solid list of 10 contracting methods you can use if you are starting/contracting on a project that will be an agile project. It’s a good read and a constant question I hear while working with teams.

#7 Top Ten Organizational Impediments. This blog was penned by Craig Larman and Bas Vodde, this top ten list lays out some of the issues that slow or prevent organizations from successfully using agile as a software development process. Much of the list centers around the organizations that say they are agile but they are not serious about it. What I mean is that they are not aware of the commitment they must make.

#6 Top 10 Estimation Best Practices. I like to say that we make estimating way too complex; however, we all do it and we do make it too complex. This blog from Leading Answers (Mike Griffiths) takes a fairly broad brush and paints out 10 guidelines surrounding estimation. The best point made is “Agree on what ‘It’ and ‘Done’ Means”. This is where the conversations for agile requirements should be centered and estimation will be natural and easy.

#5 Top 10 Essential Product Owner Characteristics. Peter Saddington does a great job maintaining AgileScout, and he has done a good job helping to hone the skills of the ever important Product Owner role. This top 10 list does a great job spelling out those things to look for within a good product owner — the best one here is “Collaborative by choice.” To me, this characteristic is make or break when it comes to a good Product Owner.

#4 Top Ten Reasons to Love Agile Testing. This is a favorite list of mine. One reason is that a team that has embraced Agile Testing best practices is usually a successful agile team and the second reason is that it is a fun list.

#3 Top 10 Agile Development Traps. Found on BrainsLink.com by Vin D’Amico, this blog posting should be shared with all developers as part of their training and indoctrination to agile development. I’ve seen multiple teams fall into these traps.

#2 10 Agile Strengths. John Goodpasture writes a great positive blog about why Agile has worked for him. He stated that his first post about agile weaknesses went negative and I must say, you are not alone. A lot of folks write negative slanted blogs about agile and it was tough for me to find many positive top ten lists. I don’t get this because I see that when Agile principles are applied and used, the long-term results are positive. Nonetheless, thanks John for writing a positive top 10!

#1 Top Ten Things Programmers Hate About Agile. And to wrap up this top 10 of top 10′s, Damon Poole provides us the perfect satirical top ten to make folks reflect on why they think they don’t like agile. It’s a great list in that it pokes good fun at some behavioral aspects of developers/engineers which often lead us to dislike the fun change that Agile introduces. Nice job Damon

If you have a top 10 list to share, please post a comment and a link.