I’ve given myself some time off from anything that resembled a classroom since graduating from college *gulp* two years ago. I figured that I had worked hard and reaped the results in the form of an interesting job in New York so I deserved a bit of time off from learning. I’ve had fun on my little break from academia but I’ve also realized that I haven’t taken a break from learning at all, I’ve just shifted my focus to things that fall more on the unscholarly side of the spectrum. As much as catching up on 5 years of neglected fiction and honing my vegetarian cooking skills has been enjoyable, there are some incredible opportunities to learn something a bit outside of my comfort zone that are low-commitment and easily accessible that I would be remiss to continue ignoring.
On Wednesday I overcame my intense dislike of walking into a room full of people I don’t know (if only I was kidding) and went to my first General Assembly class. GA is a coworking/education space that quite frankly seems way too cool for me to be hanging around (I’m going to have to get over the fact that I am painfully un-hip and just own it.)
My first class in close to two years was the first session of a 3 part series lead by Peter Bell focusing on managing software development, this first session was specifically about how to specify software as a non-developer. It was great both for future endeavors but also in the context of what I’m currently working on professionally, as my company is still in the process of working out the kinks in our new development process and we don’t have anyone with Peter’s expertise hanging around to give us these insights. A lot of ideas that I have about why things are working (or aren’t) in how I’m currently managing projects at work were validated. The class was aimed at founders/small companies but lets face it, managing software development doesn’t vary all that much it is just the quality of the final output that matters. At a lean startup you are just going for a viable product, in an established company you might want to put it through a few extra rounds of polishing & tweaking before you release (or at least you would think, we’ve been known to not do that also to really *stellar* results.)
I went into the class with an inkling of an idea that agile development is a better approach overall but after about 90 minutes I was feeling validated in my feelings about managing the development process. Something I’ve seen a lot in my current position is how when you get locked into requirements early on it makes iteration at best painfully difficult and at worst impossible. Peter called this “locking in ignorance”, I’ve seen it in 20 page buisness requirements documents that took months to complied and have been rendered useless due to the 17 change orders we’ve attached. I’ve unfortunately been working on projects where we are locked into some variable early on and deliver a product that we then find out no one is using. Since I work on all internal-facing projects we don’t get the same kind of feedback as a product with end-users that are actually in the marketplace so we get stuck in a place where we don’t necessarily have to listen to the needs of the customer and that has hurt us significantly. We implemented a new product development specification process about 6 months ago that was 100% upfront design heavy but… that didn’t work either. The process was clearly developed by management as opposed to thos eof us who would be working in it every day, so they liked the huge business requirement docs and sign-off from many people but that quickly failed also. It was heartening to hear that this is probably to be expected, though a large part of me wishes that I could have brought my entire team to this class about 6-8 months ago so that we could have skipped reinventing the wheel and discovering a lot of this on our own.
Something I can definitely push for more of in the current process we use is building more time for iteration encouraging flexibility in our vision for the end result. We also need to become more realistic about what can be accomplished in a given time frame. Peter mentioned that you’ll usually end up delivering about 2/3 of the features you expect out of the initial round of development because as you work through them you realize that some features are going to take more time and or require iteration to make them even better and you’ll also realize that some of the features you though you wanted don’t really make sense. That is something as a company that we need to work on– accepting that as we go into development we don’t know what it will look like 100% at the end of the build period but if we can accept that uncertainty that we will have a better product at the end for it.
Outside of my current work, it was interesting to gain some perspective on how freelance/one off design work is handled. I definitely would have been the clueless girl looking for a fixed bid project with wireframes and highly detailed specs thinking that was the right way to go about it until very recently. So if nothing else Peter definitely just saved my future company a bit of hassle :)
The deck from Wednesday’s session can be found here, but I’m not sure how much sense it makes on its own so maybe you would just be better off going to Peter Bell’s upcoming GA workshop. I had held off on going to GA classes before due to the cost but I can say with certainty that this was worth every penny.