Tuesday, December 10, 2013

Learning against my will. Oh, and there was this Lean Startup Conference thing...

Sometimes this learning thing isn't all it is cracked up to be.

Take today's example. I found myself down at the Miller Business Innovation Center to watch their local webcast of the Lean Startup Conference happening this week in San Francisco. I was all set to settle in, have a couple epiphanies, and then I'd be able to knock off for the day with a new "I learned something" badge earned.

Wrong.

I put at least some of the blame on Alistair and the Salt Lake Agile Roundtable gang. It was from them that I picked up the habit of a) always be ready to articulate at least one learning moment from any learning event, and b) actually write down your learning moments so they are reinforced at the moment they are strongest.

I knew I was in trouble about 5 minutes after the first session started. It was Kathryn Minshew - "Getting Users Out of Nowhere". Normally I'd coast through topics like this with my mental cruise control on. Not because they were not interesting or relevant. They are. But that's not an area I've often been at a loss for ideas, so I hadn't pursued learning more.

Well, you know the universe loves moments like this. Or at least the universe that I inhabit certainly does. Since I'm a fan of Norse mythology I can picture with amazing clarity Odin sharpening up Gungnir while Thor is off to the side giving Mjolnir a last bit of polish while glaring in my general direction.

Ok. Maybe it wasn't Gotterdamerung. But what did happen was that a part of my brain that doesn't like the mental cruise control slammed on the brakes and said "Hang on! Did you hear that?!?"

In this particular case it was Kathryn's discussion of how to become your own PR machine. Upon hearing that I dutifully recorded the "aha" moment (yes, it's below if you really want to know). With that aha safely recorded I patted myself on the back and prepared to settle back into cruise control.

Never got there. That same part of my brain that slammed me out of cruise control said "What if she said something else interesting before this?". Muttering vague obscenities under my breath I called up my mental playback department to find out if there had been anything else interesting that I had missed the first time through.

And of course there was. The other tidbit was about making it insanely easy for others to engage in word of mouth advertising for you.

After admitting to myself that I had let a learning moment actually slip by there was no chance that I'd be able to descend back into mental cruise control. I was saddled up for the full ride.

And what a ride it was. I recall actually being irritated by the end of the webcast at the audacity of the conference organizers to schedule that many impactful sessions in a row. What ever happened to tossing a few stiffs in there so you could have time to wander over to the mental dressing room to see how well the new ideas fit?

I'm glad to say my irritation was short-lived. Yes, the learning experience had a lot to do with my mood alteration. So did this parting shot from my mental brake-slammer:

 "Gee, you're not getting OLD, are you? Only OLD people stop learning"

In case you thought you were going to get out of this blog entry without having to hear me blather on about the actual things I learned (or re-learned), think again.

I will give you this warning. Context counts in learning moments. If you don't have a shared context for the new idea it will not have the same impact. I'll do my best to convey context but I can promise you that whatever I have to say will be no substitute for you to have your own learning experience from these presentations. Hopefully they will be posted publicly at some point so you can if you missed the conference.

What I learned (or re-learned) today from the Lean Startup Conference:

Kathryn Minshew (The Muse) - Acquiring Your First Users Out of Thin Air

  • "Ask for word of mouth from your customers and make it insanely easy to do". It was the insanely easy part that got me thinking.
  • "Tell a good, clear, easy-to-report story". When you're working with bloggers / news outlets to get your message out stories are much more effective than data or marketing statements. Those stories should whenever possible relate to current events / trends
  • (Regarding her advice to offer to write posts / articles for blogs and news outlets) "Harvard Law Review rejected my offered stories for a year before they accepted one. Persistence matters.
Alexis Ringwald (LearnUp) - How to Build the Product When You're Not the User
  • Her team spent 5 months visiting people in unemployment lines learning what the people there needed.
  • Having a "Contact Us" button was not enough - they built a way to stay engaged with their users.
  • The whole team recently took a field trip to Mendota, CA (39% unemployment) to continue to learn about what was and was not working.
