Archive
Scrum And Non-Scrum Interfaces
According to the short and sweet Schwaber/Sutherland Scrum Guide, a Scrum team is comprised of three, and only three, simple roles: the Product Owner, the Scrum Master, and the Developers. One way of “interfacing” a flat and collaborative Scrum team to the rest of a traditional hierarchical organization is shown below. The fewer and thinner the connections, the less impedance mismatch and the greater the chances of efficient success.
Regarding an ensemble of Scrum Developers, the guide states:
Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule.
I think (but am not sure) that the unambiguous “no exceptions” clause is intended to facilitate consensus-based decision-making and preclude traditional “titled” roles from making all of the important decisions.
So, what if your conservative org is willing to give Scrum an honest, spirited, try but it requires the traditional role of “lead(s)” on teams? If so, then from a pedantic point of view, the model below violates the “no exceptions” rule, no? But does it really matter? Should Scrum be rigidly followed to the letter of the law? If so, doesn”t that demand go against the grain of the agile philosophy? When does Scrum become “Scrum-but“, and who decides?
Related articles
- The Scrum Sprint Planning Meeting (bulldozer00.com)
- Bring Back The Old (bulldozer00.com)
- Ultimately And Unsurprisingly (bulldozer00.com)
- From Complexity To Simplicity (bulldozer00.com)
- Why I’m done with Scrum (lostechies.com)
Courageous Journey
Here’s a dare fer ya:
If your org has a long, illustrious history of product development and you’re just getting started on a new, grand effort that will conquer the world and catapult you and your clan to fame and fortune, ask around for the post-mortem artifacts documenting those past successes.
If by some divine intervention, you actually do discover a stash of post-mortems stored on the 360 KB, 3.5 inch floppy disk that comprises your org’s persistent memory, your next death-defying task is to secure access to the booty.
If by a second act of gawd you’re allowed to access the “data“, then pour through the gobbledygook and look for any non-bogus recommendations for future improvement that may be useful to your impending disaster, err, I mean, project. Finally, ask around to discover if any vaunted org processes/procedures/practices were changed as a result of the “lessons learned” from innocently made bad decisions, mistakes, and errors.
But wait, you’re not 100% done! If you do survive the suicide mission with your bowels in place and title intact, you must report your findings back here. To celebrate your courageous journey through Jurassic Park, there may be a free BD00 T-shirt in the offing. Making stuff up is unacceptable – BD00 requires verifiable data and three confirmatory references. Only BD00 is “approved” to concoct crap, both literally and visually, on this dumbass and reputation-busting blawg.
A Risky Affair
The figure below shows the long term savings potential of a successful Software Product Line (SPL) over a one-off system development strategy. Since 2/3 to 3/4 of the total lifecycle cost of a long-lived software system is incurred during sustainment (and no, I don’t have any references handy), with an SPL infrastructure in place, patience and discipline (if you have them) literally pay off. Even though short term costs and initial delivery times suffer, cost and time savings start to accrue “sometime” downstream. Of course, if your business only produces small, short-lived products, then implementing an SPL approach is not a very smart strategy.
If you think developing a one-off, software-intensive product is a risky affair, then developing an SPL can seem outright suicidal. If your past history indicates that you suck at one-off development (you do track and reflect upon past schedule/cost/quality metrics as your CMMI-compliant process sez you do, right?), then rejecting all SPL proposals is the only sane thing to do…. because this may happen:
The time is gone, the money is gone, and you’ve got nothing to show for it. D’oh! I hate when that happens.
Related Articles
The Odds May Not Be Ever In Your Favor (Bulldozer.com)
Out Of One, Many (Bulldozer.com)
Prune Me, Please
In “Integrating CMMI and Agile Development“, Paul E. McMahon asserts that even though they’d like to, many orgs don’t “prune” their fatty, inefficient, and costly processes because:
..it requires a commitment of the time of key people in the organization who really use the processes. Usually these people are just too busy with direct contract work and the priority doesn’t allow this to happen.
One of BD00’s heroes, the Oracle of Omaha, has a different take on it:
There seems to be some perverse human characteristic that likes to make easy things difficult. – Warren Buffet
Of course, both reasons could apply.
The Scrum Sprint Planning Meeting
Since the UML Scrum Cheat Sheet post is getting quite a few page views, I decided to conjure up a class diagram that shows the static structure of the Scrum Sprint Planning Meeting (SPM).
The figure below shows some text from the official Scrum Guide. It’s followed by a “bent” UML class diagram that transforms the text into a glorious visual model of the SPM players and their responsibilities.
In unsuccessful Scrum adoptions where a hierarchical command & control mindset is firmly entrenched, I’ll bet that the meeting is a CF (Cluster-f*ck) where nobody fulfills their responsibilities and the alpha dudes dominate the “collaborative” decision making process. Maybe that’s why Ramblin’ Scott Ambler recently tweeted:
Everybody is doing agile these days. Even those that aren’t. – Scott Ambler
D’oh! and WTF! – BD00
Of course, BD00 has no clue what shenanigans take place during unsuccessful agile adoptions. In the interest of keeping those consulting and certification fees rolling in, nobody talks much about those. As Chris Argyris likes to say, they’re “undiscussable“. So, Shhhhhhh!
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!
From Complexity To Simplicity
As the graphic below shows, when a system evolves, it tends to accrue more complexity – especially man-made systems. Thus, I was surprised to discover that the Scrum product development framework seems to have evolved in the opposite direction over time – from complexity toward simplicity.
The 1995 Ken Schwaber “Scrum Development Process“ paper describes Scrum as:
Scrum is a management, enhancement, and maintenance methodology for an existing system or production prototype.
However, The 2011 Scrum Guide introduces Scrum as:
Scrum is a framework for developing and sustaining complex products.
Thus, according to its founding fathers, Scrum has transformed from a “methodology” into a “framework“.
Even though most people would probably agree that the term “framework” connotes more generality than the term “methodology“, it’s arguable whether a framework is simpler than a methodology. Nevertheless, as the figure below shows, I think that this is indeed the case for Scrum.
In 1995, Scrum was defined as having two bookend, waterfall-like, events: PSA and Closure. As you can see, the 2011 definition does not include these bookends. For good or bad, Scrum has become simpler by shedding its junk in the trunk, no?
The most reliable part in a system is the one that is not there; because it isn’t needed. (Middle management?)
I think, but am not sure, that the PSA event was truncated from the Scrum definition in order to discourage inefficient BDUF (Big Design Up Front) from dominating a project. I also think, but am not sure, that the Closure event was jettisoned from Scrum to dispel the myth that there is a “100% done” time-point for the class of product developments Scrum targets. What do you think?
Related articles
- Scrum Cheat Sheet (bulldozer00.com)
- Ultimately And Unsurprisingly (bulldozer00.com)
- Introduction to scrum (slideshare.net)
- Scrum Master, a management position? (scrumguru.wordpress.com)
- Developing, and succeeding, with Scrum (techworld.com.au)
Software Reuse
As a follow up to my last post, I decided to post this collection of quotes on software reuse from some industry luminaries:
Planned? Top-down? Upfront? In this age of “agile“, these words border on blasphemy.
The Odds May Not Be Ever In Your Favor
The sketch below models a BD00 concocted reference cost curve for a single, one-off, software-intensive product. Note that since the vast majority of the accumulated cost (up to 3/4 of it according to some experts) of a long-lived product is incurred during the sustainment epoch of a product’s lifetime, the graph is not drawn to scale.
If you’re in the business of providing quasi-similar, long-lived, software-intensive products in a niche domain, one strategy for keeping sustainment costs low is to institutionalize a Software Product Line Approach (SPLA) to product development.
A software Product Line is a set of software-intensive systems that share a common, managed set of features satisfying the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way. – Software Engineering Institute
As the diagram below shows, the idea behind the SPLA is to minimize the Total Lifetime Cost by incurring higher short-term costs in order to incur lower long-term costs. Once the Product Line infrastructure is developed and placed into operation, instantiating individual members of the family is much less costly and time consuming than developing a one-off implementation for each new application and/or customer.
Some companies think themselves into a false sense of efficiency by fancying that they’re employing an SPLA when they’re actually repeatedly reinventing the wheel via one-off, copy-and-paste engineering.
You can’t copy and paste your way to success – Unknown
If your engineers aren’t trained in SPLA engineering and you’re not using the the terminology of SPLA (domain scoping, core assets, common functionality, variability points, etc) in your daily conversations, then the odds may not be ever in your favor for reaping the benefits of an SPLA.
Related articles
- Out Of One, Many (bulldozer00.com)
- Product Line Blueprint (bulldozer00.com)
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“.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 