Many years ago at a previous job, I was responsible for pushing our organization to adopt a new ticket tracking system. We decided to use an open source project called Request Tracker (RT).
This was before the days of Zen Desk and similar services. RT matched our requirements best. I worked with our sysadmins and engineers to get the software running and rolled it out to the organization.
It was a failure. People were openly swearing at RT, and I’m sure they were privately cursing me for forcing them to use it.
While I sympathized with the complaints, I felt hamstrung because RT was deployed on an underpowered server and we had not been allowed to modify the look and feel. Back then RT was a bit of a dog both from a performance and aesthetics perspective.
As I worked with engineering to secure better hardware and get someone to assist with the design, the number of grievances continued to pile up.
One conversation stands out to me. A member of the management team told me that the fact that customers couldn’t reset their password in RT was unacceptable and as long as that was true, we couldn’t use RT.
I listened to the objections and kept a list of the issues that were raised, but I kept my focus on making RT faster and more attractive.
A few months later we relaunched RT. It was met with skepticism, but to the credit of my colleagues, they gave me and it a second chance.
It wasn’t too long after the relaunch that previous skeptics were swearing by the system. One of the team members became the master of RT and made a bunch of process improvements that I would have never considered.
What happened to that list of complaints that I gathered? We didn’t address a single one of them. Passwords worked exactly as they did before.
We simply made RT fast and attractive.
I have a simple rule when it comes to user experience: when something is slow and ugly, nothing else matters.
Until you address those two issues, you’re not going to be tell whether other complaints are real or red herrings.
Speaking at An Event Apart is intimidating. Last year, I was privileged to speak twice, and I was terrified each time.
While I thought I gave a good talk both times, I realized after my first talk that I had misjudged the audience. I feared I had whiffed on my only chance to speak and wouldn’t be invited back.
So you can imagine my surprise and delight when Eric and Jeffrey asked me back this year. I swore that this year I would nail it.
What I learned last year was that people come to AEA expecting not only to be wowed by fantastic speakers, but also to take home a tangible things that they can implement.
So I put together a presentation called Mobile First Responsive Design. We know that over 90% of responsive designs are built poorly. This talk teaches you how to build in a responsible manner.
I presented the talk for the first time at AEA Atlanta. It is always difficult to judge your own talks, but based on the feedback from attendees, I think it worked. At minimum, I know people went home with a long list of things that they could do immediately.
I’m giving this presentation two more times. Once next month at AEA San Diego and in October at AEA Orlando.
I’m really proud of the way the talk has come together. I’d love it if you could join me at one of the two AEAs that I’m going to be speaking at.
But even if you can’t make it to San Diego or Orlando, An Event Apart puts on one of the best conferences in our industry. You should attend. And if you do, use ‘AEAGRIG’ on checkout to receive $100 off the price.
That discount code applies for all of the 2014 events—even the ones I’m not speaking at.
I hope to see you in San Diego or Orlando!
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.
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.
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.