Agile Development Blog

In a continuation on my last post on Eric Ries and The Lean Startup, I wanted to share how these concepts continue to ripple through Rally. (Learn more on how to apply these topics in your business at our upcoming in-person and virtual Portfolio Management Roadshow featuring Eric alongside an awesome line-up of speakers.)

Three weeks ago while in Denmark, I had a deep dive with customers on the topic. While in Copenhagen Denmark and talking with 40 European customers at Rally’s Agile Open Forum, one of the top 5 questions that group proposed was:

“How can we develop features that give the maximum long-term value and the minimum long-term cost?”

Vist Custdev.com for this "Cheat Sheet"

I believe you will find the answer to this question in Steve Blank’s customer development approach to differentiating new products or simply in the build-measure-learn cycle of Lean Startups. For Agile teams that can already build right and build fast, this answers the question of what to build!

By focusing on the concept of creating “validated learning,” a Lean Startup team does not provide solution development teams stories that are not validated or constructed to validate a hunch.  As such, the Agile backlog becomes prioritized by learning and risk.  The result is a team that couples Agile product development cycles with customer problem discovery and customer solution validation. What is great about this approach?  It works at the whole business or product-line level, and you can also slim this down for use with A/B testing of enhancements too. Your level of application only depends upon your scope as well as the scale and maturity of your Agile efforts.  The more Agile your enterprise is the more leverage you can have with these techniques.

The result of this work allows you to determine, if there is desirability for this solution before you commit to ship it.  As a result of understanding the intersection of feasibility, effectiveness and desirability, you can be sure to deliver features that have maximum value.  And, by working with a minimal viable product (MVP) concept, you can be sure not to overbuild that solution too.  In this way you can be sure to build the features with maximum value and minimal long-term cost.

To me, Lean Startup is a method to drive continuous innovation and brutal, entrepreneurial prioritization. But taken to the extreme, Lean Startup is a way of being and acting and can become an attribute of culture. In addition to speaking and teaching on the topic, we have had some customers and partners come to learn, teach and do with us. The following efforts demonstrate how these activities can become cultural.

Act like a scientist, not a fire fighter

In a tradition of Lean companies, we had one of our largest customers come visit our office in early October.  He and his company have adopted and scaled Agile very well.  Now, they are focused on creating validated learning to do concurrent set-based development on their toughest problems. He pointed us toward this HBR Article on Decoding the DNA of the Toyota Production System.  You will notice the Lean rules and principles from Toyota support the Lean Startup approach.  This customer’s hope was to share his learning to help make us a better partner.  His trip was a true gift.  Thank you, Pat.

Two weeks prior to our customer visit, our friends George Kembel and Scott Dorsey, from Stanford’s d.school were here in Boulder. The principles and method of design thinking are clearly wrapped into the Lean Startup.  In design thinking, the iterations include practices to empathize, ideate, prototype, and test/reframe. Typically, these cycles are used to create the initial design of a new product or service, but not at the d.school. In the d.school, students take these concepts into more of a continuous cycle to help shape emerging services or social startups. Like Lean Startup, the d.school is learning to run people and teams through fast and continuous cycles of build-measure-test to create a “continuous innovation to create radically successful” efforts.

In a serendipitous way,  I taught a seminar on customer development and business model canvas approaches to fellows at the  Unreasonable Institute.  In September, Zach did a crash course on “Why Lean Startup Approaches Work” for 120 folks at the Silicon Flatiron’s portion CU Law School and Boulder/Denver New Tech Meetup.  Like my first post said, it has truly been Lean Startup everywhere at Rally.

If this post was not concrete enough for you, my final Lean Startup post is on “How to Apply Lean Startup to Your Agile Rollout.”

Ryan Martens is CTO/Founder of Rally Software, a recovering Entrepreneur-in-Residence at the Unreasonable Institute and chief promoter of the Entrepreneurs Foundation of Colorado. You can follow him on Twitter @RallyOn.

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

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

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

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

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

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

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

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

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

Ryan Martens is CTO/Founder of Rally Software, a recovering Entrepreneur-in-Residence at the Unreasonable Institute and chief promoter of the Entrepreneurs Foundation of Colorado. You can follow him on Twitter @RallyOn.

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

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

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

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

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

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

Ryan Martens is CTO/Founder of Rally Software, a recovering Entrepreneur-in-Residence at the Unreasonable Institute and chief promoter of the Entrepreneurs Foundation of Colorado, you can follow him on Twitter @RallyOn

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

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

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

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

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

