Agile Development Blog

(Creative Commons D. Sharon Pruitt)

On this last Friday of 2010, I thought I’d try to get a quick “One Hit Wonder” in before the horns toot and the bubbles flow. And maybe these New Year traditions are apt images for my topic today. I’ve been thinking about what we do for the New Year and what we do for Agile. We like to scoop up information to help us figure out what we can best do next. On New Year’s Eve we sometimes call that “resolutions” for the next year. Ugh. Not my style. Rather, I’d like to think about intentions. So bear with me as I reveal my style of  “inspect and adapt” for my personal New Year:

Accentuating what is positive and whole is best

Years ago, a friend of mine had told me about how she prefers to reflect on the last year. She has a way she moves into the New Year, answer three questions:

1. What will I let go of that has drained me or perhaps has caused me to feel guilt or shame?
2. What will I choose to continue to do, those things that energize and delight me?
3. What new things am I prepared to invite into my life to help me to continue to let go and grow?

I like this metaphor for Agile teams as they retrospect from iteration to iteration, or from release to release, or even year to year. I like paying attention to the positive.

1. What has not worked for us, caused us angst or distress whether in our process or our technology, that we are prepared to let go of?
2. What do we choose to continue to embrace about our work as we move forward?
3. And, what new practices or agreements are we prepared to invite into our team or with our stakeholders that will help us to continue to grow and improve?

Start simply: where you are

So for me, I start today, here, now. I could think about how I have seen my life from day to day. I can watch how my life has unfurled from week to week or month to month. Using appreciative inquiry, I can take what has brought me the greatest delight and pride and then look at what was happening when that occurred. And then I can choose to replicate those circumstances, sort of like what our guest blogger Lee Devin refers to as “Planning to Get Lucky”.

For Agile teams, we can apply this philosophy each time we demo functionality to our customer, whether at timebox intervals or as each new function or minimally marketable feature is completed. We’ve learned. These demos, often on a Friday afternoon, lead us to inspect and adapt. These demos also feed the team and the customer. We all learn. AND, we do this through the pride of completing working functionality.

I believe in the humanity and delight of this form of retrospection. Do you see why I shirk New Year’s resolutions? Instead, I look for the accomplishments that have helped me grow and move forward. Agile teams, through their demos and reviews invite the same.

And now for our one hit wonder!

I am thinking of a song that accentuates the positive, invites us to let go of what may be drudgery and to plan instead to get lucky. Oh the metaphors!

Thanks in advance to Wikipedia for helping me fill in the tale of our one hit wonder. The band (yes, not a solo act this time) started with a husband-wife team who then added another male/female contingent. The album that held their #1 hit song actually did quite well on the charts. And this was 1976 when you could buy songs as single 45 records (no, single MP3s were not yet available ; -).  The band received two Grammy Awards that year, “Best Arrangement (voices)” and “Best New Artist”. And yet two subsequent album outings not only produced no new hits; the husband and wife team were soon divorced. Oh the tragedy of it all after such success from a song that you can still hum today.

So what is our One Hit Wonder this last Friday of 2010? We’ve got Starland Vocal Band and their great tune with which to say, “Happy New Year, dear readers!”

Jean Tabaka is a snow shoveler, crash skier, author and Agile Fellow at Rally Software Development. You can follow Jean on Twitter at @jeantabaka

Question: what do Neil Young, Simon Sinek, Don Reinertsen, and Jean Tabaka have in common? We all want to know why.

Several weeks ago, we introduced a new blog series “N Levels of Planning”. Our goal in this series is to investigate how Agile planning can benefit from thinking of planning as a number of levels, or layers, or paths. In this series post, I’d like us to take a conceptual step back from what we mean by “N”. I’d like to instead think about the “Why” of Agile planning regardless of the number of levels.

The Neil Young Connection

Warning: minor non sequitur. In 1970, Neil Young released his “After the Gold Rush” album featuring as its first track the great tune “Tell Me Why”.

Love that song! I had this song buzzing through my head after a discussion with colleagues about “Why.” Lyrics like: “Still the searcher must ride the dark horse, racing alone in his fright,” and, “Tell me lies later.” What can it mean?! What is there that is so important about starting with “Why,” and to ask it repeatedly? What did the Neil Young of yore get about the searcher, the dark horse, and the race that I needed to revisit now? And what does it have to do with Agile planning?

The Reinertsen Principles

I had some suspicions after reading Don Reinertsen’s “The Principles of Product Development Flow” that the “Why” is indeed what should be driving our Agile product development. In his book, Reinertsen exhorts us to inform our decisions about product development by starting with value flow. You may call this stating the glaringly obvious. For me who had been handily sticking to the “How” and “What” in my computer science expertise for decades, this tumbled several of my false idols. Ugh.

Simon Sinek’s Golden Circle

