Agile. Now the corner-stone of any development organization, agile processes and development methodologies have taken over businesses, tech. articles, and the lives of the engineers tasked with playing their song. I’m not sure you could find a software engineer job listing that didn’t ask for “agile experience.” The entire idea behind agile processes is to enable us, as engineers, to respond quickly to changing business requirements – to be agile – right? If that’s truly the case, then why are they so painful?

For even a small team of 4 contributors and a dev manager (or program manager, product owner, etc), [sprint planning] is 2 days worth of salary for 5 people to just decide what we’re actually going to be working on. That’s really expensive.

Take for example Scrum, in its purest sense. In a nutshell and in contrast to “Waterfall Development” Scrum enables us to work in (typically) 2-week periods of development (known as “sprints”), so that we don’t spend ages up-front ironing all of the business requirements, design specs, user interactions, etc. just to watch them change in a month. To start every sprint, we typically spend a day or two selecting the stories that have written by our product owner, ensuring that they fit within our velocity, and then breaking those stories down in to actionable tasks. For even a small team of 4 contributors and a manager, that’s 2 days worth of salary for 5 people to just decide what we’re actually going to be working on. That’s really expensive. If you could eliminate that, you get another engineer on the team for “free.” Not only is this an expensive process, it’s absolutely soul crushing for those involved. During a sprint, we spend an alleged 10-15 minutes (which usually turns in to 30-45 minutes) for our “stand-up” every morning so that everybody is on the same page.

As another example, let’s look at Kanban. With this, we’ve managed to kill off the 1-2 day sprint planning meetings, but we still have the the stories on our Kanban board, and we still have our overly-long and grueling stand-up. Further, because we’ve removed the sprint planning and task break down, the level of detail that ends up going in the stories is far too high and the number of meetings to try and clarify that detail quickly gets out of hand. Not only that, because we’re constantly evolving a single story, the amount of work that ends up part of it grows, and that kills our velocity. What started out with good intentions has turned problematic.

That’s two different flavors of “Agile” processes, both still have weaknesses.

Saving Time And Money

One of the more recent changes I tried to implement on one of my teams to help mitigate some of this was to reduce the amount of time spent in our daily stand-up. A stand-up generally tasks each member of the team with answering three questions:

1. What did you do yesterday?
2. What are you doing today?
3. Are you blocked?

The first run at this goal got us down to:

1. What’s remaining on the story you’re working on?
2. Are you blocked?

The end result was:

1. Are you blocked?

In essence, the entire meeting was reduced to about 60-120 seconds of time where everybody working on the project would be in the same physical place at the same time to facilitate getting a hold of somebody if you needed to. That’s really it.

Anything outside of answering that single question has no real bearing; nearly all of the other information is available by looking at the Kanban board, and if more detail is needed about something, that’s a smaller conversation that doesn’t require the entire team and can be organized with “I need to talk to you and you after this.” In essence, the entire meeting was reduced to about 60-120 seconds of time where everybody working on the project would be in the same physical place at the same time to facilitate getting a hold of somebody if you needed to. That’s really it.

Expanding The Idea

What if we could throw out nearly all of the process? The “Processless Process”?

Most recently, two co-workers and I participated in our organization’s Hackathon. We took a slightly different approach than other teams did. While we did produce some great technical artifacts as well as some great metrics and statistics, we had a completely different focus; hack the process.

Our goal was to see just how much work we could crank out in two days using 3 people if the entire process was effectively thrown out. Bring two engineers and a creative guy together to just do their jobs without things getting in the way and see how successful could they be.

It turns out that if you let you talented and skilled people do what they’re good at and passionate about, a lot gets accomplished in a short amount of time.

It turns out that if you let you talented and skilled people do what they’re good at and passionate about, a lot gets accomplished in a very short amount of time. While we didn’t create production-ready code by any means, we did generate an entirely new site design, implement a fault-tolerant API abstraction and caching layer, migrate our assets to .webm and .webp saving between 60-80% of our file size, put together a new search results page with three different layout styles, and a new detail page. In two days.

The greatest outcome from that endeavor came from demo itself, garnering comments such as “Why aren’t we [working like this] today?”

Where Are We Now?

While it’s taken quite a while to grow roots, the fruits of that labor are beginning to bear. There a few experimental projects running through the organization now, and while the idea has been given a marketing-esque name, the concept itself is intact; dissolve the unnecessary process over-head, enable individuals to thrive and succeed without putting up roadblocks, and watch the speed at which development progresses.

These changes have enabled us to work very loosely and iteratively with the business. Our requirements are now akin to “this is kind of what we’re thinking” and our UX comps are more of a “this is kind of what we want it to look like”. We have a closer relationsihp with both UX and the business to refine and iterate on the design and the concept itself. We’re no longer risking throwing out large portions of work when we come across something that doesn’t work for one reason or another.

Our sprints, meetings, stories, story planning and task breakdown, and our daily standup have all been replaced with walking over to someone or shooting them an IM or an email and asking a question. We have one weekly meeting, for about 30 minutes, to go over customer and business feedback. That’s it.

Further, our time to market is drastically reduced. Pushing our in-progress code to production behind an A/B test that’s limited to a very small fraction of our users enables us to gather real-world metrics from our actual customers without affecting the bulk of the site.

Feedback across the board has been positive; the engineers like it, the UX/UI teams like it, the PMs, POs, and dev. managers like it, the directors like it. Thus far, there’s not been (to my knowledge) a single negative thing that’s been said with one exception – the concern that we’re moving too fast for the business. I’m not quite sure what that means yet, but I think it’s a good thing.

Finally, we’re being agile instead of doing agile. And it feels good.