Posts Tagged ‘scott ambler’

Result-Focused, Or State-Focused?

April 23, 2014 Leave a comment

As I continue to explore/evaluate the relevance of the SEMAT Kernel to the future of software engineering, I’m finding that I’m liking it less and less. (For a quick introduction to the SEMAT Kernel, please go read this post, “Revolution, Or Malarkey?“, and then return back here if you’re still interested in what BD00 has to say.)

One of the principal creators of the SEMAT movement, Ivar Jacobson, subjectively asserts that:

“…using the SEMAT kernel to drive team behavior makes the team result focused instead of document driven or activity centric.” – Ivar Jacobson

Using the patented BD00 method of distorted analysis, let’s explore this bold proclamation further.

In the current definition of the SEMAT kernel, each of the seven top-level alphas in the SEMAT Kernel has a state whose value at any given moment is determined by the sub-states of a set of criteria items in a checklist. In addition, each sub-alpha itself has a checklist-determined state.

“Each state has a checklist that specifies the criteria needed to reach the state. It is these states that make the kernel actionable and enable it to guide the behavior of software development teams.” –  “The Essence Of Software Engineering

SEMAT Checklists

So, let’s look at some numbers for a small, hypothetical, SEMAT-based project. Assume the following definition of our project:

  • 7 Alphas
  • Each alpha has 3 Sub-Alphas
  • Each checklist has 5 Items

With these metrics characterizing our project, we need to continuously track/update:

  • 7 alpha states
  • 7 * 3 = 21 Sub-alpha states
  • 7 * 3 * 5 = 105 checklist item states

Man, that’s a lotto states for our relatively small, 21 sub-alpha project, no? It seems like the SEMAT team could be spending a lot of time in a state of confusion updating the checklist document(s) that dynamically track the state values. Thus,

“…using the SEMAT kernel to drive team behavior makes the team state focused instead of result focused.” – BD00

Unless result == state, Ivar may be mistaken.

Left And Right

October 25, 2013 3 comments

The Manifesto for Agile Software Development is rightly credited with launching the agile revolution and catalyzing the birth of methodologies like XP, DSDM, and Scrum. The following four major tenets supposedly underpin every single agile methodology.

agile 4

In theory, not many people (with the exception of a pure bred bureaucrat) could argue effectively against preferring the soft left side over the hard right side of the table.

In practice, the situation is often much different than the theory. While espousing the need to operate in accordance with the left side, many so-called leaders stick to their 20th century guns behind the rhetoric. They demand process and tool compliance, dumpsters full of useless forms/documents/metrics, formal, penalty-laden contracts, and preposterously huge, upfront project plans.

BD00 posits that the reasons managers and executives demand conformance to the tenets on the right while espousing the ones on the left are one or more of the following:

  • They don’t sincerely believe that the stuff on the left can possibly lead to higher quality products and faster delivery times than the stuff on the right.
  • They can’t shed their personal fears of loss of control and loss in stature if they switch operating modes from the right to the left.
  • They have no idea how to ignite the shift to the left (other than rhetoric).
  • Their hands are tied because big customers (like the government and Fortune 500 companies) demand all the hulking, time-consuming, and expensive stuff on the right.
  • They’ve made tons of money operating in accordance with the principles on the right both before and (many years) after the introduction of the agile manifesto.

Maybe that’s why I chuckle every time this quote comes to mind:

Everybody’s doing agile these days, even those who aren’t. – Scott Ambler

What do you think, dear reader? Are there any other reasons that should be added to the list?  Do you think that the ratio of fake-to-real agile orgs is high or low? Is it increasing or decreasing with time?


Agile Overload

June 1, 2013 9 comments

Since I buy a lot of Kindle e-books, Amazon sends me book recommendations all the time. Check out this slew of recently suggested books:

Agile Books

My fave in the list is “Agile In A Flash“.  I’d venture that it’s written for the ultra-busy manager on-the-go who can become an agile expert in a few hours if he/she would only buy and read the book. What’s next? Agile Cliff notes?

Agile” software development has a lot going for it. With its focus on the human-side of development, rapid feedback control loops to remove defects early, and its spirit of intra-team trust, I can think of no better way to develop software-intensive systems. It blows away the old, project-manager-is-king, mechanistic, process-heavy, and untrustful way of “controlling” projects.

However, the word “agile” has become so overloaded (like the word “system“) that….

Everyone is doing agile these days, even those that aren’t – Scott Ambler

Gawd. I’m so fed up with being inundated with “agile” propaganda that I can’t wait for the next big silver bullet to knock it off the throne – as long as the new king isn’t centered around the recently born, fledgling, SEMAT movement.

What about you, dear reader? Do you wish that the software development industry would move on to the next big thingy so we can get giddily excited all over again?

Agile NP

Revolution, Or Malarkey?

May 14, 2013 4 comments

BD00 has been following the development of Ivar Jacobson et al’s SEMAT (Software Engineering Method And Theory) work for a while now. He hasn’t decided whether it’s a revolutionary way of thinking about software development or a bunch of pseudo-academic malarkey designed to add funds to the pecuniary coffers of its creators (like the late Watts Humphrey’s, SEI-backed, PSP/TSP?).

To give you (and BD00!) an introductory understanding of SEMAT basics, he’s decided to write about it in this post. The description that follows is an extracted interpretation of SEMAT from Scott Ambler‘s interview of Ivar:  “The Essence of Software Engineering: An Interview with Ivar Jacobson”.

As the figure below shows, the “kernel” is the key concept upon which SEMAT is founded (note that all the boasts, uh, BD00 means, sentences, in the graphic are from Ivar himself).