Recently, several colleagues here at Rally pointed me to a great TED talk: Simon Sinek’s “The Golden Circle”. If you haven’t watched it, take a gander. Sinek’s very simple model consists of 3 concentric circles, the innermost being “Why”, the outermost being “What” (See the picture above of the turquoise post-it.). Sinek defines successful businesses as those that start, not with “What” or “How”; they start with the core “Why”. This articulation of the “Why” rallies the business around one compelling vision and creates a vital emotional connection with its customers. “How” the company delivers on the “Why” follows from and is directed by the “Why”. Then and only then does the business move out the circle to the “What”. What exactly will our product be? Well, we know why we are building it, and we know how to deliver on this. Now it is time to build it!

We missed the “Why” boat in our initial Agile scaling advice

I was thinking about Sinek’s Golden Circle with regard to how we plan in Agile teams and Agile organizations. Too often, we have a tendency to start with  “What” as the core for our planning. If we are really maverick, we may start with “How”. Too often, I fear that our planning “Why” is conspicuous by its absence. I am fairly certain Ryan Martens and I fell into this “What” trap when we defined 5 steps for Agile scaling and maturing using Flow, Pull, and Innovate. Why were we defining how to scale and mature should have been the first question? And then How shall we do that? Okay, we did get the How: we turned to Lean Thinking principles about Flow, Pull, and Perfect (which we renamed Innovate) for guidance. And then we quickly jumped to What the practices are: 5 steps of what to do, what roadblocks to expect, what benefits to reap.

Agile planning levels need to start with “Why”

This is what I now believe to be true. Just as businesses must be driven by the “Why”, I believe we must consider the “Why” that drives any of our Agile planning. My hope is that we in the Agile product development world would come up with a fairly common answer for “Why”: smooth flow of value delivery. Period. Our “How” can be informed by the set of principles we believe would best address our “Why”. We can turn to Lean Principles as a great guide. Here, I’ll admit I favor Reinertsen’s principles of product development flow as the canon for “How”. We’ve got the “Why” and the “How” for our planning. Now we can declare our “What”: what will be our planning practices in our Agile organizations?

How Jean Tabaka fits in

With “Why”, “How” and “What” as our planning guide, there is one more beautiful gift of symmetry across Neil Young, Don Reinertsen, and Simon Sinek. Not only does this virtuous Golden Circle guide overall planning. I believe that within each of the “N levels of planning”, we can see that there is a “Why”, “How”, and “What”. Here is an example: “Why should we have a daily level of planning?” “How should we guide that planning, i.e. how would we know we were doing a good job of planning at this level?” And now, “What will our practices be around daily planning?” As we regard levels of planning as not just sufficient but necessary, we turn back to the “Why”, find guidance from the “How”, and then create the useful “What” practices.

Back to Neil Young’s “Tell Me Why”. I think we can avoid “riding the dark horse racing alone in fright” if we start our planning with a compelling “Why.” And, with thoughtful  “Why”, “How” and “What” levels of Agile Planning, I believe that we can avoid the “lies later” as well.

This is what I believe. What do you believe?

Jean Tabaka is a crash skier, sometime poet, author and Agile Fellow at Rally Software Development. You can follow Jean on Twitter at @jeantabaka

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.

Our medium fidelity prototype has the bugs shaken out and we’ve ordered 30 T-walls and an overhead power and data grid for our new engineering, operations and support space. To help you and your team down a similar path, I have attached the plans that we had drawn to manufacture our magnetic board walls on wheels. Click on the image for the PDF.

Back in the summer and based my visit to the Standford DSchool, I started talking about the innovations in furniture that I had seen in that space. In Fall, we had a space hackathon with the local team from RightNow and George from the dschool. As a result of that work, we built some T-wall prototypes and started trying different power management strategies.

What was amazing was that the day after we had the T-Walls delivered, a new product development team moved in; as the core engineering teams split from four teams of 9-10 to 7 teams of 3-5 people. It was the perfect validation and a great “earlyvangalist” customer to help us develop our final solution for scale in our new space. (More on “earlyvangalists” on Monday’s blog post – stay tuned.)

Ryan Martens is an epic pass user, CEO of the Entrepreneur’s Foundation of Colorado, and CTO at Rally Software Development.

Of course!

Back in October, Rally started a project led by Craig Lagenfeld, one or our great Technical Account Managers, and Dean Leffingwell, see more on Dean below, to take the FUD (Fear, Uncertainty and Doubt) out of this application of agile methods.

If we hit this out of the park, we will be delivering guidance to the Agile Community that describes the best practice for developing high assurance software in highly regulated environments. The primary guidance will be a detailed “how to” whitepaper that will include examples of organizations who are already utilizing one or more of the practices and tools that we describe. Other deliverables will include a blog series, webinar, and tool validation guide. In short, the Agile Community will change their question from “can we utilize Agile to create high assurance software and still be compliant” to “how soon can we get the process and tools implemented to take advantage of Agile”.