Daina Linton (Fashion Metric) - Work With Customers Before You Write Any Code
  • Initial idea (having a fashion expert available to advise when shopping) wasn't what people needed. By using open-ended questioning they learned what was needed for Men was a way to help them find clothes that actually fit.
  • By using a Concierge model (human in the loop) as opposed to building applications they were able to go from validating the new idea to confirming a return rate of 0% on shirts sold via their fitting model. 
  • Their initial product consisted of a web site that offered a better shirt fitting experience. Only call to action was to ask for permission to have a 10 minute phone conversation about what they needed.
Christie George (New Media Ventures) - Funding for Lean Impact
  • Applying the principles of "Fail Fast" and "Fail Forward" to social challenges means that real people are failed. Make sure the failure stays where it has positive value.
  • Social change takes a long time (interracial marriage as an example). Social startups can accelerate those feedback loops only so much.
  • Social funders (charitable organizations) are very risk adverse. Need to find a way to incentivize risk.
  • Create a culture where the truth is incentivized (example given was Unreasonable Institute's practice of reporting their investment decision failures).
Ari Gesher (Palantir) - Preparing for Catastrophic Success
  • The hard things to deal with are getting real estate and leadership. Both require at least a 6 month horizon. Only the leadership part is interesting (his words in the presentation).
  • Want internal leaders? Pick your leaders, then give them a few people to lead immediately. Support them with a forum that they can discuss their challenges and problems. Then let them lead.
  • In the midst of growth is no time to build command and control leadership. Leaders need to be communication nodes, facilitating communication for their teams, coordinating with other teams.
  • Culture is an emergent property of the people you hire. Thinking "Will this person fit the culture" is not as important as thinking "How will this person enhance the culture"
  • Indoctrinate culture from the day people start. Don't leave it up to chance.
  • Final thoughts - "If it hurts, you're doing it right"
Steve Blank (Stanford / Berkley / Columbia) - Evidence-based Entrepreneurship
  • Steve scared me a bit. His presentation centered around the fact that there are now actionable metrics around startups, which on the surface seems a good thing. But there's no lack of cautionary tales of metrics gone wrong...
  • Startups are not smaller versions of companies. They are temporary organizations that exist to find a scalable business model. Only when they find that model can they become "companies"
  • His template for a startup is a Business Model Canvas + Customer Development Lab + Agile Engineering and Dev methodology
  • His Lean Startup class at Stanford is experiential - you will talk to at least 100 customers during the 10 week course.
  • NSF approached him to put together a class for the NSF. That grew into a metric framework to observe the progress of teams
  • Having that metric framework allowed Steve to come up with the "Investment Readiness Measurement" - a means of determining what pre-funding stage a startup was in. Modeled off of the NASA Technology Readiness Scale
Nikhil Arora & Alejandro Velez (Back To The Roots) - Using Kickstarter to Run an MVP
  • After starting with a "Grow your own mushroom" home kit they decided to bring an aquaponics idea to market - a system where fish waste was used to grow a small herb garden. Turned to Kickstarter to fund it. Had $248,000 in funding within 30 days.
  • They learned along the way the cost of rushing to market (faulty pump, unclear packaging). Their lesson learned that it was less expensive to deal with those things before rushing to market, not after.
Keya Dannenbaum (ElectNext) - Learning to Be and Organization that Pivots
  • One of the most common statements about entrepreneurship is "Follow Your Passion". It's wrong. She followed this up with data about the effect of emotional "passion" (it burns out) versus dedicated practice. Out of the two, practice is what matters, not passion.
  • Their first MVP took 18 months to develop, and it is no longer in use. Their second took 6, and their third took a few weeks. Only the third has proven a repeatable revenue model, and the only "Product" is Google docs and an email address database.
  • But those first two products are not failures. They were vital practice for their team to get better at what matters as a startup. Previously there was a lot of fear associated with pivots. Over time the pivots became something embraced - it meant progress towards a goal.
John Shook (Lean Enterprise Institute) - Lean Startup--From Toyota City to Frement to You
  • John started off by following the lead of the MIT research team that spawned the Lean Institute. He wanted to work for a Japanese car manufacturer to learn their management methods. Only one would hire him - Toyota. At the time he was the only westerner working at a Japanese auto plant.
  • His statement about Lean to the whole group was powerful. "This (Lean) is a Learn By Doing process. You learn by doing it. With respect to everyone here, attending conferences and reading books will not get you there".
  • In 1 year the factory selected for the joint GM/Toyota venture went from last in quality to first (UAW rated)
Brad Smith (Intuit Software) - Lean Leadership Lessons
  • This was by far my favorite session. Of course I am defining "favorite" as "The one story I'd most like to find out if they are full of BS or really meant what they said".
  • Creating an innovation culture was a deliberate effort and takes buy-in across the whole company. The function of management is most importantly to "Find a way to get to Yes".
  • They host an annual incubation week - teams are allowed to work on anything they see fit, company has resources deployed to assist them (legal, etc).
  • Their projects are classified into three tiers - Horizon 1 (immediate revenue generators), Horizon 2 (Established business model with actual customers needing to be curated into a full offering), Horizon 3 (The idea/MVP area)
  • Their team cultures are different based on their tier of product. And they encourage that to be the case.
  • Most interesting to me was the acknowledgement that the Horizon 3 products require a more risk-tolerant environment to thrive, and Intuit delivers it to them.
  • Hugh Molosti is their primary idea guy over the years and has a 7 figure incentive package to keep him from going anywhere else. What other company is that proactive in keeping their best idea people?


Monday, November 18, 2013

Of Liaisons, ball bearings, fetzer valves and failures

There's a scene from the movie "Fletch' when Chevy Chase is posing as an aircraft engine mechanic and is being grilled about why he'd need ball bearings. His reply: "Come on guys, it's all ball bearings these days!"

\No, I'm not going to talk about ball bearings or even Fetzer valves (inside joke for the Fletch fans out there).

To paraphrase, "Come on guys! It's all patterns these days!"

But before I do, a bit of history. First, the earth cooled. Then dinosaurs roamed the planet.

Too far back? OK. We'll just set the wayback machine to 1977.

An architect by the name of Christopher Alexander published a book titled "A Pattern Language: Towns, Buildings, Construction". Although reports vary on the influence it had on the Architecture industry, it is commonly cited as the inspiration design patterns in software architecture, interaction design and many other fields.

So what was the big deal? He introduced the concept of a Pattern Language. Pattern languages gave a structure to identifying common problems along with their best practices solution(s) in specific disciplines. This allowed valuable information about common problems and solutions to be communicated much more rapidly and reliably than ever before.

As a software architecture-ish kinda guy, I cut my teeth on the Gang of Four's Design Patterns book. Then as I started looking around at other disciplines I realized that they had their own pattern languages, and if I took the time to understand them I'd have a much better understanding of the problems and problem solving approaches to these other disciplines - think of it as an abstract version of the Rosetta stone

Imagine my delight when I discovered that there were organizational patterns - a pattern language devoted to problem solving challenges in organizational structures, something we have to do from time to time in this business.

Odds are good that you're very familiar with at least one of these, even if you don't know it as an organizational pattern. Ever hear anyone say "We're running a skunk works team"?

Yep. It's an organizational pattern.

During a recent Agile Roots 2014 planning session I was talking with Lory Maddox (RN extraordinaire and mother of Ruby guru and Clean Coder evangelist Pat Maddox) about her current job, which is taking new patient interaction innovations and operationalizing them to work within the highly regulated environment of clinical medicine.

As she was telling a story about how her team averted a logistic nightmare by stopping the release of a new communication solution that had not been adapted by her team for deployment into the highly regulated clinical medicine environment, I realized that her team (whether they realized it or not) were implementing an organization design pattern I like to call "Operationalizing".

Operationalizing: A team with deep experience in a specific (usually highly regulated) environment that has the skills and the responsibility for adapting new solutions (software, process, etc) in such a way that the new solution can be deployed successfully within the target environment.

Note: I have not found definitive literature on the name of this pattern, so I get to call it what I like for now. Comment if you can point me to something authoritative.

I know what you're thinking. No, we haven't gotten to the actual point yet. We're close, I promise! Don't get me wrong, the concept is very interesting, but it isn't the one I wanted to talk about. So why did I even take the time to mention it?

Well, because thinking about how the Operationalizing pattern would play out was the trigger for putting my finger on how I've failed to properly apply the Liaison pattern.

Let's go back to the SkunkWorks pattern for a moment (quietly, we don't want Lockheed suing us).