What is top of mind on this topic for you?

Ryan Martens is CTO and founder of Rally Software, a recovering Entrepreneur-in-Residence at the Unreasonable Institute and chief promoter of the Entrepreneurs Foundation of Colorado. You can follow him on Twitter @RallyOn.

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

Along with our Project Stratus initiative (see our Scaling Agile to the Strategic Level blog series), Rally Idea Manager is a big piece of Rally’s goal to extend agility outside of development and into the enterprise.

Traditional ways in which product management collects user input – customer visits, enhancement request forms, homegrown systems, and commercial product management tools – tend to fall apart as development goes Agile.  Agile teams are hungry for user input as their frequent delivery schedule calls for fast feedback loops to continuously influence development.  Agile teams know it’s important to build things right, but making sure they build the right things requires product managers to engage quickly with customers around the world.

Product managers have another challenge in our competitive world — they can’t just take feature requests at face value. True product innovation comes from understanding the WHY behind feature requests. Rally Idea Manager is a social site specifically designed for actively engaging users in frequent conversations and getting to the WHY.

Rally Idea Manager was released a year ago to help product managers effectively prioritize their product backlogs by increasing the understanding of users’ needs. Powered by our partner Brightidea, the leader in ideation and innovation systems, Rally Idea Manager is honed for product marketers and product managers working with Agile teams.

That launch was a result of Rally’s own Agile product management experience. When I started at Rally in the summer 2007, we had just launched Agile Commons with a “Feature Requests” hive to discuss product ideas. Three years later (last October) we adopted Rally Idea Manager, and branded our site “Rally Ideas.” With Rally Ideas, we have been learning how to effectively leverage a user community to drive innovation in our products and to account for user input into our brutal prioritization process.

This month, to celebrate the first anniversary of the Rally Idea Manager launch, we released a bunch of added value for product managers to keep their user community vibrant, including things like:

• A user reputation system and leaderboard: to monitor and incentivize user participation in the community
• Customizable idea tabs: for users to easily locate their favorite ideas and for product managers to highlight special features in this week’s discussions
• Improved search: to minimize the creation of duplicate ideas
• Rally integration enhancements: to link new ideas to existing Rally stories and update idea statuses based on any Rally story states
• Better idea status change notifications: to keep users informed of specific status changes
• A “idea interest report by company” report: to better understand the specific needs of a given customer

The below demo highlights some of the new additions. To learn more, read the Product Blog from Rally’s site owner, who is blazing new trails with our own deployment of Rally Idea Manager (Rally Ideas), so we can improve the offering for you to engage with your own end-users.

And because launching a user community site is new to many organizations, we decided to consolidate our 4 years (and counting) of learning into a 2-day workshop where you can learn how to set up your very own Rally Idea Manager site. The workshop covers how to setup your site (frankly, that’s the easy part), how to market your site, who to involve in your organization and how to keep your site vibrant so user input keeps flowing into product backlogs. Interested? Contact rim@rallydev.com for more information.

Catherine Connor is a Product Marketing Director and product owner for Rally Idea Manager. She loves Colorado summers (which finally arrived this year), for all the camping, hiking, biking and sailing opportunities!

This is a story of how I went from being the poster child for bad posting etiquette on pm.stackexchange.com to becoming their poster child for fast learner! A poignant tale of hubris, struggle, fear, benevolent mentorship, and redemption.

Prequel: The Lure

Some colleagues of mine at Rally Software (Karl Scotland, Ken Clyne, Eric Willeke, Ben Carey, and Ryan Martens) have been telling me about how much they were enjoying their experiences in StackExchange. My CTO colleagues Zach Nies and Mark Gammon have also been enthusiastic about the value of being engaged in the StackExchange community. But I was intimidated. I feared I wouldn’t know how to appropriately engage in either asking a question or answering a question. It turns out my fears were well-founded.

Scene 1: The Leap

I finally decided to jump in. I set-up an account, fairly easy to do. I perused some of the questions already posted by others. I saw the tags and the replies. I saw the voting. Somewhat intimidating. But, I had a topic I was really excited about. I thought it would make a great question. And so I made the leap; I took the plunge. And this is what was wrought:

Scene 2: The Faux Pas

Not a bad question. The problem was that in the text area below the question title, I gave further detail on the question. A lot of detail. I pulled a major faux pas: I waxed poetic on what I thought the answer was. (I’m not going to go into the topic here. Trust me. It was lengthy and unyielding. :-(

Fortunately for me, however, very timely and gentle advice appeared from Mark Phillips and jmort253:

Could they have been any nicer? What a great community!

Scene 3: Meeting with the masters

The good news is that help was on its way. Back in March, we’d spoken with Joel Spolsky (co-founder and CEO of StackExchange.) Ryan’s goal in talking with Joel was to look at how we at Rally could incorporate StackExchange into our upcoming RallyOn conference in May. How could we work together to create community in StackExchange as we were creating community in the conference?

The result? We brought in the great StackExchange masters Anna Lear and Mark Phillips to the RallyOn conference. In his opening remarks at the conference, Ryan introduced our two Zen StackExchange masters and Ryan’s hope for how we could all engage with them to kick start a powerful presence of the Agile community within StackExchange.

Yea! I was going to actually be able to work with Mark and Anna to become more comfortable and more productive in StackExchange!

Scene 4 : Lessons Learned

After Mark held a small session on getting started in StackExchange, I saw him in the hallway. I’d missed the session, but he quickly filled me in. It turned out, he’d used MY question/answer fumble as an example of how NOT to engage in StackExchange. I had become the poster child for bad StackExchange etiquette :-(

But both Anna and Mark quickly took my under their wing. We edited my original question. We commented on one of the answers. We created a new question. And we answered another question. The result was a new exchange of comments:

Close: A Happy Ending

Today, good news abounds. Mark recently wrote a phenomenal blog post: Why StackExchange is Hotter than Twitter

I continue to stay engaged asking and answering questions. I’ve learned to keep my questions short, my comments short, and my answers short. And, I’m gaining reputation points and earning badges, still with gentle guidance from Anna, Mark and “jmort253″.

My Rally colleagues continue to post as well. It is exciting to see the Agile community begin to expand in pm.stackexchange.com. Provocative questions with great answers. And through the tags, we can watch the expansion into other topic areas.

For the happiest ending of all, I’m saving the best for last: my email yesterday from StackExchange!

“Congratulations — you are one of the top new Project Management – Stack Exchange users for the month of May 2011! http://stackexchange.com/leagues/month/pm/2011-05-01 ” There was also the caveat that my name would not appear in the list of users because I still need to earn more reputation points. Okay, June, you are going down!

Help keep the story alive!

To wrap things up: I not only survived jumping into StackExchange; I love it. I’m hooked. So, my story is not over.

Now, I’d love your reply to this post to tell me how you are getting involved in StackExchange.

Jean Tabaka is an intrepid intercontinental traveller, a 6-badge holder in pm.stackexchange.com,  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.

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

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

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

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

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

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

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

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

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

Last week, 10 of us from Rally product development, sales and coaching attended the Lean Software and Systems Consortium’s 2010 conference in Atlanta.  For me, the learning highlights of the conference were in the Systems Engineering track  led by James Sutton. To kick-off his talk on Lean Systems Engineering, James used a number of compelling stories around different systems and what guide them.  As part of his introduction to systems, he played this hilarious Dave Snowden video about how you plan or act based on one of 3 systems in which you might find yourself -- Chaotic, Ordered and Complex.

David Snowden -- Cognitive-Edge -- Ways to Plan a Party

James, a Systems Engineer, Principal with Lockheed Martin, is an invested member of the Lean SSC board as well as a technical advisory member.  He is the deepest expert that I have ever met in the field of systems engineering. And he has a wonderful gift for bringing multiple resources to bear in helping people understand and care about systems. For a Civil Engineer and Computer Science major like myself his talk and track were the definition of a prop-spinning geek nirvana.

Systems are guided by the pressures that form them

The point of view that James imparted on us was to understand that there are fundamental systems in which we operate. They are not value-based; one is not better than the other. They just help us set context and inform us about the world around us. Why should we care about this? How you approach your product and project development depends on which system  you find yourself in. And, as it turns out, the system you find yourself in is largely guided by one of four compelling pressures. That is, you will recognize the system in which you operate based on what is driving you to act.

There are four fundamental pressures that guide us: abundance, scarcity, desperation, or conformity. And each leads to a different system context. To illustrate this, James led us through the story of four different nations following the second World War.  Each nation, responding to different drivers, led to advances in different types of systems management approaches in use today.

• United States -- Abundance -- Systems Engineering

• Japan -- Scarcity -- Lean

• England -- Desperation -- Chaos Theory

• USSR -- Creativity and Conformity -- Patterns of Inventiveness
  

The Four Systems

Given this sense of what guides particular systems, James explained that we live in a world of four fundamental systems: Simple, Complicated, Complex, Chaos.

Cynefin

Once you recognize what system you are in, you discover what principles and practices will best serve you in that system. But systems tend to not be static. So, James presented what agent or pressure might cause you to move to a different system and therefore what tools and practices would guide your thinking and actions for transition.

For instance,  if you are in a Simple system and are moving into a Complicated system, Lean Manufacturing and Analytical Systems Engineering are your best tools and guides. If, however, you are in a Complex system verging on Chaos, you’ll work best relying on the perspective originated by Dave Snowden: Cynefin, the Welsh word for “the place where you hold multiple things.” Cynefin serves Complex systems well as it emphasizes emergent behaviors and, what Snowden refers to as “sense-making.”

The history and vision from this talk became almost a grand unifying theory for me. It all made great sense. If you are a  systems engineering fan, do not miss the recorded version of this talk when it becomes available.

Thanks Lean SSC

While 6 speakers and several attendees from Europe were prevented from attending the conference due to the Icelandic volcanic ash cloud, the Lean SSC rolled with the punches and pulled off an excellent event. The folks able to attend and the over 40 sessions offered created an electric buzz both in the air and on Twitter. Given the caliber of sessions, hallway discussions, and Open Space,  I am sure there will be many posts that emanate from attendees. And no doubt new ideas will be growing that were nurtured by the conference. Kudo’s to the Lean SSC board for creating a space for this excitement and emergence.

About the Authors:

This week, I had the pleasure of attending the seminar “The Way of Artful Making” presented by Rob Austin and Lee Devin , co-authors of the book “Artful Making”.

While I have met both gentlemen separately in the past and heard them both speak, this was one of those golden moments when I was able to hear them co-present. And for me, I loved the odd mixture in the audience: MBA students, MFA student actors, and software engineers. (Okay, guess which group I was in?)

Lee and Rob have a great “pairing” style in presenting. For those of you who don’t know them, Lee is a professor emeritus in Theatre from Swarthmore College. And Rob is a former associate professor at the Harvard Business School and is now full professor at the Copenhagen Business School.

In co-presenting, Lee and Rob take turns applying their perspectives about the look and feel of artful making. For Lee, this is about life in the theatre. For Rob, this is about great product development and, in particular, software development. So two great tastes that, as it turns out, taste great together (sorry, a reference to an old candy advertisement :)

So, what do actors and programmers have in common? Well, some amazingly fundamental things as it turns out:

• Iterative work
• Collaboration
• Innovation

Theatre work and product development both thrive on iteration and collaboration. Lee described this in terms of rehearsal and the emergent look of a play leading up to and even after opening night. Rob affirmed the value of a collaborative and iterative approach in product development and provided videos from Boeing and Bang and Olufsen showing how both companies take advantage of this approach.

What do these practices have to do with innovation? Well in both theatre and product development, Lee and Rob encourage us to embrace what should be the glaringly obvious; that is, iteration and collaboration invariably produce innovation .

What happens when you put iterations and collaboration together? Rob introduced us to a term he had learned during his study of Boeing’s use of iterations: “try-storming”. That is, instead of just brainstorming ideas (whether in theatre or in product development), take your brainstorm and try it.  Find something out about it as soon as possible. Then “try-storm” the next idea. (I think I am going to have to steal that term from him!)

I was also very fortunate to be able to sit next to Pete Behrens of Trail Ridge Consulting during the evening. Talking with him afterward, he reminded me of a few more similarities between theatre and product development:

• You need to be able to surprise people in order to create value
• If you don’t know in exact detail where you are going, it’s okay
• The ideal play/product you hold in your head is very limiting; let go of it
• In iterations, like rehearsals, each iteration may be or even will be significantly different from each other
• We’ve been able to move to being more iterative these days, more Agile, because of technology making it cheap enough to iterate
• Nothing is lost and wonders never cease as we build up each iteration from all the iterations before

Artful Making through iterations, collaboration and try-storming—all are important if you intend to be a theatre or product development organization that is truly innovative in the 21^st century. And THAT is what actors and programmers have in common.

About the Author: Jean Tabaka is a wine enthusiast, author and Agile Fellow at Rally Software Development. Subscribe today to get free updates by email or RSS.