Archive
Who Dun It?
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.
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.
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
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:
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
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.
A Concrete Agile Practices List
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:
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?
The Magical Number 30
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.
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.
Bring Back The Old
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!
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“.
Ultimately And Unsurprisingly
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.
Hurry! Hurry!
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!
Marginalizing The Middle
Because they unshackle development teams from heavyweight, risk-averse, plan-drenched, control-obsessed processes promoted by little PWCE Hitlers and they increase the degrees of freedom available to development teams, agile methods and mindsets are clearly appealing to the nerds in the trenches. However, in product domains that require the development of safety-critical, real-time systems composed of custom software AND custom hardware components, the risk of agile failure is much greater than traditional IT system development – from which “agile” was born. Thus, a boatload of questions come to mind and my head starts to hurt when I think of the org-wide social issues associated with attempting to apply agile methods in this foreign context:
Will the Quality Assurance and Configuration Management specialty groups, whose whole identity is invested in approving a myriad of documents through complicated submittal protocols and policing compliance to existing heavyweight policies/processes/procedures become fearful obstructionists because of their reduced importance?
Will penny-watching, untrusting executives who are used to scrutinizing planned-vs-actual schedules and costs in massive Microsoft Project and Excel files via EVM (Earned Value Management) feel a loss of importance and control?
Will rigorously trained, PMI-indoctrinated project managers feel marginalized by new, radically different roles like “Scrum Master“?
Note: I have not read the oxymoronic-titled “Integrating CMMI and Agile Development” book yet. If anyone has, does it address these ever so important, deep seated, social issues? Besides successes, does it present any case studies in failure?
… there is nothing more difficult to carry out, nor more doubtful of success, nor more dangerous to handle, than to initiate a new order of things. For the reformer makes enemies of all those who profit by the old order, and only lukewarm defenders in all those who would profit by the new order… – Niccolo Machiavelli
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 