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.

6 Comments on “Own Your Process: Ending Agile Guilt”

  1. Matt Gifford says:

    One thing that a lot of people who are really into being agile (and especially Agile) overlook is that both the agile manifesto and the rules of XP call for changing the process if it’s not working for you. Being agile is not about replacing waterfall with another rigid process. It’s about being *agile*.

    • Megan Notarte says:

      Exactly. Which is why Dave’s post about practicing agility resonated so much with me. The basic principles are very simple; the rest is just implementation detail that should be up for customization depending on the team and project.

  2. Thomas says:

    Megan – nice post. Thanks! The post you mention by Dave sbout practicing agility – could you svare it, please?

  3. Marcin Ziolek says:

    Hi, great post! I agree with everything,
    Most cases comes down to the Deming’s PDCA cycle, “..Repeat it, test it, refine it.”