The SkunkWorks pattern is a very common organizational approach these days to attempt to solve the problem of innovation. Look at any large company you'd care to point to. Odds are very high that they have at least one SkunkWorks team running, maybe more. My former employer Walmart was no exception.

When I was with Walmart this was the organizational pattern that we used to restructure the Mobile Applications group. Or was it?

On the surface, yes. But we broke a few key rules of the SkunkWorks pattern - we did not completely segregate the team from the rest of the organization, nor did we completely decouple our infrastructure from the larger organization. Although I'm of the opinion that we could have done more to segregate the team the same was not true regarding the infrastructure. Because we were building live mobile apps that customers were using to buy real things from Walmart, we didn't have a lot of choices regarding our production infrastructure.

And this is where the Liaison pattern comes into the story. If you were paying attention a few paragraphs back you'll see that I actually used the dreaded "F" word in reference to myself.

One of the first external teams I met with was the InfoSec group - this was the team responsible for insuring that all production code met industry and company security standards. As you'd expect with any large organization, the InfoSec team was a single siloed team that evaluated and validated the output of several teams including our Mobile Applications group.

Here's the sad part. In my first meeting with them I explained how we were departing from the previous practice of months-long release cycles to a much faster cycle. When they indicated that their process didn't allow for that fast of a cycle I told them about the Liaison pattern and how it could be used to great success. After confirming that they all liked the idea I assured failure by making the foolish assumption that they'd actually do something about it.

What I should have done in that situation was to put "find a way to get InfoSec to give us a liaison" at the top of my priority list.

Back to the Liaison pattern. Never heard of it? You'll have to be a student of military organizational logistics to have come across the same definition that I have. In military circles, a Liaison is a person (or persons) that are a member of one group within a military organization but are assigned to be part of another group for the express purpose of helping that group to effectively interact with their "home" group. The pattern is most often implemented in situations where the "other" group operates at a much faster pace than the other group (e.g. Special Operations teams conducing operations in the same areas as conventional forces).

Examples: Forward Air Controller, Liaison Officer

Had I made it a priority to work with InfoSec to have a member of their team assigned to ours it probably would not have made much of a difference in the early days of that engagement, namely because we were successful at pushing back on their process thanks to Executive Sponsorship (yet another organizational pattern). Where it would have made a huge difference was when that same executive sponsorship shifted and we were no longer able to keep InfoSec from slowing down our cycle time.

By the way, that whole slowdown thing? That's an organizational pattern too - Organizational Antibodies. I'll be talking about that one in a future posting.

The moral of the story - Organizational Patterns! Learn them, learn to use them if you care about being effective. Most importantly, learn how not using them will have a negative impact on your team(s).

Tuesday, October 29, 2013

Getting political with Agile Sadism

I was on my way home from a medical appointment the other day and for some unknown reason decided that I needed to have a little talk radio background noise. After tuning into the local NPR station I was all set to disengage my thinking brain from my ears when I heard the interviewee say "Without common pain there is no chance to achieve real change in an organization."

Cue cinematic double-take record scratching sound.

Did I really just hear that? On an NPR talking heads program?

After a little research I discovered that the talking head in question making this point was no less than Mike Leavitt - former Governor of Utah (amongs many other positions I didn't bother to go look up) and the point he was making was in his new book entitled "Finding Allies, Building Alliances".

For those of you worried about being bored to death by a book report, fear not. I have yet to pick up the book. You'll just have to get by with being bored to death by my thoughts on what I learned from that interview.

If you haven't looked at the title of the blog recently, this would be a good time to do so. Go ahead - I'll give you a minute.

Done? Great. As you'd imagine, the fact that pain is an effective tool in the political arena isn't a huge surprise. What was a surprise was the fact that he acknowledged it as such. What was even a bigger surprise is that he went on to describe a situation where his approach failed.

See why I was surprised? Hearing a politician (or at least a former one) acknowledge not only the fact that he's applied "Machiavellian" techniques to get things done but actually admit that he experienced failure was the true eye-opener for me.

Sounds a lot like a reflection session, doesn't it?

What he "learned" from his failure was that not all of the stakeholders in a particular situation felt a common pain. As a result that same stakeholder ended up derailing the effort because they were better off maintaining the status quo.

Of course we'd never see such a thing in the software development industry, would we?

It is always instructional to see how similar problems are solved in different contexts. As this was the first time I've heard of a formalized approach to solving difficult problems in the political world I wanted to see what could be applied to my industry. Fortunately I was able to find the "Too Long; Didn't Read" book summary to get the big picture:

1. A Common Pain—a shared problem that motivates different people/groups to work together in ways that could otherwise seem counterintuitive. 

Absolutely. Of course no virtuous person would ever consider actually manufacturing these common pains to get things done, right?

2. A Convener of Stature—a respected and influential presence who can bring people to the table and, when necessary, keep them there.

If I were translating these points into the software domain (which of course I am) I'd say that this is the equivalent to the concept of an Executive Sponsor

3. Representatives of Substance—collaborative participants must bring the right mix of experience and expertise for legitimacy and have the authority to make decisions.

This was a good reminder to me that the twin characteristics of recognized experience and decision making authority are key for all participants.

4. Committed Leaders—individuals who possess the skill, creativity, dedication and tenacity to move an alliance forward even when it hits the inevitable rough patches.

Since problems within the software domain tend to be smaller in scope to the challenges government groups face, I'd say that we'd see this be the same group as with point

5. A Clearly Defined Purpose—a driving idea that keeps people on task rather than being sidetracked by complexity, ambiguity and other distraction.

Definitely an important point for our industry considering how common it is for our teams to have split responsibilities.

6. A Formal Charter—established rules that help resolve differences and avoid stalemates. 

I've decided I don't know how I feel about this one yet. My initial reaction is that establishing rules is counter-productive to solving a problem quickly, but as I thought about it more I realized that the teams that I'd point to as not needing rules were actually operating under a self-generated set of rules learned from prior experiences.

7. The Northbound Train—an intuitive confidence that an alliance will get to its destination, achieve something of unique value, and that those who aren’t on board will be disadvantaged.

This was probably my most valuable takeaway from this list. When you think about it, it is nothing more than a "pain" generated by the problem solving process. But it is also a particularly wide-reaching pain that if properly applied can increase the "rejection rate" of the solution across the wider organization.

8. A Common Information Base—keeps everyone in the loop and avoids divisive secrets and opaqueness.

This is not exactly news for our software world (Information Radiators, Sunshine, etc), but it is a good reminder for me as I have a tendency to not put as much effort into these tools/process as they deserve.

So I'm sure at some point I'll pick up the book and read it. It's probably worth your time to do the same, especially if you are (as I am) a student of seeing similar problems solved in different environments.