Thoughts on Scrum
11/21/2015 § Leave a comment
After a few years (10 to be more precise, wherein I was aware that a development methodology was in place in my shop, before it was always “get it done” and “all hands on deck”) of experiencing several software development cycle models and reading this slashdot entry regarding scrum I have a few thoughts on the subject and its high time I published them. First, let me say that my time spent in software development has been in the trenches, not at a managerial level, if that makes any difference. Still, I’m well aware of budgets, schedules, marketing requirements, all that. But the lingua franca of those subjects was never clearly spelled out to me, I simply absorbed them, as most of us probably do as we traverse the maze of the software business. And it is a maze, standing from my vantage point.
So when I tenured into this business the model had usually been “Customer wants *this*. They may or may not not realize they want *this*, but ultimately they want this. Take spreadsheets and the saga of Lotus 1-2-3. I clearly (like a bell) recall a business manager friend of mine for PG&E (That’s Pacific Gas and Electric for you who are not part of the American West Coast fauna) talking about software in the 80’s or so saying, during the introduction of IBM’s killer app for the 8086 PC; “Software is great, but when we’re cost analysing a proposal, we want to see those figures spread out.” and he went on to describe how the business preferred to have sheets of graph paper spread out on long tables, and if figures changed accountants with pencils would run up and down those tables changing figures as they changed in other parts of the sheets and so on. I have no idea how long he lasted with PG&E but I can’t imagine long because I can’t see people putting up with that nonsense when Lotus 1-2-3 made that mode of spreadsheet processing completely and utterly obsolete.
Every software developer since has been trying to create the next killer app. And with that have come people legion trying to create killer anything else; especially business logic.
“We’ll create the next killer business logic…” I can only imagine. So how’s that working out for you.
The next killer app for business logic had been “Agile” development, and the main (arguably) tool in Agile’s arsenal is scrum.
Agile software development is a “methodology” whereby people rush around complaining about schedules and pushing procedures. Not much different from any other “methodology.” At least in my experience wherein scrum was a thing, that’s what I’ve seen. And unlike many things in my life, I can definitely say this has been my exact experience with scrum, to greater or lesser degrees. I’m not even joking a little.
Which isn’t surprising, adopting a discipline is like adopting a puppy; sure sounds like fun, but then you have to take care of it. Then the reality sets in.
We have to do what?”
Software development disciplines are just that, disciplines, and they have to be followed, nurtured, improved on, and fed. And unlike waterfall, which requires and overseer, sure, scrum requires a “scrum master”, and a development manager is usually not a good candidate for that position. Scrum mastering requires a hands-on overseer, and with schedules and deadlines and enhancement requests and liaison (to development and business development ) management I frankly don’t see manager’s doing this; hence the invention of the “scrum master”, which is usually a developer being taken away from development time to “scrum master”. This is not from the Agile Bible, but from past experience.
In very recent experience, I’ve taken note of scrum and how it effects the development cycle. My overarching criteria in evaluating any process (or anything in that matter, in order, looks like this:
- Is it simple?
- Does it add value
- Does it add structure to the process?
- Are its iterations faster, or smaller in scope?
- How easy is it to implement?
- Did everyone involved find it less intrusive than the system in place before?
This is really just an off-the-cuff list but I think the points are relevant, even if others might position them differently. However, given these points as a frame of reference, I’m not so sure scrum adds value.
If a system requires a “master”, the implication is that the system on its face is already so complicated that a traffic cop is required for it to function at all. An engineer dedicated to the proper functioning of a development system already requires some time to learn the system and when to step in when a red light condition occurs, by definition. This requires some investment in study of the methodologies, depending on how much of the process you want to implement.
I knew we were in trouble in my last experience when I arrived for work on morning and my manager had the Scrum Master’s Bible sitting on his desk. Before long I (as sole software developer for the product) was charged with architecture as well as prototyping and production and required to fit it within the strictures of this agile system.
I can tell you the effort was a complete failure. I did things my own way and that manager went on to bizdev. It simply didn’t work. I’ve read opinions on the agile cycle being more effective in smaller dev teams. Well I’m here to tell you it certainly isn’t appropriate for teams of one, especially when that that team is making architectural decisions. So what, teams of 3? 5? What is the proper size of a scrum team?
I’m a firm believer of the “tool for the job” paradigm. You don’t need a hammer for all jobs, sometimes a tab is best.