Froggacuda's Weblog

The popularity of Agile project management has come with a lot of people saying that they “do Scrum” or “we Scrum” or “we be Sprinting” or any other combination of buzzword + us. This is known in the community as doing “Scrum but” because it inherently identifies that agility has not been fully embraced. This leads to three things:

1. Poor results
2. Frustration
3. Anger at Scrum / Agile methodologies

Introducing Agile methodologies into a company is a subject for future blog posts, and won’t be covered here. Suffice it to say that without understanding and embracing, at least for the duration of a medium-sized project, an Agile tech completely, you’re going to be disappointed with the results. “Scrum but” begets butt results — just remember that.

I could go on and on with the metaphors that might explain how doing “Scrum but” is a terrible idea (it’s like thinking one or more tires on a car are optional to go on a road trip; it’s like trying to grill steaks with no propane; it’s like trying to land a job with no resume) — it all rolls up to three issues:

1. Doing Scrum because it is cool / a buzzword / makes you feel cutting edge
2. Believing that Scrum is a la carte rather than a whole methodology
3. Unwillingness to let go of old Waterfall habits

Let’s discuss these three points.

One: Scrum / XP / Lean / Agile may sound cool — and done right, providing clean, measurable results, it is — but that is not the point. The point of Scrum is to force participants to think outside the box and provide continuous feedback on specific deliveries to insure that nobody is working in a vaccuum. The agile part of Scrum is reducing the battleship to a PT boat; it is able to turn on a dime rather than lumber around to a new heading. I believe that some of the attraction of Scrum is due to the flexibility of the methodology; however, when Teams start skipping Scrum Retrospectives because they have to rush to the next Sprint, or the Sprint Stories are “close enough” or “placeholders” or “XP Style” (a note to have a conversation about this later on), or there are other shortcuts taken in the process, you are accumulating Tech Debt which is guaranteed to bite you in the ass like a rogue wave (or a rogue VP). I am not arguing against the coolness of Scrum or any other Agile PM; again, they ARE cool, but it’s not in the name, it’s in the results of using Scrum effectively, and that means the whole enchilada.

Two: Scrum is not a buffet line, where you take a few Sprint sausages, some scrambled egg Stories, and a tall glass of Tasks, passing on the perceived parsley of a complete Planning Scrum and the dubious gridwork of well-formed Retrospective waffles. If you are going to try this approach, you might as well skip the plate while you are at it. There is a reason that CSMs are certified: it’s because Scrum is a methodology, and although Scrum purists will dislike that I point this out, there is a 1-2-3-4 to Scrum. It works best if the tech is embraced fully, even if you don’t understand why right off of the bat. Reusing the food metaphor, eat your veggies; it makes for a properly balanced diet. Try it, you might like it. Three pain points that I have found while implementing Scrum into businesses are the following:

1. Planning Scrums are not prepared for (Stories ready, Backlog prioritized, etc.)
2. Sprint Retrospectives are skipped (gotta get going on the next Sprint — no time!)
3. Daily Scrums are not transferring knowledge properly (usually not asking the right questions)

A list of things to do is not a Backlog; an ad hoc 5 minute “how’d that Sprint go?” is not a Retrospective; “what’d you do yesterday? how bout today? are you blocked?” is not a Daily Scrum. Feel free to try to fool yourself and your organization that this is adding value, but see the first ordered list in this post for the results.

Three: As a veteran PM, I have ridden the inner tube of Waterfall-style project management, and it really isn’t all that bad if you are working for a huge company with lots of specialists and compartments, have all the time in the world to complete a project, and you are employed by the government. Even software development with ever-changing requirements can be successful with the right amount of documentation, change requests, and a battery of people willing to trade speed for bulk; i.e., the battleship. I would, however, like to point out that the dreadnought became extinct in World War II, when the strategic air power of carrier-based fighters and bombers sunk the Yamato in port in ’45. It couldn’t hide from a swarm of agile aircraft. The introduction of Scrum / Agile into a business is always fraught with the dangers of incorporating Waterfall-style PM into the process. “The Tech Spec IS the Backlog” is one I have heard countless times, and this leads to skipping the work of creating the needed pieces to properly Sprint. “These meetings are a waste of time; get back to coding!” is another one, typically from Business Owners who are trying to buffet their way to agility, usually because Waterfall — “we’re in development phase!” — is how they understand the surface of the project and because saying that the company is “Agile” or “does Scrum” is some sort of competitive advantage jargon. One of the reasons that Scrum is flexible is to be able to USE Waterfall-style documents to create solid, prioritized, accurate Backlogs, well-formed, spot-on Stories with full doneness requirements, and to provide developers with all the information that they need to Task out the Sprint to a high degree of initial accuracy, which provides a framework to embrace the inevitable changes that will come down the pipeline.

Overall, Scrum (and other Agile methodologies) suffer from the coolness factor, the buffet line, and the grandfathering-in of Waterfall thinking. Observation of anything along these three lines should be cause to stop, drop, and re-evaluate. Anytime I hear “we do Scrum but…” I always inquire if the organization has done Scrum with no But. That is the only way to understand how the pure methodology works for you, and from that foundation comes tuning and refinement, THROUGH Scrum, not around it.