Posts Tagged ‘Waterfall’

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.

Honesty is not only the best policy; in Scrum, it is the ONLY policy. There is a pseudo-phrase that is used in Scrum training to describe the appearance of Impediments: they ‘bubble up”. This only happens when Team members are honest — with themselves, with each other, with their ScrumMaster. The ScrumMaster is a facilitator and a communicator. It is the job of a well-trained and courageous SM to prod, poke, investigate, cajole, bribe, berate, beg, reward, entice, and otherwise convince both the Team as a unit and individual members to communicate impediments — no matter how large or small they may seem — by “bubbling them up” to the surface. The brave ScrumMaster then takes the Impediments and communicates them to the rest of the Team, the Product Owner; if necessary, the Business Owner, and possibly even the Stakeholders (read: Clients). Good ScrumMasters are always in jeopardy of having their heads ripped off because many times they are the bearers of bad news. Agility is also helpful in dodging thrown staplers, monitors, and other heavy, close-at-hand office items.

Honesty leads to Agility in this manner: the communication should be like greased lightning. Every employee at Achieve has seen me absorb some information and immediately turn around and start communicating it to someone else. Whether this is by walking into someone’s office, picking up the phone, crafting an IM or an e-mail, creating or refining an Unfuddle ticket, or driving between offices, you have witnessed the lengths I go to insure that communication is happening quickly, effectively, and honestly. Scrum — and I would suspect most Agile methodologies — completely falls apart if the channels to move information slow down or become clogged. Lack of transparency to the Client is the bane of Waterfall, where you work in a bubble on a project for a segment of time only to find out at delivery that this is no longer what the end user wants. It is better to confront a known Impediment than to pretend that there isn’t one or that there is nothing that you can do about it; ignorance is NOT bliss; it is cowardice.

The central strength of Scrum is that everyone is in the loop all of the time. Developers should raise impediments as they appear, not after they have been trying to solve it for an hour. Lead Developers should be ready to (and encouraged to) step in to team program around a thorny issue — after they tell their ScrumMaster that something has come to their attention in this vein. ScrumMasters should be central communication hubs that are constantly talking to the Team and the Product Owner to keep everyone appraised of progress and Impediments, all the while shielding their Team from outside interference. Product Owners should be speaking with their Clients daily in order to provide their feedback to the Team and to tell them of both good news and bad. This is colloquially known in Scrum as “swarming” and it is fantastic when it happens. Transparency may lead to Agility, but transparency comes from being honest.

[snip]

Scrum is really fond of recoiling at anything that vaguely resembles Waterfall methodology, but after a while, this provokes the following question: How do you balance Agility and Process? By definition, [Business] Process means following established procedures, usually in a certain order. This is already starting to quack like a duck in a Waterfall to Scrum aficionados.

On the other hand, it is patently stupid to be Agile for the sake of saying that you are being Agile. That is like pretending that there is a hopscotch board in front of you wherever you need to walk. Entertaining for a little while? Perhaps; however, over time, you will not only expend a lot of unnecessary effort, you will look foolish. Scrum, XP, Lean Development, and other Agile methodologies are, well, methodologies, and as such, are processes. Although clever witticisms such as “Scrum: it depends on common sense (Danube Training)” and “Scrum is not a methodology — it’s a pathway (Ken Schwaber)” are helpful when in the context of the tapestry that they pertain to, lifting them out as sound bites will insure that they are used in the wrong circumstances to justify incorrect assumptions.

So, back to my Blog title: Process Makes Perfect. I am not quacking here; even Agile PM has procedures to insure results. The introduction of Agility to a company is always tough because it forces the employees at all levels to think sideways, not completely out of the box. No Agile screed that I have ever heard of asks an enterprise to jettison everything in the name of Agility; rather, it is learning to recognize that you have many more options besides ludicrous speed and ranking full stop.

If you look at all of the fancy diagrams that supposedly depict Scrum processes with 3D delivery time loops, poetry and Bible verses, and even BHAG flowcharts, they really all say the same thing:

Wait for it…

Think Different

OK, I am not joining the ranks of the Apple fanatics (NSFW) here at Achieve with this bold appropriation of their late 90’s advertising campaign. It just so happens that this describes Agile thinking very, very well…when it is paired with a standard process to follow.

Nobody complains about the Waterfall when it is producing quality software, meeting deadlines, communicating well, and insuring that clients feel like heroes. No one cares how Agile your company is if you deliver a shoddy product that the customer didn’t ask for, late and over budget. There is a balance that can be struck — and should be found — where the best practices of differing methodologies can actually provide better results than any one on its own.

If a process is a series of steps in a predictable order, such as points on a straight line, then agility is thinking multidimensionally: away from the line. The main cause of grief from Waterfall is the strict adherence to the idea that “we can’t do that until we have done this”. This dot is in front of that dot on the line, and you cannot think differently enough to see that there is more than one dimension. Agile methodologies encourage anyone who is familiar with this mode of thinking to do a sort of mental Aikido when the standard operating procedures meet with resistance or raised impediments:

Aikido techniques are normally performed after first blending with the motion of the attacker, so that the defender may redirect the attacker's momentum without directly opposing it, thus using minimum effort...Aikido demonstrates this philosophy in its emphasis on mastering martial arts so that one may receive an attack and harmlessly redirect it. In an ideal resolution, not only is the receiver unharmed, but so is the attacker.

If the process is running smoothly, and product (quality “potentially shippable” code) is being generated, there is no real problem. It is when one perfectly-shaped piece of gravel catches your left front skateboard wheel at high speed that you realize that the attack is imminent — in this metaphor, the asphalt meeting the side of your face. Being flexible in your processes not only allows for agility, but brings you closer to not only dealing with your “attacker” (WIBNI, anyone?) but finding an ideal resolution to the apparent confrontation.

Here is some more abuse of the code block tags; something else to pair up with this idea of an Agile process, this time from the buzzword bingo that is the Agile Manifesto:

Simplicity--the art of maximizing the amount of work not done--is essential

As I have stated before, Achieve has an Approach. This is where I am going with my defense of Process. Recent hard work has determined that we may have found a balance point between Scrum and Process that will provide the Company with the best of both worlds.

Stay tuned for the other side of the double-wide!

on my driveway in Point Loma,
smoking 3 cigarettes,
I thought it was my cat Ferguson
cracking bird-bones at four in the morning,
but the white and grey patchy creature
was a shiny eyed opossum,
who moved off as fast as it could
back down the sidewalk
after discovering its way back to its lair
in the college leaf-lined drainpipes
was guarded by a flannel-skinned human.
insomnia can be a great thing
when the TV isn’t running any Godzilla movies
or Kung-Fu Theater;
then the silence outside, the cool air
can be heard straining to beckon
with no mouth, no gestures,
just an often overlooked phenomenon.
some will travel huge distances
to find beauty in waterfalls and vistas
that are easy to pretend that no one else has seen,
yet the early morning hours of solitude
and a token nightlighting of vapor lamps on telephone poles
is the hush of the spectacular
that not many appreciate,
right outside their heavy-lidded windows.

Seeing Green

Posted: April 25, 1993 in Poetry
Tags: , , , , , ,

I want you to see green
the way that I see green
in all of its fluorescence and grandeur:
a lawn and a suit
and a rain-clean forest in Hawaii fed by moss-strung waterfalls,
frog skin and garden hoses and glow sticks,
the bindings of books with gold letters,
childrens’ animated watercolors;
the hue and cry of the lifelong green
of the ocean where kelp beds hang,
or of a new car,
or of an apple.

Gnomes

Posted: February 3, 1993 in Poetry
Tags: , , , , , , , ,

Geoff and I hiked
to find a level place,
to stretch out with the countryside,
to stop and have a smoke.
trading the pipe-stem back and forth
– when one would speak,
the other would listen –
blowing thoughtful smoke rings
and laughing with the ease of friends.
we sat upon a king of rocks
immersed in the chatter of the waterfalls
aching to hurl ourselves into the air
dreaming of staying there forever.

and somewhere far above us,
our spirits, tall and clear and free,
smoked with us, looking down
their breath touselling our hair.
if I was asked to fly from that cliff
I know we could – and would!

[for Geoff Ian Stearns]

Dream Girl

Posted: July 20, 1992 in Poetry
Tags: , , , , ,

I SAW YOU [believe]
run pitter-patter run
hide away, waterfall or
column of flame;
run along dream girl.
I caught you this time
(in the echo of your flowered footprints)