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, specifically this first one was about how to specify software as a non-developer for a business audience. It was actually great both personally but also in the context of what I’m 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. It was great to validate a lot of ideas I had about why things are working (or aren’t) in how I’m currently managing projects at work. Hearing it come from a developer it makes a lot of sense even though we thought we were reinventing the wheel and no one else was having these issues! 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.)
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 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 a whole lot of process issues!
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 call it “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.
I think something I can definitely push for more of in the current process we use is building more time for iteration and encouraging more flexibility for iteration. I think 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 accomplishing about 2/3 of the featured you expect out of the initial round of building 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 them don’t 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.