Archive

Posts Tagged ‘Scrum’

The Real And The FAKE

March 20, 2016 2 comments

Deal Of The Year

Hot off the presses, I just received a Groupon offer to take a $99 online Scrum Master certification course. Holy crap! Instead of paying $2000 and taking 3 consecutive days off from work, I can learn how to become a micro-managing process enforcer from the comfort of my own home; munching on chips while lounging around in my skivvies.

Online CSM

How can I refuse such a great deal? Just look at all those smart, well-dressed, professional, micro-managers in the advertisement staring at a burndown chart. It’s an especially nice touch that the marketing team put a pair of eyeglasses in Katherine Heigl’s hand.

From the course description:

CSMs understand Scrum values, practices, and applications and provide a level of knowledge and expertise above and beyond that of typical project managers.

If you’re a “typical project manager“, your days are numbered. The sky is falling and all that uncool PMI and EVM training you suffered through is sooooo yesterday.

course advisor

Categories: management Tags: , ,

Satirical Substitution

June 19, 2015 5 comments

Here’s how a Theory-X indoctrinated manager interprets the definition of the Daily Scrum as written in the official Scrum Guide:

Satirical Substitution

The Missing Role

April 22, 2015 2 comments

Quick, quick! What role is missing from the classic Scrum 1.0 team configuration of developers, product owner, and scrum master?

Missing AC

Ooh, ooh, I know what’s missing….

AC Present

Me thinks version 2.0 of the Scrum guide should include, and formally recognize, the glorious role of Agile Coach, no?

Since the Scrum Master has waaaaaaay to much to do already (running the daily 15 minute meeting and removing all those bazillions of impediments that the whiny developers willingly disclose every day), she can’t possibly fulfill the crucial role of agile coach. In addition to formal recognition, the Scrum Alliance should create a program where aspiring coaches can dole out some $$$$ to get certified.

Categories: management Tags: , ,

Planet Agile

March 16, 2015 1 comment

Because methodologists need an “enemy” to make their pet process look good, Agilistas use Traditional methods as their whipping boy. In this post, I’m gonna turn the tables by arguing as a Traditionalista (yet again) and using the exalted Agile methodology as my whipping boy. First, let’s start with two legends:

Legends

Requirements And User Stories

As you can see, the Agile legend is much simpler than the Traditional legend. On planet Agile, there aren’t any formal requirements artifacts that specify system capabilities, application functions, subsystems, inter-subsystem interfaces/interactions, components, or inter-component interfaces/interactions. There are only lightweight, independent, orthogonal, bite-sized “user stories“. Conformant Agile citizens either pooh-pooh away any inter-feature couplings or they simply ignore them, assuming they will resolve themselves during construction via the magical process of “emergence“.

Infrastructure Code And Feature Code

Unlike in the traditional world, in the Agile world there is no distinction between application-specific Infrastructure Code and Feature Code. Hell, it’s all feature code on planet Agile. Infrastructure Code is assumed as a given. However, since developers (and not external product users) write and use infrastructure code, utilizing “User Stories” to specify infrastructure code doesn’t cut it. Perhaps the Agilencia should rethink how they recommend capturing requirements and define two types of “stories“:  “End User Stories” and “Infrastructure User Stories“.

Product Models

 

Non-Existent Design

Regarding the process of “Design“, on planet Agile, thanks to TDD, the code is the design and the design is the code. There is no need to conceptually partition the code (which is THE one and only important artifact on planet Agile) beforehand into easily digestible, visually inspect-able, critique-able, levels of abstraction. To do so would be to steal precious coding time and introduce “waste” into the process. With the exception of the short, bookend events in a sprint (the planning & review/retrospective events), all non-coding activities are “valueless” in the mind of citizen Agile.

Traditional-Agile Map

No Front End

When asked about “What happens before sprint 0?”, one agile expert told me on Twitter that “agile only covers software development activities“.

Sprint-1

As the process timeline template below shows, there is no Sprint -1, otherwise known as “the Front End phase“, on planet Agile. Since the Agile leadership doesn’t recognize infrastructure code, or the separation of design from code, and no feature code is produced during its execution, there is no need for any investment in any Front End work. But hey, as you can plainly see, deliveries start popping out of an Agile process way before a Traditional process. In the specific example below, the nimble Agile team has popped out 4 deliveries of working software before the sluggish Traditional team has even hatched its first iteration. It’s just like planet Agile’s supreme leader asserts in his latest book – a 4X productivity improvement (twice the work in half the time).

Trad Agile Timelines

Process Scalability

The flexible, dare I say “agile“, aspect of the Traditional development template is that it scales down. If the software system to be developed is small enough, or it’s an existing system that simply needs new features added to it, the “Front End” phase can indeed be entirely skipped. If so, then voila, the traditional development template reduces to a parallel series of incremental, evolutionary, sprints – just like the planet Agile template – except for the fact that infrastructure code development and integration testing are shown as first class citizens in the Traditional template.

Scaled Down Traditional

On the other hand, the planet Agile template does not scale up. Since there is no such concept as a “Front End” phase on planet Agile, as a bona fide Agilista, you wouldn’t dare to plan and execute that phase even if you intuited that it would reduce long term development and maintenance costs for: you, your current and future fellow developers, and your company. To hell with the future. Damn it, your place on planet Agile is to get working software out the door as soon as possible. To do otherwise would be to put a target on your back and invite the wrath of the planet Agile politburo.

The Big Distortion

When comparing Agile with Traditional methods, the leadership on planet Agile always simplifies and distorts the Traditional development process. It is presented as a rigid, inflexible monster to be slain:

Big Bang

In the mind of citizen Agile, simply mentioning the word “Traditional” conjures up scary images of Niagara Falls, endless BRUF (Big Requirements Up Front), BDUF (Big Design Up Front), Big Bang Integration (BBI), and late, or non-existent, deliveries of working software. Of course, as the citizenry on planet Agile (and planet Traditional) knows, many Traditional endeavors have indeed resulted in failed outcomes. But for an Agile citizen to acknowledge Agile failures, let alone attribute some of those failures to the lack of performing any Front End due diligence, is to violate the Agile constitution and again place herself under the watchful eye of the Agile certification bureaucracy.

The Most Important Question

You may be wondering, since I’ve taken on the role of an unapologetic Traditionalista in this post, if I am an “Agile-hater” intent on eradicating planet Agile from the universe. No, I’m not. I try my best to not be an Absolutist about anything. Both planet Agile and planet Traditional deserve their places in the universe.

Perhaps the first, and most important, question to ask on each new software development endeavor is: “Do we need any Front End work, and if so, how much do we need?

 

Ill Served

You’ve been ill served by the software industry for 40 years – not purposely, but inextricably. We want to restore the partnership. – Ken Schwaber

ill served

Scrumming For The Corner Office

January 10, 2015 Leave a comment

Note1: This bogus post was inspired by Bertrand Meyer’s book: “Agile!. Specifically, the juice is squeezed from chapter 2: “Deconstructing Agile Texts“.

Business gurus love to fabricate crises and instill fear in their deep-pocketed C-level executive clients so they can pitch their latest idea (at $2000/day plus expenses) to “reinvent management!

Steve Denning is a big-league business management guru, ala Gary Hamel, Tom Peters, Ken Blanchard, Bob Sutton, etc. Even though Mr. Denning has no software background, he somehow got into Jeff Sutherland’s refrigerator and managed to drink a whole pitcher of “agile” koolaid with nary a burp.

agile koolaid

In a brilliant marketing move to distance himself from his peers, Steve has jumped on the “agile” bandwagon. He’s been busy advocating the migration of Scrum out of the software development trenches; up the ladder and into the corner office we go. I can visualize it: CEO as Certified Product Owner, COO as Certified Scrum Master, and the rest of the C-suite as second-class, uncertified, “developers“. (Why is there no certification program for developers?)

agile execs

In closing out this post, I’d like to share with you this brief twitter exchange between Mr. Denning and the lowly BD00 :

Denning Tweet Exchange

Note2: I actually like many of Steve’s ideas: “Who’s Left Standing?“, “Salesmen And Accountants“.

Categories: management Tags: ,
%d bloggers like this: