Archive
Breaking News!
BD00 is still down in NOLA for Mardi Gras 2014, but he needs your help! The “donate” button will be up shortly.
Schmeam-Work
It took me about 15 minutes to conjure up the inane picture below. It took me another frustrating fifteen minutes attempting to come up with something that rhymes with “team-work” for the lower half of it. As you can see, I failed miserably. Do you, dear reader, have a better label for the “crappy” half? (@riczwest, my money is on you!)
Variable Sized MWs
Rewritten in “old school” terminology, the five Scrum process events can be expressed as follows:
- Sprint Planning = Requirements definition and capture
- Sprint = Requirements analysis, design, coding, unit testing, integration testing, code review
- Daily Stand Up = Daily status meeting
- Sprint Review = Post-mortem
- Sprint Retrospective = Continuous process improvement
So, someone with an intentionally warped mind like BD00 may interpret a series of Scrum sprints as nothing more than a series of camouflaged Mini-Waterfalls (MW).
But ya know what? Executing a project as a series of MWs may be a good thing – as long as an arbitrary, fixed-size, time-box is not imposed on the team. After all, since everything else is allowed to dynamically change during a Scrum project, why not the size of the Sprint too?
Instead of estimating what features can be done in the next 30 days, why not simply estimate how many days will be needed to complete the set of features that marks the transition into the next MW? If, during the MW, it is learned that the goal won’t be achieved, then in addition to cancelling the MW outright, two other options can be contemplated:
- Extend the length of the MW
- Postpone the completion of one or more of the features currently being worked on
Consumed By Randomness
Let the Design Emerge, But Not The Architecture
I’m not a fan of “emergent global architecture“, but I AM a fan of “emergent local design“. To mitigate downstream technical and financial risk, I believe that one has to generate and formally document an architecture at a high level of abstraction before starting to write code. To do otherwise would be irresponsible.
The figure below shows a portion of an initial “local” design that I plucked out of a more “global” architectural design. When I started coding and unit testing the cluster of classes in the snippet, I “discovered” that the structure wasn’t going work out. The API of the architectural framework within which the class cluster runs wouldn’t allow it to work without some major, internal, restructuring and retesting of the framework itself.
After wrestling with the dilemma for a bit, the following workable local design emerged out of the learning acquired via several wretched attempts to make the original design work. Of course, I had to throw away a bunch of previously written skeletal product and test code, but that’s life. Now I’m back on track and moving forward again. W00t!
Not So Nice And Tidy
Assume we have a valuable, revenue-critical software system in operation. The figure below shows one nice and tidy, powerpoint-worthy way to model the system; as a static, enumerated set of executables and libraries.
Given the model above, we can express the size of the system as:
Now, say we run a tool on the code base and it spits out a system size of 200K “somethings” (lines of code, function points, loops, branches, etc).
What does this 200K number of “somethings” absolutely tell us about the non-functional qualities of the system? It tells us absolutely nothing. All we know at the moment is that the system is operating and supporting the critical, revenue generating processes of our borg. Even relatively speaking, when we compare our 200K “somethings” system against a 100K “somethings” system, it still doesn’t tell us squat about the qualities of our system.
So, what’s missing here? One missing link is that our nice and tidy enumerations view and equation don’t tell us nuttin’ about what Russ Ackoff calls “the product of the interactions of the parts” (e.g Lib-to-Lib, Exe-Exe). To remedy the situation, let’s update our nice and tidy model with the part-to-part associations that enable our heap of individual parts to behave as a system:
Our updated model is still nice and tidy, but just not as nice and tidy as before. But wait! We are still missing something important. We’re missing a visual cue of our system’s interactions with “other” systems external to us; you know, “them”. The “them” we blame when something goes wrong during operation with the supra-system containing us and them.
Our updated model is once again still nice and tidy, but just not as nice and tidy as before. Next, let’s take a single snapshot of the flow of (red) “blood” in our system at a given point of time:
Finally, if we super-impose the astronomic number of all possible blood flow snapshots onto one diagram, we get:
D’oh! We’re not so nice and tidy anymore. Time for some heroic debugging on the bleeding mess. Is there a doctor in da house?
Collapsing The Wavefunction
Sprint 0 Starts Today!
With Fat Tuesday falling on March 4, Mardi Gras 2014 is coming up fast. Since BD00 will soon be making the trek down south to the world’s greatest party again this year, he downloaded the Mardi Gras Parade Tracker to keep on top of the situation. Think of the app as the greatest burndown chart ever concocted; providing 24X7 real-time progress updates to Scrum Master BD00 of each agile krewe’s progress from inception to final delivery.
After downloading the app, BD00 scrolled through the parade list and counted no less than 50(!) time-boxed parades on the product backlog. Sprint 0 starts….. TO-FREAKIN’-DAY, February 15th, with the Krewe du Vieux kickoff. BD00 can’t wait to ask the last of the big 3 Scrum questions (you know, the one nobody normally likes to ask or answer): “Are there any obstacles preventing you from creating business value?”
If you, dear reader, will be down in the ‘Nawlins French quarter between the dates of 2/28 through 3/4, tweet me with a “Who Dat?” when you rumble into town. We’ll hookup somewhere and the first Hurricane will be on BD00. If not, then check my twitter feed ‘tween those dates for some wholesome, uh, family-oriented pix of the festivities as they unfold.
It would be especially great to meet and interact with those reader(s) who strongly take issue with much of what BD00 writes in this mostly caustic blog, because:
I don’t like that man, I must get to know him better – Abraham Lincoln
Hopping On The Anti-Fragile Bandwagon
Since Martin Fowler works there, I thought ThoughtWorks Inc. must be great. However, after watching two of his fellow ThoughtWorkers give a talk titled “From Agility To Anti-Fragility“, I’m having second thoughts. The video was a relatively lame attempt to jam-fit Nassim Taleb’s authentic ideas on anti-fragility into the software development process. Expectedly, near the end of the talk the presenters introduced their “new” process for making your borg anti-fragile: “Continuous Delivery/Discovery/Design“. Lookie here, it even has a superscript in its title:
Having read Mr. Taleb’s four fascinating books, the one hour and twenty-six minute talk was essentially a synopsis of his latest book, “Anti-Fragile“. That was the good part. The ThoughtWorkers’ attempts to concoct techniques that supposedly add anti-fragility to the software development process introduced nothing new. They simply interlaced a few crummy slides with well-known agile practices (small teams, no specialists, short increments, co-located teams, etc) with the good slides explaining optionality, black/grey swans, convexity vs concavity, hormesis, and levels of randomness.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 