Product development is truly a difficult process, especially when it involves a big team of people. Everyone has their distinct roles, and people are constantly inventing methods to keep those roles in check and make sure that everyone is working toward the same end goal. “Agile development” is one of those methods that is in place where I work, and while I’m sure it works for the most part, there is always still room before you can truly call any big development team “agile”. I’ve been thinking about what the major themes of Agile are (to me) and why I think they are important.

Always Be Communicating

I’ve always been really bad at communication. Partially because I think people can hear my inner voice, when they really can’t. So of course I would go and do something like chat with a developer about a minor design change in the MIDDLE OF AN ITERATION FOR GOODNESS SAKE and not tell anyone else about it. The least I could have done was to notify the leads just so they are aware. Live and learn. This is why I try hard to keep my design documents up to date so that anyone can go take a look when something does change. Of course, I don’t always do that right away, which is probably why I got called out, but I think being able to hash out issues directly with a developer is one of the great things about working agile-ly. We don’t always need a committee of 10 to approve and have a say in every single design decision that is made.

Embrace Constant Change

The thing with Agile is that, well, you’re supposed to be “agile”, right? Which means that you’re ready for anything that pops up, maybe an architectural change, a design change, API change…anything. Breaking down features into achievable mini tasks is really the key to managing this. I don’t expect to see an Eiffel Tower at the end of each iteration, but I do expect to see small things like where the footprint of the tower will go, and defining placeholders for where the snack carts can hang out, and approximately how many trees can be in the lawn in front of the tower. That way, when someone decides that the snack carts have to be at least 50 feet from the tower footings, we aren’t going to freak out about it.

There’s No Final Build ‘Til The Product Ships

If you have automated builds of your product that run daily or more often than that, there’s no reason you couldn’t put in temporary code for the sake of experimentation. Yes, that’s what I said. Don’t break code, of course. I work on designing mobile apps. There’s no better way to validate a design than to have a developer build it and let you install that on your phone. If it works, great. If it doesn’t, then we iterate and make it better in the next day’s build. Of course, once you start getting into code freeze and testing, it’s a different story. But in the early stages, I think it’s fine.

Dogfood It!

I’ve always felt that the best indication of progress (or lack thereof) for a software product isn’t those Gantt charts or checked-off todo lists or whatever people use to track work items. The best indication of progress for a software product is to install the actual product and use it. Of course, much easier said than done for some products, but if you’re working on a tool that you actually use on a daily basis or could use, there really is no reason you can’t run daily or weekly builds.