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.

Fantastic intro to new srcset and sizes

I normally don’t write a post simply to link to another article, but if you’ve enjoyed the things I’ve written about responsive images, you really should read what Eric Portis wrote about Srcset and Sizes.

Eric describes the logic behind srcset and sizes, how they are part of the new picture proposed standard, and how to use them.

Easy. Peas.

What’s New in hideShowPassword 2

Last June, we released our hideShowPassword plugin for improving the experience of password-entry (particularly on mobile devices). As of this writing, it’s our most-starred and most-forked project on GitHub.

We’ve released a handful of incremental and bug-fix updates since then, but today we’re shipping a full-fledged Version 2 with several noteworthy improvements.

Simpler Usage

The plugin’s “inner toggle” feature tended to steal the show, yet its syntax was verbose:

$(selector).hideShowPassword(true, { innerToggle: true });

We now support a simpler, shorthand syntax for enabling the inner toggle:

$(selector).hideShowPassword(true, true);
 
// enable toggle but hide till input focus:
$(selector).hideShowPassword(true, 'focus');
 
// using shorthand method:
$(selector).showPassword('focus');

Improved Accessibility

My personal favorite feature is the improved accessibility of the inner toggle button. Some changes we made based on real-world feedback:

  • The toggle button element is now a <button> by default (it was previously a <div>).

  • Several accessibility attributes have been added to better communicate the purpose and state of the button to assistive devices.

  • The toggle should now be keyboard-accessible, with space and enter key events attached where necessary.

We understand every project’s different, and you may need to tweak some of these new properties. Luckily, Version 2 also includes…

Overhauled Options

Just about anything we could make an option, we have. There are so many new options, we had to re-organize the options object to accommodate them all. See the full list here.

Built For jQuery and Zepto

Version 1 of hideShowPassword supported Zepto, but we’ve decided to simplify the plugin’s dependencies by only supporting jQuery from here on out. This makes sense to us for a few reasons:

  • Zepto’s data module was required, necessitating a custom build of Zepto to work at all.

  • The plugin’s inner toggle features could be unpredictable given Zepto’s simpler width and height calculation methods.

  • Zepto does not support AMD, and likely never will. We introduced AMD support to hideShowPassword in our first minor update based on developer feedback.

  • While Zepto’s modest file size remains an attractive feature, its performance once loaded may not be so competitive.

Get It Now!

All the aforementioned improvements (plus more fixes and tweaks) are available right now on GitHub (which is also a great place to report issues or request features). Check out the live demo if you remain unconvinced.

If you use the plugin in a project, please drop us a line and let us know. We’d love to hear about it!

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!