Archive

Posts Tagged ‘Scott Berkun’

Magical Transformation

March 11, 2012 4 comments

In this interview of Scott Berkun by Michael “Rands In Repose” Lopp, “Rands In Repose: Interview: Scott Berkun“, Scott was asked about his former stint at Microsoft as a program manager. Specifically, Rands asked Scott what his definition of “program manager” is. Here is Scott’s answer:

It’s a glorified term for a project leader or team lead, the person on every squad of developers who makes the tough decisions, pushes hard for progress, and does anything they can to help the team move forward. At its peak in the 80s and 90s, this was a respected role of smart, hard driving and dedicated leaders who knew how to make things happen. As the company grew, there became too many of them and they’re often (but not always) seen now as annoying and bureaucratic.

Americans have a love affair with small businesses. But due to the SCOLs, CGHs, BUTTs, and BMs that ran companies like Enron, Tyco, and Lehman Bros, big businesses are untrusted and often reviled by the public. That’s because, when a company grows, its leaders often “magically” morph into self-serving, obstacle-erecting, and progress-inhibiting bureaucrats; often without even knowing that the transformation is taking place. D’oh! I hate when that happens.

The Berkun Process

March 4, 2012 5 comments

Scott Berkun’s brilliance never ceases to amaze me. In the video below, which runs at 30X real-time, we see a 1000 word essay that took 3 hours to write being created in 5 freakin’ minutes. While the footage whizzes by, Scott explains what he was doing and thinking during the creative act.

Like Gerry Weinberg does in his “Fieldstone Method“, Scott carries a notebook around wherever he goes and jots down notes/ideas as they appear in his head out of the ether. This crucial practice prevents the dreaded “blank page” syndrome from manifesting when it’s time to sit down and write.

BD00 collects “fieldstones” in much the same way. He also sketches out dorky pictures for future enhancement and refinement in Microsoft Visio.

Self Made Myth

February 24, 2012 Leave a comment

Western societies, especially the good ole USA, revere the myth of the “self-made” man. Even though many people might consider some of my greatest influencers; Seth Godin, Leo Babauta, Hugh MacLeod, and Scott Berkun self-made men, all of them depend on what Godin defines as “tribes” for their livelihood. And they’ll all humbly admit it – which is why I’m a fan.

I recently listened to Leo interview Seth on the subject of tribe-building for writers. Here are some tidbits of sage advice served up by Mr. Godin:

  • Don’t get upset by the fact that you don’t have a vision and can’t tell what’s coming next.
  • The core of any worthwhile, enduring business is not about maximizing profit.
  • You’ve got to embrace a willingness to fail.
  • Get that voice out of your head so you can do your best work. (D’oh!)
  • Don’t write for strangers – you don’t need a huge “tribe“, and thus, you don’t have to dilute your message.
  • Forget about writing “how to” books anymore. People just look it up online.
  • People hate reading, so keep it short.

The first four bullets are not just applicable to aspiring writers, no?

Kickstarted

October 7, 2011 2 comments

Last month, I blogged about helping to kickstart Scott Berkun‘s new book, “Mindfire”. Yesterday, I received a kool e-mail from kickstarter.com stating that all systems are go:

I also received a thank you e-mail from Scott inviting me to a party he’s throwing in Seattle:

Damn, I wish Scott lived in Syracuse, NY.

Set Your Mind On Fire

August 28, 2011 2 comments

One of my favorite authors on the topics of creativity and innovation, Scott Berkun, is about to hatch his fourth book: “Mindfire: Big Ideas For Curious Minds“.

Checkout the innovative way Scott is employing to launch the book: Kickstarter. Of course, I’ve signed up as a backer. Maybe you should too?

SysML Support For Requirements Modeling


“To communicate requirements, someone has to write them down.” – Scott Berkun

Prolific author Gerald Weinberg once said something like: “don’t write about what you know, write about what you want to know“. With that in mind, this post is an introduction to the requirements modeling support that’s built into the OMG’s System Modeling Language (SysML). Well, it’s sort of an intro. You see, I know a little about the requirements modeling features of SysML, but not a lot. Thus, since I “want to know” more, I’m going to write about them, damn it! :)

SysML Requirements Support Overview

Unlike the UML, which was designed as a complexity-conquering job performance aid for software developers, the SysML profile of UML was created to aid systems engineers during the definition and design of multi-technology systems that may or may not include software components (but which interesting systems don’t include software?). Thus, besides the well known Use Case diagram (which was snatched “as is” from the UML) employed for capturing and communicating functional requirements, the SysML defines the following features for capturing both functional and non-functional requirements:

  • a stereotyped classifier for a requirement
  • a requirements diagram
  • six types of relationships that involve a requirement on at least one end of the association.

The Requirement Classifier

The figure below shows the SysML stereotyped classifier model element for a requirement. In SysML, a requirement has two properties: a unique “id” and a free form “text” field. Note that the example on the right models a “non-functional” requirement – something a use case diagram wasn’t intended to capture easily.

One purpose for capturing requirements in a graphic “box” symbol is so that inter-box relationships can be viewed in various logically “chunked“, 2-dimensional views – a capability that most linear, text-based requirements management tools are not at all good at.

Requirement Relationships

In addition to the requirement classifier, the SysML enumerates 6 different types of requirement relationships:

A SysML requirement modeling element must appear on at least one side of these relationships with the exception of  <<derivReqt>> and <<copy>>, which both need a requirement on both sides of the connection.

Rather than try to write down semi-formal definitions for each relationship in isolation, I’m gonna punt and just show them in an example requirement diagram in the next section.

The Requirement Diagram

The figure below shows all six requirement relationships in action on one requirement diagram. Since I’ve spent too much time on this post already (a.k.a. I’m lazy) and one of the goals of SysML (and other graphical modeling languages) is to replace lots of linear words with 2D figures that convey more meaning than a rambling 1D text description, I’m not going to walk through the details. So, as Linda Richman says, “tawk amongst yawselves“.

References

1) A Practical Guide to SysML: The Systems Modeling Language – Sanford Friedenthal, Alan Moore, Rick Steiner

2) Systems Engineering with SysML/UML: Modeling, Analysis, Design – Tim Weilkiens

Berkun Myths

January 15, 2011 3 comments

Steven Johnson‘s book, “Where Good Ideas Come From“, seems to have garnered more accolades and publicity, but Scott Berkun‘s “The Myths Of Innovation” is also an insightful, well crafted, and surprising read on much-the-same topic. I haven’t read Steven’s book yet (it’s on my list), but I’ve read and enjoyed both editions of Scott’s book.

Here is Scott’s list of the 10 myths of innovation:

My faves are numbers 4, 6, and 7. Regarding number 4, one of my favorite quotes fits the bill:

Don’t worry about people stealing your ideas. If your ideas are any good, you’ll have to ram them down people’s throats. – Howard Aiken

What are your faves? Are there any myths missing from the list? What do you think are the “truths” of innovation? Are they just the inverses of the list?

Follow

Get every new post delivered to your Inbox.

Join 457 other followers

%d bloggers like this: