Failing Fast vs. Slowly and Expensively

The following is a work-in-progress excerpt from a longer piece I am writing on agile development, agility, and other buzzwordy topics. It was originally posted on LinkedIn. 


Earlier in my career, I was asked to manage a big company initiative that was really important to my employer. Let’s call it 15LI – The 15 Letter Initiative. 15LI had at least 15 different stakeholders and probably twice as many opinions on what the heck 15LI was about and what it was supposed to do for the company.

After talking to engineers, product managers, marketing people and lots of other folks around the company, I was getting nowhere in figuring out what 15LI was and what we were trying to achieve, let alone the plan and timeline for the initiative. I scheduled a meeting with a senior project leader to brainstorm and define a direction.

The problem, he said, is that engineering isn’t stepping up to the plate to run with 15LI. I said, well, the engineers don’t really know what we’re trying to achieve with 15LI. Also, the engineers and the product people have vastly different ideas about what 15LI is and how it should be implemented. I also said that I wanted to know the goals of 15LI.

The project leader said, imagine you’re on our website. We know who you are since you’ve already bought stuff on our site. Based on what we know about you and your purchasing history and browsing history, we will serve up tailored offers that are targeted to your interests. And we’ll do it across multiple channels – web, mobile, email.

Great, I said. I paused, and then offered that what he described wasn’t a goal or a strategy. He just described an implementation approach based on a series of steps initiated by a user. What he laid out was the “how.” What nobody at the company understood was the “why” or “what” or “when” – the business context wrapped around the “how.”

I kept going, and recited a list of bullet points off the top of my head:

  • What did the company intend to accomplish with 15LI? (Capture new revenue? Increase existing revenue? Increase customer loyalty? Increase customer conversions? Expand market share? Improve user experience?)
  • Why was 15LI important, necessary, and/or urgent at this particular time in the company’s trajectory?
  • What made the company’s flavor of 15LI different from our competitors’ and from anyone else inside or outside our industry?
  • Can our teams be assured that we aren’t just doing 15LI because our competitors are doing it already? (Maybe because we need to know that we have a broader company vision than just following a “me too” strategy)
  • How will we know whether 15LI is a success? What measures will we use to determine whether it’s a success, a partial success, or a failure?
  • How much time do we have to launch 15LI and to prove that it might be successful?

All of the above, I said, covers the minimum viable business context of 15LI. We may not know all the answers to these questions, but we sure as hell need to be thinking and talking about them across all our teams. Because if we don’t, there’s a good chance that we won’t fail fast – we’ll just fail slowly and expensively.

The senior project guy listened to what I had to say. He said something about how those were good questions, but what we really needed was to get 15LI going immediately. He added, if the engineers don’t listen to you, tell them to f**k off and just get it done.

And with that, the meeting was over.

So how did it all go? None of my questions were ever answered and 15LI was never successfully launched. End of story, no happy ending, but a personal lesson learned – some questions need to be asked even if the answers never arrive.

Lean(ing) Towers: A Closer Look at the Foundation of the Scaled Agile Framework

SAFe’s foundation contains the supporting principles, values, mindset, implementation guidance and leadership roles needed to successfully deliver value at scale. – from What is SAFe?, © 2010-2017 Scaled Agile, Inc.

Why is a foundation important? As the underlying base of a residential or commercial building (or the bell tower of a famous Italian cathedral, more on that later), the foundation gives stability to the structure above it. The foundation, if it is solid and reliable, can also provide support as the structure over it grows and expands over time. In other words, to have a structure (or in this case, a framework) that scales, the structure itself should be undergirded by a foundation that is rock solid.

Let’s consider what happens to a building when the foundation isn’t that strong. What issues can affect the foundation? The foundation might not be complete — possibly a work in progress. Or the foundation may look structurally sound, but questionable materials and effort went into making the foundation. The very ground that the foundation rests on may be unstable. That’s not the fault of the foundation, but it does mean the foundation and the structure above it can be impacted by environmental factors. Even worse, the foundation may not even exist, but the structure above it is still in place and may even be expanding.

So the real question is, what happens when the foundation isn’t solid? This is what you get:


If the foundation isn’t solid, the structure that rests on it may be usable for some time. But after enough time passes, there’ll be a noticeable tilt. The leaning structure may attract visitors who will take funny photos and selfies. But mostly, the structure will become a highly visible example of how not to build or scale something on a potentially shaky foundation.

And that is precisely where the Scaled Agile Framework has its biggest opportunity and biggest challenge: its foundation.

Next, I’ll look at each element of the foundation to see how it all comes together – coming soon.

On A KickStarter Kick

KickStarter has been around for a while as an innovation driver and community builder. For me, it’s become a go-to source for finding niche products to meet my particular purchasing habits. When looking for something specific, I’ll do the usual Google key word search and check out Amazon, YouTube and other sites. This year, my hunt for specific products kept leading me to KickStarter. This probably happened because the products I was looking for hadn’t gone mass market yet, and were in early pre-production runs before going for a wider launch.

This year I supported two really cool products launched with KickStarter campaigns that more than exceeded their funding goals. They are highly original concepts that are flawlessly executed.

The first: APEX Wallet 2.0 – The Lifetime Guaranteed, RFID-Proof Wallet. I just received this a few weeks ago and this tiny wallet is sleek, indestructible, and lightweight. It also holds a lot more than what I expected.

The second: minijam studio – portable music machines. This is a cool set of electronic music products for dirt cheap. I plan to have impromptu jam sessions with my son with this pocket-size kit that generates a disgusting amount of heavy bass sounds.

Check out the Kickstarter site – no doubt that you’ll find a campaign you’ll want to support.

Hello, Ello

So there’s been a fair amount of hype about the new social networking service called Ello. I got an invite recently (which is not that hard to come by) and just spent some time using it.

So what’s it like? I’m struggling to describe it because it just seems so… sparse.

Visually it’s quite simple and clean. There’s too much white space, to the point where it seems barren and almost cold. The busy-ness of Facebook, Twitter, and LinkedIn, all of which cram way too much noise and activity into their layouts, is the norm now. And that’s probably why Ello seems oddly silent. You can practically hear the tumbling tumbleweeds. Ello’s icy silence might be less noticeable on a native mobile app, which is supposed to launch later this year for both iOS and Android.

Aside from the visual aspect, here are some quick observations:

  • There’s no helpful way to find people who you might know. Since it’s still a relatively small site, I guess they don’t have enough people to run recommendation engines that will help you find the people you might know. Instead, you have to search for them by real name or their Ello user name.
  • It’s easy to invite friends to the beta. Just click the “+” button.
  • The “friends” vs. “noise” filters are clever ways to switch between people whose updates you really want to see, vs. those you’d rather not. It’s also really easy to switch someone from friend to noise, or vice versa.

In a nutshell, it’s a simple and minimalist site in its desktop version and is refreshingly free of the “sponsored” messages that are everywhere now on social networking sites. That was a big motivator of the Ello philosophy, and it will appeal to anyone who doesn’t want to be a product to be targeted by advertisers.

“You can’t make your app viral”

“You can’t make your app viral as an afterthought, like pixie dust that magically gives you a ton of users. It has to be designed into the app’s core functionality and features.”

Smashing Magazine is a great website about mobile app design. The quote above is from their article Key Ingredients to Make Your App Go Viral.  Here’s how I summarized it on LinkedIn:

Good apps, and the ones that I use regularly, follow these simple rules:

(1) Allow meaningful sharing, (2) Be transparent about privacy, (3) Make connecting essential to the user experience, (4) Reward your users and their connections, (5) Offer meaningful ways to engage users, and (6) Always be useful.

As I think more about what I like or don’t like about the mobile apps I use, and the reasons for that like/dislike, I find that a lot of the Smashing Magazine ideas make sense to me. I will post more on this in the future, since it raises so many interesting questions about why I gravitate to some apps more than others. It’s all about the business rules

There it is, above the fold, on today’s Wall Street Journal: “Software and Design Defects Cripple Health-Care Website.” Since the October 1st launch of, which coincided with the first day of the current government shutdown, the website has been plagued with problems. It’s been bogged down by bad or lazy code, unfriendly design, and other issues. Hopefully, some of these glitches will be addressed by simple fixes before the enrollment rush of November.

However, the main problem isn’t just flawed codebad design, or page speed. Insurers participating in the health insurance exchange are reporting that 1% or fewer of the applications sent from have enough information to enroll applicants in a health plan.

The industry jargon is “batch corruption.” Batch corruption is a sign of data quality problems. Applicant enrollment data submitted through isn’t sufficient or accurate enough to process the applications. For instance, insurers are saying that they can’t associate applicants with their user IDs. There is also bad address data for applicants because of a problem with state name abbreviations. 

In other words, the culprit isn’t the technology or the design of The problem is that the fundamental business rules, around the process of applying and enrolling for a health insurance plan, have not been addressed. 

Despite all the fanfare and controversy around health care reform and Obamacare, turns out it’s the boring stuff like data quality and business process that are tripping up the launch.

Usability guru Jared Spool was right: Web sites and apps (like should not let the business rules take away from the user experience. Get the business rules right, don’t let them affect the user experience, and then make them invisible to the user.

You are not a ninja (or a maven)

I’ve noticed people around the web calling themselves a “product ninja” or a “networking maven” or even a “social media titan.”  Sorry to burst your bubbles, but something must be said about this trend.

A ninja in feudal Japan was a pretty scary person. He or she had deadly skills. Using stealth tactics and disguises a ninja could destroy their targets and disappear without a trace. They were also trained in espionage, arson, assassinations, and other nefarious arts. In short, you did not mess with a ninja.

Ninjas were skilled in uzura-gakure — a disappearing technique where the ninja curls into a motionless ball to look like a rock or stone. Is that something that you, self-proclaimed ninja, do regularly in the workplace? No? OK then.

So unless you were trained in traditional ninja skills, some 800 years ago in Japan, you are not a ninja.

I have data to back this up. There are more than 20,000 people on LinkedIn with the word “ninja” in their job titles, in either their current or previous positions. That constitutes a global ninja army. Yet none of them are truly ninja certified according to the ancient ninjutsu ways.

In my mind, there are only two acceptable reasons for you to call yourself a ninja.

1. You are a musician associated with the Ninjatune record label in the UK.

2. You were granted the title of “ninja” by your employer or colleagues, AND (this part is critical) you show up to work every day dressed in traditional ninja attire. This consists of, at a minimum, a black robe, lightweight armor, and lots of ninja tools like ropes, hooks, spikes, and wooden shoes (needed to walk on water when the situation demands). If you do not meet either of these criteria, you cannot call yourself a ninja.

By the way, you are also not a “maven.” More than 1,000 people on LinkedIn have that word in their job title. You are only a maven if Malcolm Gladwell himself has specially anointed you as one. If he hasn’t, and as far as I know it’s not a blessing he has bestowed on anyone, then you should not call yourself a maven.