My motivation for this article isn’t to slam or denigrate any of the scaling frameworks (and those that continue to emerge). Full disclosure, I’m a SAFE SPC and I find significant value in leveraging “some” framework for agile at scale.

That being said, I have a great concern that I want to share. I think we’re losing some of the original thinking and approaches from early instances of agile. The methods grew out of small teams doing big things.

But as we’ve gone forward and introduced agility into larger instances (enterprises, large-scale companies, distributed projects, etc.), I’m afraid that we’re losing the very essence of agility that made it attractive in the first place. Things like:

• Small teams
• Simple, focused solutions
• Just enough
• Face-to-face collaboration
• Working code
• High value delivery

Seem to have lost their attractiveness. I want to share a series of stories that I think (hope) might shine a light on returning to our agile roots. Or at the very least, might get you to rethink some things.

First Story – Remember Wordstar?

I doubt whether many of the readers will recognize this program. But at one point, pre-Microsoft Word in the early to mid 1980’s, was the premier word processor on the planet. It was supported on something called CP/M and later on DOS.

What was amazing about Wordstar, at least to me, was that it fit into 64k of RAM. In fact, it fit into less than that because it had to share that space with the operating system. Imagine that, a simple, but full function word processer fitting into less than 64k of RAM. Clearly the designers had to make incredibly tough choices as to what features were absolutely critical to the program. In today’s terminology, we call it an MMP or Minimal Marketable Product.

Did folks complain about missing features and capabilities? You bet! But that didn’t stop a whole generation of programmers from being able to use Wordstar to get the jobs done.

I reminisce about Wordstar and similar programs because I think today we’ve gotten a bit lazy. Since we have hardware resources to spare, we design bloated products just to sort of prove that we can design a 100 complex ways to do inherently simple things. It’s easier than thinking about simple designs and simple solutions to complex problems. When agile came around, it placed a renewed focus on design simplicity, heck simplicity everywhere. Getting to the essence of a problem and solving…just it.

I think we could relearn something important by revisiting those software design goals from so long ago…

The Lesson: Wordstar had hardware limitations that forced the developers to minimize the product to a MMP feature set. Today we would do well to “imagine” that we had a small hardware footprint to encourage us to be creative, innovative, and frugal in our applications.

Second Story – Unix

The beginning of is another one of those “minimalist” stories. It was developed by a handful of developers in the early 1970’s at AT&T Bell Labs. While some of the early Unix contributors were considered “super programmers”, nonetheless it’s another case where a small group did big things.

As Unix’s popularity grew, of course the software got bigger. However, I still remember the “erector set” nature of basic Unix commands and how you could “pipe them together” to do more complex tasks. The architecture itself was simple, yet elegant and it remained that way as it historically expanded.

In the early 1990’s, Linus Torvalds famously released an Open Source version of Unix called . At the beginning, it too was incredibly small. He initially worked on it himself and then with a small group of dedicated maintainers.  Again, Linux has grown well beyond its original size constraints. But both systems are clear examples of elegantly designed small systems that had a huge impact on our technology.

The Lesson: Again simplicity, but not only that, the beginning of the realization that a small group of programmers could deliver big, useful things. That it didn’t take a team the size of Montana to deliver meaningful products or applications.

Third Story – Bloatware & Pareto

I’ve been using a quote for quite a long time in my classes. I can’t remember where I’ve seen it before, but it goes like this:

Less than 20% of the features of Microsoft Word are actually used by human beings on the planet earth. So how did the other 80% of features get in there if they have no (lean) value?

• Competitive pressures
• Marketing checklists
• Flat out guesses
• Gold Plating
• Feature creep
• Youthful enthusiasm

All probably contributed. But at the end of the day, the only determinant to value should be REAL customer usage. Now if only Microsoft would agree to “trim” Word down to size.

Here’s a supporting quote by Kelly Waters from a 2007 blog post:

Anyway, back to my point about the 80/20 rule, Microsoft’s own research found that the average user of Word uses only *8%* of the functionality. That’s 8%! And I wouldn’t mind betting at least 80% of us use the same 8% too! [assertion]. If Microsoft had developed only the important 8% of Word, maybe they could still have captured the same market share? Maybe, maybe not; sadly we will never know.

And the article also alludes to leveraging the Pareto Principle when it comes to mining for customer features that truly make a difference. Otherwise known as the 80/20 Rule, here’s an in another context.

The Lesson: Pareto is alive and well and applicable in everything we do in software. We need to continue to look for the 20% of features that deliver 80% or more of the value to our clients. Then deliver those FIRST before we worry about the edge cases.

Wrapping Up

Part one of this article focused quite a bit on application simplicity. In part two, just whetting your appetite, we’ll look at simplicity from a team size perspective. In both cases, I believe we’ve allowed our affinity towards complexity to drive us away from core agile principles. We need to start getting back to basics: small, focused applications, small teams, and great results.

Stay agile my friends,

Bob.