Re: Software Projects In Real Life: "I See Dead People"

Oddly enough, one of the first things they teach in Scrum classes is that not every type of system is a good fit for Scrum.

Some software gets very over-specified. This usually somewhere between the customer and the developers by someone called a Business Analyst or a Product Specialist. Things that were never asked for by the customer get added, the logic and basic control flow of the overall application are specified, and then it's lobbed at a development team. Then the developers spend a lot of time developing something, send it back out, and the customer is pissed they spent so much time and cash waiting to get delivered something that is half useless to their case.

Those over-specified type of projects, it turns out, can have iterations done in which small amounts of work are added to the whole. The core idea can be fleshed out. Then Important Feature A can be added. Then work can move on to Important Feature B. Then the customer may even be able to use the project while work continues on Not-Quite-As-Important-Feature C. The customer asks the Product Owner for some things. The Product Owner makes sure the developers know what the customer wants, even if that means the PO goes back to the customer several times at the request of the developers. Then, get this, the people developing the software get to decide how to best develop it. The UI designer designs the UI. The programmers write the code. The technical writer writes the documentation. The programmers and/or the QA agents (some Scrum teams use a dedicated QA person and others have the main programmers do all the automated test suites) test it. Then they show it to the PO. Then the PO and the team schedule a meeting to show the customer what they've produced the last two to four weeks. The goal of every two to four week sprint is to make a commitment about what to deliver, work on it, and deliver it as a potentially useful part of the overall project. The project may not be totally useful until a few sprints go by because the customer may need multiple features from different sprints as their initial deployment. This works quite well for a lot of types of software.

What type of software is a good candidate for this flexible specification and iterative delivery? Business process software is one. Document management is another. A shopping cart, content management system, forum... pretty much anything that's a basic CRUD interface with maybe some API calls to a payment gateway, social network, or data transmogrifier of some sort can start really basic and grow features. A word processor can start as a basic text editor, then support marking up text, then support a spell checker, then support templates, etc. The same basic text editor could instead be grown into a programmer's editor or an IDE.

Where doesn't this work so well? Life support is an example. That's something where you have to have a whole bunch of specifications up front. Fly-by-wire flight control for planes is another. Missile guidance, nuclear plant controls, embedded systems that aren't easily updated in the field, and traffic control systems are probably poor candidates. This is especially true in initial development. It may be useful to have shorter, more responsive iterations for improvements once the initial system passes its rigorous test suite. It's possible to do these with Scrum from the beginning, but expect a whole lot of other effort around auditing all the edge cases. Something else -- maybe even traditional waterfall -- would probably be better for some things. In any case, no matter how it's developed (or how many Scrum sprints it might take), life-preserving or life-risking software or software that's really difficult to update shouldn't be actually put into place until all the parts are present.

I think the argument "well you wouldn't use Scrum for X" is a strawman considering Scrum is pretty clear that it's only a fit for some projects.

Comment on Re: Software Projects In Real Life: "I See Dead People"

Replies are listed 'Best First'.
Re: Software Projects In Real Life: "I See Dead People" by sundialsvc4 (Abbot) on Jun 24, 2015 at 11:34 UTC
A very thoughtful reply, mr_mischief. Thank you. A serious “fly in this ointment” is that the “features” of which one is speaking: (a) are only the parts of the iceberg which are above the ocean, and (b) are tacitly assumed to be independent. Therefore, the development team, without (as they(!!) say ...) “over-”specifying anything, pursues these highly-visible features one by one, but without proper regard to the whole. The resulting work-product is too-often extremely brittle, becoming unserviceable in a comparatively short amount of time. Words like “potentially,” used in the context of words like “useful” or “releaseable,” are, ahhh, “highly overrated.™” Again, the “self-directing machine” analogy. A hopelessly-coupled contraption of highly interwoven parts. Almost nothing is truly independent, in the general case. The experienced business-analysts who look for such things might be the bearers of inconvenient truth, especially if they are themselves experienced developers. (As you may have guessed, I play that role frequently.) And I speak, frankly, from the point-of-view of the coroner, or the emergency-room triage nurse. Projects that have been “scrummed until they have to be scrubbed” are usually where I come into the scene. This influences my thinking, and prompts this Meditation, but of course is not intended to be a straw man. We all understand, I think, that I am pointing to something without attempting to gather all of reality into what I am pointing to. There is a germ of truth, of course. There is such a thing as analysis paralysis, but there’s generally a much bigger thing known as “going off half-cocked.” I agree that the project should be redlined in definite stages and that those stages should be as succinct as possible, but equal attention must be paid both to the parts above the water and to the vastness that is below. If you let them, business stakeholders who really do not understand the process of building a software machine will seek to manage and micro-manage the activities. (Not entirely wrong, because they’re the ones paying for it, as well as the ones who will be most-invested in the result.) Perhaps my most serious beef with “scrum,” and with most of these methodologies (to be frank), is that they both set and encourage perceptions among stakeholders that the process itself really can’t consistently meet. This observation comes directly from my self-appointed role; from the dead or near-dead bodies that I see. One of the first things that I find that I have to do is to (re-)build trust, not only in myself but in the whole damn software-development process! When “trust” has been shattered, you really can’t get it back. Sometimes the project can be turned around. Sometimes the only realistic path is a slightly-softer and less-catastrophic crash landing. In either case, the damage has already been done ... even though the teams consisted of professionals and no one knowingly acted in bad faith.
Re^2: Software Projects In Real Life: "I See Dead People" by mr_mischief (Monsignor) on Jun 24, 2015 at 21:01 UTC
without proper regard to the whole is a terrible strawman. If you have developers disregarding the whole and integrating things poorly, they are bad developers. It's not caused by developing small, modular pieces.	[reply]
Re^2: Software Projects In Real Life: "I See Dead People" by eyepopslikeamosquito (Archbishop) on Jun 24, 2015 at 22:02 UTC
A very thoughtful reply, mr_mischief. Thank you. Yet again, you've replied to yourself, not the person you intended. At least this time, you didn't insult yourself. :)	[reply]
Re^2: Software Projects In Real Life: "I See Dead People" by Anonymous Monk on Jun 23, 2015 at 21:35 UTC
" Missile guidance, nuclear plant controls, embedded systems that aren't easily updated in the field, and traffic control systems are probably poor candidates." Those are operational concerns, not development concerns. Next?	[reply]


good chemistry is complicated, and a little bit messy -LW
	PerlMonks