In its current incarnation, the SEMAT kernel is comprised of seven, fundamental, widely agreed-on “alphas“. Each alpha has a measurable “state” (determined by checklist) at any time during a development endeavor.

SEMAT Kernel

At the next lower level of detail, SEMAT alphas are decomposed into stateful sub-alphas as necessary:

SEMAT Sub-Alphas

As the diagram below attempts to illustrate, the SEMAT kernel and its seven alphas were derived from the common methods available within many existing methodologies (only a few representative methods are shown).

Agile Over SEMAT

In the eyes of a SEMATian, the vision for the future of software development is that customized methods will be derived from the standardized (via the OMG!) kernel’s alphas, sub-alphas, and a library of modular “practices“. Everyone will evolve to speak the SEMAT lingo and everything will be peachy keen: we’ll get more high quality software developed on time and under budget.

SEMAT Practices

OK, now that he’s done writing about it, BD00 has made an initial assessment of the SEMAT: it is a bunch of well-intended malarkey that smacks of Utopian PSP/TSP bravado. SEMAT has some good ideas and it may enjoy a temporary rise in popularity, but it will fall out of favor when the next big silver bullet surfaces – because it won’t deliver what it promises on a grand scale. Of course, like other methodology proponents, SEMAT’s advocates will tout its successes and remain silent about its failures. “If you’re not succeeding, then you’re doing it wrong and you need to hire me/us to help you out.

But wait! BD00 has been wrong so many times before that he can’t remember the last time he was right. So, do your own research, form an opinion, and please report it back here. What do you think the future holds for SEMAT?

What’s The Diff?

February 10, 2013 3 comments

One of the problems I’ve always had with the word “agile” is that it’s so overloaded (like “system“) that anyone can claim “agility“:

Everyone is doing agile these days – even those who aren’t – Scott Ambler

Along this vein, check out this slide from a unnamed agile expert:

Tests first

Now tell me, how is this advice different from the unconscionable and anti-agile:

Reqs First

To define tests, you have to have some understanding of the requirements to test against in your cranium, no? It’s just that, in agile-land, you’ll be excommunicated from the cult if you formally write them down before slinging code. WTF?

Like “agile” was a backlash against “waterfall” in the past, maybe “waterfall” will be a circular backlash against “agile” in the future?

Waterfall Agile

Likewise, instead of creating an emergent Frankensteinian design with revered “TDD“, why not hop off the bandwagon and create emergent tests with “DDT“?


The Scrum Sprint Planning Meeting

September 12, 2012 2 comments

Since the UML Scrum Cheat Sheet post is getting quite a few page views, I decided to conjure up a class diagram that shows the static structure of the Scrum Sprint Planning Meeting (SPM).

The figure below shows some text from the official Scrum Guide. It’s followed by a “bent” UML class diagram that transforms the text into a glorious visual model of the SPM players and their responsibilities.

In unsuccessful Scrum adoptions where a hierarchical command & control mindset is firmly entrenched, I’ll bet that the meeting is a CF (Cluster-f*ck) where nobody fulfills their responsibilities and the alpha dudes dominate the “collaborative” decision making process. Maybe that’s why Ramblin’ Scott Ambler recently tweeted:

Everybody is doing agile these days. Even those that aren’t. – Scott Ambler

D’oh! and WTF! – BD00

Of course, BD00 has no clue what shenanigans take place during unsuccessful agile adoptions.  In the interest of keeping those consulting and certification fees rolling in, nobody talks much about those. As Chris Argyris likes to say, they’re “undiscussable“. So, Shhhhhhh!

Hurry! Hurry!

August 30, 2012 Leave a comment

Lots of smart and sincere software development folks like Ron Jeffries, Jim Coplien, Scott Ambler, Bob Marshall, Adam Yuret, etc. have recently been lamenting the dumbing-down and commercialization of the “agile” brand. Since I get e-mails like the one below on a regular basis, I can deeply relate to their misery.

Hurry! Hurry! After just 2 days of effort and a measly 1300 beaners of “investment“, you’ll be fully prepared to lead your next software development project into the promised land of “under budget, on schedule, exceeds expectations“.

Whoo Hoo! My new SCRUM Master certificate is here! My new SCRUM Master certificate is here!

Working Software, Working Documents

October 28, 2009 2 comments

Documentation is a love letter that you write to your future self – Damian Conway

The agile software development community rightly says that the best measure of progress is demonstrate-able working software that is delivered incrementally and frequently to customers for their viewing and using pleasure. For the most part, and for good reasons based on historical evidence, agile proponents eschew documentation. Nevertheless, big bureaucratic customers like national and state governments often, very often, require and expect comprehensive documentation from their vendors. Thus, zealot agilist juntas essentially ignore the requirements of a large and deep-pocketed customer base.

It’s software development, not documentation development – Scott Ambler

What if we can bring big, stodgy, conservative, and sometimes-paranoid customers halfway? Why not try to convince them of the merits of delivering frequent and incrementally improving requirements, design, construction, and user documents along with the working software builds? If we pay as we go, incrementally doing a little documentation, doing a little software coding, and doing a little testing instead of piling on the documentation up front or frantically kludging the documents together after the fact, wouldn’t the end result would turn out better?

Useful Docs

A consequence of generating crappy documentation for big, long-lived systems is the high cost of downstream maintenance. Dumping hundreds of thousands of lines of code onto the maintenance team without handing them synchronized blueprints is an irresponsible act of disrespect to both the team and the company. Without being able to see the forest for the trees, maintenance teams, which are usually comprised of young and impressionable developers, get frustrated and inject kludged up implementations of new features and bug fixes into the product. Bad habits are formed, new product versions get delivered later and later, and maintenance costs grow higher and higher. Bummer.

Poop Docs

%d bloggers like this: