Jan 19, 2017

Agile: Why it’s ok to suck

I’m not going to rehash the same old Agile marketing jargon that you’ve heard or read a thousand times before. Google “Agile” for a comprehensive summary written by someone who’s most likely a better writer than me.

Instead, I’m going to tell you the truth about what’s up with Agile at Aspera: We work everyday to improve ourselves. So, why share this fact with the world? Well, to truly develop industry-leading technologies, we must constantly be motivated to develop a better process that helps us build a product to meet our customers dynamic needs.

This core idea is the motor behind our continuous effort to improve and reinvent ourselves. In the 1.5 years that I’ve been a Scrum Master at Aspera, the development department has seen countless changes and numerous experiments in their Kaizen quest (that’s Agile marketing speech for continuous improvement).

How it works

Let’s start with our Product Owners. These are the people who constantly sort and refine the required changes in an ongoing effort to find better ways of bringing all the necessary information about new features to the development teams as early as possible.

They do this by creating User Story (Scrum for Change Request) templates which customers and consultants fill out. Developers then analyze this information to understand not just “what” - but also “why”, new features are requested. This process ensures that our developers construct the best way to implement requested features. Not knowing the “Why?” sucks. We changed that.

Because developers are actually part of a Scrum team (Aspera practices the Scrum variety of Agile), this exercise also safeguards that our trusty developer doesn’t become a code monkey. Instead, developers are given the responsibility to decide the “how” for the implementation. We trust the people who actually know the application best to make the best decisions. Leaving technical decisions to someone other than the developers sucks. So, we changed that too.

Getting things done

Our developers do both the testing and the QA (in round robin fashion). We don’t first implement a feature and then have it tested afterwards by different people. Testing is actually part of our Definition of Done. This is a handy set of technical requirements and tests that a given feature has to fulfill and pass before our developers release anything.

Rather than being imposed on them by a meddling bunch of middle managers, the Definition of Done is a document that is created by the developers and that defines a set of quality-criteria which is general enough to be applied to all things under development, but that is still meaningful. Our developers come up with their own set of quality control criteria, and they perform all necessary testing. Their code ships only when they feel satisfied that it has met all of their determined criteria. This ensures that they feel responsible and invested. It says that Aspera trusts them to get the job done, and this makes them take their role seriously. Developers who don’t test their code and quality criteria established by managers suck - and we changed that.

We have new shippable features ready after every 2-week Sprint. A Sprint is an iteration in which we develop a certain amount of new features. But, we actually only deploy every 8 weeks to minimize efforts required on the customer side. This lets customers and our consultants that represent them check out new changes every 2 weeks in our public Sprint Review meetings. Stuff that’s really hot can be steered into the right direction on the fly since we have dedicated people to give immediate feedback on questions regarding features that are currently in production. Not giving stakeholders an impression of the current state of development sucks. We changed that too.

Staying happy (to suck less)

We also have a retrospective every 2 weeks to review our process. This is where we decide on old habits to drop and new things to try out in order to reach maximum productivity and fun along the way.

Yes. Fun.

Depressed and worn out developers don’t create the greatest products. They don’t come up with new ideas on how to improve something. They may even stop caring about the increment (or feature) that they’re building altogether.

So, we let our developers have some fun! Not having fun sucks.

Also, they get to decide which of our teams they want to be on. Currently we have four core teams: Cyberdyne, Weyland, Umbrella and Tyrrell. They got to choose our team names. Can you guess the theme? (Click here for a graphic hint.)

Developers also decide where they want to sit because why should anyone other than those guys decide this sort of thing? We have remote participants in meetings who work from home due to their family situation, so we set up a live video feed to make them part of the team. It sucks to feel like you’re just a worker bee delivering a pre-assigned work package.

We live in an information age and do knowledge-based work. Every day we build and improve on technology that helps global enterprises optimize their software licenses, protect themselves from risk and save millions of dollars. That stuff requires a fine-tuned process like Scrum. Connecting the right people to talk about the right stuff is paramount for creating such a tremendous product.

Of course, this also means bringing the right cookies to the meeting. That’s what I do.

Topics: SmartTrack