Now two months into the project, we are trying to broaden the audience and collaborators for this work. We’re excited about this project and the great feedback we are getting from the Agile community. The blog series is generating a lot of interest, with people either wanting to know more or offering to contribute. Heck we even have quite a few emails from the Compliance Community wanting to help us out. Keep the emails coming- or better yet, start directing all of your support, questions, and feedback to the blog posts (and comments on this post) so that we can keep this building in a public forum. In the end Dean and I plan to deliver much more than a series of blog posts. We want to deliver guidance that Rally customers and Agile Practitioners can use to educate themselves and their organization.

The purpose of the project is to bring together Agilists who know that Agile is a better way to produce safe, reliable innovations but are unsure of how to accomplish this within a highly regulated environment. In our second post, Dean and I decided to use medical devices as the focus of our work, providing real examples of how medical device companies are confidentially using Agile practices today (see our recent posts on Abbott Labsand GE Healthcare). My part in the project focuses largely on ensuring that we provide a best of breed tooling suggestion to support the process that Dean and other experts in the field are developing. – Craig Langenfeld

Dean Leffingwell is a great friend, author, and entrepreneur. Before starting Requisite, the orignal makers of Req Pro, Dean ran a company called Rella that manufactured medical devices. Not only does he know software, agility and lean, but has many stripes from medical device certification and compliance. We are thrilled to be collaborating with him again; if you do not know his work, he is the author of Scaling Software Agility: Best Practices for Large Enterprises and the soon to be published Agile Software Requirements: Lean Requirements Practices for Teams, Programs and the Enterprise.

Again, if you are in this field please join Criag, Dean and your peers in the High Assurance and Regulated category of Dean’s blog.

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

Craig Lagenfeld is a Technical Account Manager at Rally Software Development.

Dean Leffingwell is an entrepreneur, executive, author and consulting methodologist.

In “The Design of Business“, Roger Martin talks about businesses that find an algorithm and just stick with it. They exploit it and never really dare to explore new ideas or ways of doing things. Sort of like a one hit wonder. You just live off the royalties of that one great idea.

What’s a one hit wonder?

My colleague Mark Gammon and I were talking about Martin’s book and this phenomenon and decided it was time for a “One Hit Wonder Friday”. A one hit wonder is an artist, singer, or group who has made a hit, a really big hit, and yet has not been able to do anything else that really grabbed the public’s attention. Given that the one hit wonder Martin describes in his book is one I’ve loved for a while, we decided to kick-off our Friday series with his example. Here’s who we have in mind: someone who has a song pretty well known even though it is quite old. And yet, the artist (okay, that’s a hint, it is one person) never explored or expanded. It turns out he (okay, it’s a male), has been doing okay living off his royalties. But before we reveal further clues about our artist, first back to business.

Are you living off the royalties of your business “one hit wonder”?

Businesses can end up being one hit wonders too. They find that one “song,” that one big idea, or that one good process and believe they have to stick with it in order to be successful. This is the stuff of bureaucracies. The sad fate of business one hit wonders is that they just aren’t built to last. The idea either dies out or is bought out. One thing for sure, with business one hit wonders there is no room for chance or growth; that is too dangerous.

For your business to avoid the doom of a one hit wonder, you’ll have to challenge yourself continuously in process improvement, in product visioning, and in knowledge sharing. You will have to invite the discomfort of exploration and the unknown. Accepting and embracing the ambiguity of whether you will be a hit or not is not easy. But, as in the Agile world, with frequent feedback and delivery in small batches, you can make quick adjustments through heuristics that set you on  your next big hit.

Back to our “One Hit Wonder Friday!”

Here are a few facts about this week’s one hit wonder (thank you Wikipedia):

He’s a Massachusetts boy, born in the 1940′s. He studied music at Boston University (ah, that paid off :-) Using some of the proceeds from his one hit, he landed a farm outside of Petaluma, CA. So all is not bad for our one hit wonder!  The song itself is remarkably recognizable given that it came out back in 1969-1970 and sold over 2 million copies during that time. (Again, what an algorithm to stick with!) To our one hit wonder’s delight, it has been re-made a number of times, including by the great all girl punk band Fuzzbox (Hint: yes, there is a connection between the term fuzzbox and our song.) This is really good stuff :-)

The song itself had a combination of a sort of spiritual and hippie feel using heavy guitars and hand-clapping. Our artist wrote the song in 15 minutes as his own version of what he thought a gospel song could be. And finally, Rolling Stone rates the song #333 in its top 500 songs of all time.

So who is our one hit wonder this week?

Jean Tabaka is a crash skier, author and Agile Fellow at Rally Software Development. You can follow Jean on Twitter at @jeantabaka