Archive

Posts Tagged ‘agile development’

Who Dun It?

July 6, 2015 2 comments

Assume that the figure below faithfully represents two platform infrastructures developed by two different teams for the same application domain. Secondly, assume that both the JAD and UAS designs provide the exact same functionality to their developer users. Thirdly, assume that the JAD design was more expensive to develop (relative depth) and is more frustrating for developers to use (relative jaggy-ness) than the UAS design.

JaggyAndDeep

Fourthly, assume that you know that an agile team created one of the platforms and a traditional team produced the other – but you don’t know which team created which platform.

WhoDunIt

Now that our four assumptions have been espoused, can you confidently state, and make a compelling case for, which team hatched the JAD monstrosity and which team produced the elegant UAS foundation? I can’t.

Additive Vs Multiplicative

April 25, 2015 Leave a comment

You may not believe this, but overall, I like “agile” management and coding practices- where they fit. The most glaring shortcoming that I, and perhaps only I, perceive in the “agile” body of knowledge concerns the dearth of guidance for handling both the social and technical dependencies present in every software development endeavor. The larger the project (or whatever you #noprojects community members want to call it), the more tangled the inter-dependencies. There are, simultaneously: social couplings, technical couplings, and the nastiest type of coupling of all: socio-technical couplings.

The best analogy I can think of to express my thoughts on the agile dependencies black hole is the linear vs multiplicative complexity conundrum as expressed so elegantly by Bertrand Meyer in his book, “Agile!“. But instead of the family friendly linguini and lasagna images Mr. Meyer employs in his book, I, of course, choose to use imagery more in line with the blasphemous theme of this blog:

Additive Multiplicative

The complexity of the system is at least equal to the product of the problem and solution complexities. At worst, there are exponents associated with one or both multiplicands.

Dueling Quagmires

March 21, 2014 2 comments

To BD00, the agile movement, even though it is a refreshing backlash against the “Process Models And Standards Quagmire” (PMASQ) perpetrated by a well-meaning but clueless mix of government and academic borgs who don’t have to create and build anything, has spawned its own quagmire of “Agile Process Frameworks And Practices Quagmire” (APFAPQ). Like the PMASQ community has ignited a cottage industry of expensive consultants, certifiers, assessors, trainers, and auditors, the APFAPQ movement has jump-started an equivalent community of expensive consultants, coaches, trainers, certifiers.

Dueling Quags

A Concrete Agile Practices List

September 19, 2013 2 comments

Finally, I found out what someone actually thinks “agile practices” are. In “What are the Most Important and Adoption-Ready Agile Practices?”, Shane-Hastie presents his list:

Agile Practices

Kudos to Shane for putting his list out there.

Ya gotta love all the “explicit definition of done” entries (“Aren’t you freakin’ done yet?“). And WTF is “Up front architecture” doing on the list? Isn’t that a no-no in agile-land? Shouldn’t it be “emergent architecture“? And no kanban board entry? What about burn down charts?

Alas, I can’t bulldozify Shane’s list too much. After all, I haven’t exposed my own agile practices list for scrutiny. If I get the itch, maybe I’ll do so. What’s on your list?

Agile List

The Magical Number 30

August 14, 2013 2 comments

In agile processes, especially Scrum, 30 is a magical number. A working product increment should never take more than 30 days to produce. The reasoning, which is sound, is that you’ll know exactly what state the evolving product is in quicker than you normally would under a “traditional” process. You can then decide what to do next before expending more resources.

SW 30

The trouble I have with this 30 day “law” is that not all requirements/user-stories/function-points/”shalls” are created equal. Getting from a requirement to tested, reviewed, integrated, working code may take much longer – especially for big, distributed systems or algorithmically dense components.

Arbitrarily capping delivery dates to a maximum of 30 days and mandating deliveries to be rigidly periodic is simply a marketing ploy and an executive attention grabber. When managers and executives accustomed to many man-months between deliveries get a whiff of the “30 day” guarantee, they: make a beeline to the nearest agile cathedral; gleefully kneel at the altar; and line up their dixie cups for the next round of kool-aid.

agile kool-aid

Categories: technical Tags: , ,

Bring Back The Old

September 11, 2012 4 comments

The figure below shows the phases of Scrum as defined in 1995 (Scrum Development Process) and 2011 (The 2011 Scrum Guide). By truncating the waterfall-like endpoints, especially the PSA segment, the development framework became less prescriptive with regard to the front and back ends of a new product development effort. Taken literally, there are no front or back ends in Scrum.

The well known Scrum Sprint-Sprint-Sprint-Sprint… work sequence is terrific for maintenance projects where the software architecture and development/build/test infrastructure is already established and “in-place“. However, for brand new developments where costly-to-change upfront architecture and infrastructure decisions must be made before starting to Sprint toward “done” product increments, Scrum no longer provides guidance. Scrum is mum!

The figure below shows a generic DRE system where raw “samples” continuously stream in from the left and value-added info streams out from the right. In order to minimize the downstream disaster of “we built the system but we discovered that the freakin’ architecture fails the latency and/or thruput tests!“, a bunch of critical “non-functional” decisions and must be made and prototyped/tested before developing and integrating App tier components into a potentially releasable product increment.

I think that the PSA segment in the original definition of Scrum may have been intended to mitigate the downstream  “we’re vucked” surprise. Maybe it’s just me, but I think it’s too bad that it was jettisoned from the framework.

The time’s gone, the money’s gone, and the damn thing don’t work!

Don’t Do This!

September 2, 2012 Leave a comment

Because of its oxymoronic title, I started reading Paul McMahon’s “Integrating CMMI and Agile Development: Case Studies and Proven Techniques for Faster Performance Improvement“. For CMMI compliant orgs (Level >= 3) that wish to operate with more agility, Paul warns about the “pile it on” syndrome:

So, you say “No org in their right mind would ever do that“. In response, BD00 sez “Orgs don’t have minds“.

%d bloggers like this: