Archive

Posts Tagged ‘Agile software development’

The Supreme Scrum Master

January 1, 2015 2 comments

Even though I mildly resisted the urge to do so, I capitulated and posted this doubly disrespectful blasphemy:

Could not resist

Awe, come on. Drop the who-pooped-in-my-soup face, relax your sphincter, smile for an instant, and simply go with it. If the hermit kingdom’s supreme leader invested a little money ($2k) and time (3 fun-filled days) to add the coveted title of Certified Scrum Master to his already impressive cache of expert credentials, you’d definitely want him to be your Scrum Master.

But wait! Make sure you don’t ask Mr. Un what agile methods he uses to magically remove the obstacles and impediments to your success.

Show Me Your Curves

December 14, 2014 7 comments

Either directly or subliminally, the message I hear from hardcore agilista big-wigs is that an agile process trumps a traditional plan-driven software development process every time and in every context – no exceptions.

No Exceptions

On the other hand, the message I hear from traditionalists is… well, uh, I don’t hear much from traditionalists anymore because they’ve been beaten into silence by the hordes of unthinking zombies unleashed upon them by the agilista overlords.

agile zombies

Regarding the “betterness” of #agile over #traditional (or #noestimates over #estimates, or #noprojects over #projects), please leave your handful of personal anecdotes at home. Charismatic “I’ve seen” and “in my (vast) experience” stories don’t comprise science and aren’t sufficient justifications for sweeping generalizations. The science simply doesn’t exist – especially for the construction of large, distributed software systems.

I suppose that if a plausible (and thus, falsifiable) theory of software development processes was to be methodically derived from first principles and rigorously tested via a series of repeatable experiments, the general result would end up looking something like this:

Agile Vs Traditional

What predictive capabilities do you think a credible theory of software development processes would generate? Show Me Your Curves.

Impedance Mismatch

November 7, 2013 Leave a comment

The anecdotal evidence is overwhelming. Agile methods can work really well for many small teams and small projects. However, no matter what the expert, high-profile, “coaches” purport, the jury is still out regarding its scalability to large teams and large projects. In “How even agile development couldn’t keep this mega-project on track“, Nick Heath showcases the British disaster known as the £2.4bn “Universal Credit Programme“.

First, the sad fact:

…the UK government has had to write off at least £34m on the programme and delay the national launch for the project. The department in charge of the project, the Department for Work and Pensions (DWP), can’t guarantee the remainder of the £303m it has spent on the project so far will offer “good value” it said.

From the rest of Nick’s story, it becomes clear that agile methods weren’t really used to develop the software:

There was a two-year gap between the DWP starting the project design and build process, and the system going live in 2013.

The DWP experienced problems incorporating the agile approach into existing contracts, governance and assurance structures.

That second point is key. No matter how much a big org wants to be “agile“, it is heavily constrained by the hierarchical structures, stature-obsessed mindsets, byzantine processes, and form-filled procedures entrenched within not only itself, but also within its suppliers and customers. It’s a classic “system” problem where futzing around with one component may crash the whole system because of hardened interfaces and skin tight coupling.

As the figure below shows, attempting to “agilize” a large component within an even larger, waterfall-centric, system creates impedance mismatches at every interface. The greater the mismatch, the less productive the system becomes. Information flow and understanding between components bog down while noise and distortion overwhelm the communication channels. In the worse case, the system stops producing value-added output and it would have been better to leave the old, inefficient, waterfall-centric system intact.

impedance mismatch

The only chance an agile-wanna-be component has at decoupling itself from the external waterfall insanity is to covertly setup a two-faced, agile<->waterfall protocol converter for each of its external interfaces. Good luck pullin’ that stunt off.

aw adapter

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?

FR

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

Promised Vs. Provided

February 16, 2013 Leave a comment

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“?

DDT

%d bloggers like this: