Cloud Four Blog

Technical notes, War stories and anecdotes

Own Your Process: Ending Agile Guilt

What process do you use for your projects? Agile? Waterfall? Scrum? Extreme? A little bit of everything?

Join the club.

I had the pleasure of spending some time Saturday with a number of talented colleagues at the Digital PM Workshop here in Portland. I learned a lot and met some really great digital project managers.

As you might expect from a group of project managers, we talked a lot about process. When asked how participants typically run a project, I heard responses like, “Well, we’re sort of agile” or “I like to call our process broken agile” or “we’re not Agile with a capital A”. I heard a lot of qualifications and uncertainty about whether their particular method was correct.

Agile-ish?

I know the feeling. When I started at Cloud Four almost five years ago, we worked on projects with a very typical waterfall approach. In the past few years, we’ve started experimenting with ways to make our process more agile, to help address the reality that we often don’t know everything at the onset of a project, the only project constant is change, and that responsive projects tend to really benefit from rapid iterations. We started by breaking down the defined work into sprints, transitioning our clients to a more iterative process.

It’s been a fun challenge. In an agency setting, we’re grappling with integrating existing, disparate customer processes with our own, and we’re often working with ever-changing client teams. Process education becomes a burden the client must bear. Also, our customers generally want a high degree of certainty in budget and timeline when they embark upon a project with an agency.

What we’ve ended up with is something Agile-y. Agile-ish. Sort of, kind of Agile. Not agile-with-a-capital-A Agile, but you know, mostly Agile. Sometimes more waterfall-y than Agile, depending on the project and customer.

After exploring this with other web development folks, I’m pretty confident we’re all doing this. We tailor our process for the project and client that we have in hand. This is the right thing to do. One-size does not fit all when it comes to web development.

Let it go, let it go!

It’s time we let go of our process guilt that is plaguing us. There is no gold star for achieving a 100% agile process. We’re grasping for something that feels unattainable, yet it may not exist at all.

Even Dave Thomas, one of the contributors to the original Agile manifesto, has proclaimed that Agile is Dead. He pushes us to work towards developing with agility instead. Your project isn’t agile – your project exhibits agility. Your team works in an agile way. No more Agile perfectionism.

So, let go of the guilt. Own your process. Is it working for your client and your project? Are you meeting your goals? Great. If not, tweak it. Try something new. Find a process that works. Repeat it, test it, refine it.

In our case, that means we try to exhibit agility in our projects because it reduces risk and addresses the reality of the software world in which we work. That manifests itself differently for each project. Is it perfect? No. Is it agile? Yes. I’m done qualifying that statement.

Invisible Webfont Issues in Chrome (and a fix)

A few weeks back, we started hearing from Chrome users about a rather bizarre problem. They’d visit our site, only to find that the text was completely invisible:

Screenshot of blog.cloudfour.com with webfont issue

(Poor Jason, all alone, no content to keep him company…)

It turns out that Chrome 32 and 33 have some bugs when it comes to webfonts. Typekit wrote about the problem in a February post and again in a March update.

We’re sure the Google folks will fix the issue in a future update, but in the meantime it’s a significant obstacle for our users. So we rigged up a temporary hack based on a solution offered in Chrome’s issue tracker that seems to remedy things:

Our hack uses browser detection (yuck) to avoid unnecessary repaints, but if that turns your stomach there’s also a CSS-only solution. Let’s hope either measure is an extremely temporary one!

SimpleSlideView: Controlling Flow With JavaScript

In July we released SimpleSlideView, a jQuery and Zepto plugin for simple, responsive sliding views (here’s a demo). In the last few months, I’ve noticed an uptick in developers emailing to ask a variation of this question:

How do I change or stop a view transition based on user input?

It’s a great question, and one that may not be immediately apparent from the demo alone.

When using SimpleSlideView, there are two ways to navigate between views. The simplest way is with HTML, which is great for predictable, non-dynamic interactions or prototyping:

<button data-pushview="#result">See Result</button>

The straightforwardness of this technique is a double-edged sword. It’s easy to use, but it’s also kind of static. What if we want to change the destination? Or prevent the transition altogether? For that, we’ll want to use JavaScript instead.

We can remove the data-pushview attribute from the button, but we’ll need some way to select it via JS, so let’s give it an ID:

<button id="result-btn">See Result</button>

And here’s the scripty part:

// Save the simpleSlideView instance to a variable
var slideView = $('#container').simpleSlideView();
// Add a click event handler to the button
$('#result-btn').click(function(){
  // On click, push the view with an ID of 'result'
  slideView.pushView('#result');
});

Right now this probably feels like a step backward. It’s more verbose. But we’ve gained the freedom to define the sliding-view behavior any way we like.

Suppose you only want to transition when certain criteria are met:

if (isValid) {
  slideView.pushView('#thanks');
} else {
  alert('Oops! Something seems off.');
}

Or maybe you’d like the next view to depend on the value of something else:

if (age < 21) {
  slideView.pushView('#soda');
} else {
  slideView.pushView('#beer');
}

Here’s a working example that uses Moment.js and your browser to determine the weekday of a date you provide. The result is populated before the view transitions, and only if Moment.isValid() returns true:

See the Pen Weekday (SimpleSlideView Demo) by Tyler Sticka (@tylersticka) on CodePen.

For more info on what you can do with SimpleSlideView and JavaScript, refer to the documentation on GitHub. If you’re using SimpleSlideView in your own projects, we’d love to hear about it!

Retooling

GitHub introduced a new text editor called Atom last week, and reactions (at least in my Twitter feed) seem divided between fervent desire and snide disregard. For every few people shamelessly begging for invites, you’ll find one or two bemoaning how fickle we all are, how crowded this software category has become, or how our obsession with the “latest and greatest” distracts us from what really matters (what we make).

Some of these emotions are likely the result of the unspoken assumption that everyone in our industry must always know everything (Lyza called this the knowledge burden). But I also believe, regardless of industry, that a natural friction exists between makers and their tools.

We’ve yet to invent a device capable of directly converting our thoughts into physical manifestations. Until we do, tools can only approximate our intent. This means that the distance between idea and execution is often defined by the capability of our tools and our mastery thereof. They tell us what we can and can’t do.

It’s a complicated relationship.

 Some remain faithful to a specific toolset for as long as possible, cultivating an intense and focused knowledge of every feature, quirk and workaround. Peanuts creator Charles Schulz was so fond of Esterbrook & Co.’s Radio Pen No. 914 that he bought all of their remaining stock when they stopped producing it. The pens lasted him through the remainder of the strip’s nearly fifty-year run.

Others transition quickly, abandoning their previous workflow as soon as they feel it may be working against them. English post-punk band The Fall have remained vital and prolific for nearly four decades, in part because of frontman Mark E. Smith’s infamous propensity for changing the band’s lineup with little or no warning.

We’ve yet to discover that magic “one size fits all” process. Until we do, we should encourage the accelerating expansion of available tools while remaining skeptical of any that claim to be everything to everyone. Choice encourages diversity in the types of thought processes our medium supports.

In other words, tools are important. Not for their own sake, but for those they empower to create. Welcome!