Archive

Posts Tagged ‘Gerald Weinberg’

There “Shall” Be A Niche

November 23, 2014 9 comments

Someone (famous?) once said that a good strategy to employ to ensure that you get something done is to publicize what you’re going to do for all to see:

Reqs Book Publicity

As you can see, my new found friend, multi-book author Jon M. Quigley (check out his books at Value Transformation LLC), proposed, and I accepted, a collaborative effort to write a book on the topic of product requirements. D’oh!

Why the “D’oh!”? As you might guess, there are a bazillion “requirements” books already out there in the wild. Here is just a sampling of some of those that I have access to via my safaribooksonline.com account:Current Requirements BooksOf course, I haven’t read them all, but I have read both of Mr. Wiegers’s books and the Hatley/Hruschka book – all very well done. I’ve also read two great requirements books (not on the above list) by my favorite software author of all time, Mr. Gerry Weinberg: “Exploring Requirements” and “Are Your Lights On?“.

Jon and I would love to differentiate our book from the current crop – some of which are timeless classics. It’s not that we expect to eclipse the excellence of Mr. Weinberg or Mr. Wiegers, we’re looking for a niche. Perhaps a “Head First” or “Dummies” approach may satisfy our niche “requirement” :). Got any ideas?

shallvalanche

The biggest obstacle, and it is indeed huge, in front of me is simply that:

“My ambition is handicapped by laziness” – Charles Bukowski

Multiturding

February 4, 2013 Leave a comment

The best graphic I’ve ever seen on the inefficiency of multitasking comes via one of my long-time mentors from afar, Mr. Gerry Weinberg.

Weinberg MT

Even though some level of multitasking is pragmatically required once in awhile for getting things done, some orgs explicitly put multiturding up on a pedestal as a desired skill to be developed and honed. In these types of orgs, if you have multiple titles, roles, projects, etc, going on at the same time, you’re probably in the good graces of your bosses and a prime candidate for promotion. Plus, you get to pump up your annual appraisal form with a boatload of (half-assed) “accomplishments“.

Nine vs 6

As a test to see if you’re a member of an org that’s hooked on multiturding, try telling your boss that you’d like to work on one project at a time – and then observe the response. Also, observe the feelings that arise within you before you make the request – if you do indeed make the request.

multiturding

MTP

Ultimately And Unsurprisingly

September 1, 2012 5 comments

Take a look at the latest, dorky, BD00 diagram below. The process model on the left is derived from the meaty, 482 page CMMI-DEV SEI Technical Report.  The model on the right is derived from the lean, 16 page Scrum Guide.

Comparing CMMI-DEV and Scrum may seem like comparing apples to oranges, but it’s my blog and I can write (almost) whatever I want on it, no?

Don’t write what you know, write what you want to know – Jerry Weinberg

The overarching purpose of both process frameworks is to help orgs develop and sustain complex products. As you can deduce, the two approaches for achieving that purpose appear to be radically different.

The CMMI-DEV model is comprised of 22 practice areas, each of which has a number of specific and generic practices. Goodly or badly, note that the word “practice” dominates the CMMI-DEV model.

Unlike the “practice” dominated CMMI-DEV model, the Scrum model elements are diverse. Scrum’s first class citizens are roles (people!), events, artifacts, and the rules of the game that integrate these elements into a coherent socio-technical system. In Scrum, as long as the rules of the game are satisfied, no practice is off limits for inclusion into the framework. However, the genius inclusion of time limits for each of  Scrum’s 4 event types implicitly discourages heavyweight practices from being adopted by Scrum implementers and practitioners.

Of course, following either model or some hybrid combo can lead to product quality/time/budget success or failure. Aficionados on both sides of the fence publicly tout their successes and either downplay their failures (“they didn’t understand or really follow the process!“) or they ignore them outright. As everyone knows, there are just too many freakin’ metaphysical factors involved in a complex product development effort. Ultimately and unsurprisingly, success or failure comes down to the quality of the people participating in the game – and a lot of luck. Yawn.

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.

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

Cucumbers, Pickles, Brine

June 19, 2010 1 comment

It’s been a while since I read Gerry Weinberg’s “Secrets Of Consulting“, but the cucumber-pickle-brine story has been frequently appearing (uninvited, of course) in my mind. It goes something like this:

No matter how vehemently a cucumber says he/she will not turn into a pickle if dropped into a barrel of pickles filled with brine, he/she will get pickled. No exceptions.

When a DIC crosses the magical threshold into the land of privilege, the guild of management, the cucumber-to-pickle transformation is inevitable. From lowly wealth creator to status taker, schedule jockey, planner, watcher, controller, evaluator. Trouble is, most cucumbers want to get pickled.

Loop Dee Loo

March 29, 2010 Leave a comment

I first learned about cause-effect diagrams from one of Jerry Weinberg’s books. I can’t remember which one because I have so many of them and I’m too lazy to browse through them all to find the exact source. Cause-effect diagrams are useful two dimensional tools that can be used to understand cyclical loops of relationships in a system of interacting components.

In the RWEP loop example below, revenue leads to work, which leads to execution, which leads to profit, which leads to more revenue. If a profit seeking organization is well run, the org leaders vigilantly keep track of the “whole” RWEP loop and influence each malleable component so that the loop is positively reinforced and the org prospers. Neglecting one or more of the dominant RWEP loop components can lead to an unstable system that breaks the loop and collapses the system.

Let’s investigate the ways the loop can break down so we can appreciate what good leaders actually do. The first obvious system buster is a halt to the revenue stream. This single point of failure can bring the whole shebang to a screeching halt in an instant. Since the importance of revenue  to institutional viability is so patently obvious and measuring it is ridiculously easy, both good and bad leaders watch revenue closely and act (hopefully) accordingly to keep revenues rising.

The less scrutinized and harder-to-directly-measure system element, “efficient execution”, is a more subtle system buster. Crappy BMs who don’t (cuz they’re lazy or apathetic)) or can’t (because they’re incompetent) directly recognize efficient execution as a system buster take the easy way out by solely measuring profit as an indicator of execution performance. When profit declines, BMs thrash about because they’re at least one level of indirection away from where the rubber meets the road – execution. Since they’re out of touch, BMs make “suboptimal” decisions and issue ineffective mandates that actually accelerate the downward spiral in profits. Good leaders either directly evaluate execution efficiency according to their previous experience or they rely on frequently solicited feedback from those directly executing the work.

So there you have it in simple, maybe simplistic terms. Great leaders watch and positively influence both the (obvious) revenue and (subtle) execution contributors in the RWEP system loop.

Categories: business Tags:
%d bloggers like this: