Chad SturtzA Journey Through Software

9 months ago my daughter was born and since then I’ve had trouble finding much time for career development outside of the office.  One of my solutions to the problem was to form a sort of user group in my office that would meet over brown-bag lunch presentations.  I had already given a few brown-bag lunch presentations myself, trying to set an example, but only one other person ever did a presentation.  I thought that if I wrote out what it was I wanted to do and how I expected to to be valuable to our team, maybe there’d be more buy-in.  Plus, if I could get everyone to do just 1 or 2 presentations a year, we could have a meeting every other week.

I approached the entire office with this proposal and was very thrilled to get buy-in from a large percentage of my coworkers.  I volunteered to do the first presentation and asked 2 of my more active coworkers to take care of presentations 2 & 3 just to get things rolling.  Presentation number 3 is next week and after several emails, no one else in the office has volunteered for presentation #4 (or any other future slot).

I found out that for 2 people, the problem was coming up with something to talk about.  I have provided topic ideas as well as offered to brainstorm with anyone that was willing to present but unsure of a topic.  Still… no one has offered to present.

At this point I’m assuming it won’t pan out.  I felt it was acceptable to send a few emails stating that we needed people for upcoming presentations seeing as how I got a large amount of buy-in before this whole thing started, but I’m not going to push it.  If no one comes forward, I’ll just continue giving presentations when I can hoping that maybe someone else will jump in every once in a while.

I have to admit, I’m a little confused as to why so many people thought it was a good idea but then won’t participate.  I even found out that for presentation #2 (I was out sick), no one set up a virtual meeting or conference call for the few remote people assigned to our office.  Furthermore, those remote people never IM’d, emailed, or called anyone asking what number to call in on or for an invitation to the virtual meeting.  Maybe I’m the only one that feels there’s value here…

This past Friday (the 16th), I did a brown bag presentation on reducing feedback cycles on software development projects. Slides here: http://bit.ly/bORrkW. Unfortunately, the slides contain only talking points.. the real value came from the discussion. Also.. while we did record the audio, it contained some discussion specific to internal projects/processes that I’m not going to share.

First of all, I want to mention that a lot of the conversation went back to the Cost of Change curve. Take my code compilation example. Finding a compilation error in real-time will (theoretically) make the cost of fixing the error cheaper than finding it after a day of coding. The example was that using an IDE that performed real-time compilation was a much shorter feedback cycle than going to a command prompt and running your build manually. The other notable example that builds on the Cost of Change Curve was scheduled code reviews (montly/weekly/etc) vs. pair programming.

One of the final feedback cycles I presented was that of the completeness of an individual feature of the system. We talked about the Cost of Change Curve here as well, but most of the discussion focused on what other things we may get by reducing this feedback cycle.

I began by talking about how a single feature progresses through the Waterfall process. Pointing out that you won’t get feedback on the completeness of a single feature until you’ve reached the Validation phase where your QA has had a chance to test the feature. This gives us a feedback cycle of the length of time between when dev initially started on this feature and when it was tested during the Validation phase. How long are we talking here? Months probably.

So, now it’s time to ask how one would reduce that feedback cycle. In order to do that, we need to bring the validation phase closer to the point at which development began on this feature. Since the traditional Waterfall approach moves the entire software system from phase to phase, it’s not possible without re-defining the process.

We then took a look at this feedback cycle in Scrum. Sometime after the start of a sprint, you start development on one of the user stories you’ve selected (aka feature). Considering the goal is to deliver this feature at the end of the sprint, at some point you’re going to validate this feature, completing the feedback cycle. So, here, the feedback cycle is at most 1 sprint.

We continued the discussion down the path of what things we get by reducing the feedback cycle in this way. The most profound impact is on our feature estimation because the feedback cycle on feature estimation accuracy is directly tied to the feedback cycle on feature completeness. Now that we’re attempting to complete individual features within a single sprint, we’ll also get feedback on our estimation of that feature within the same sprint.

We spent some time talking about what you can do with this information. Essentially it means that you can better estimate the remaining features of the system. This in turn gives you a more accurate project schedule, which in turn allows you to confidently discuss project timeline and budget predictions with stakeholders and customers. Also, when someone asks what features won’t make the deadline, you’ll be able to answer that question and others like it.

Hopefully that’s enough text here for you to get a feel of the presentation. Feedback cycles is a broad topic. In this presentation I hit some things at a very high level and went a little more detailed on others. My goal was simply to communicate that reducing any feedback cycle is beneficial (some to a much smaller degree than others). I also needed to address a wide audience: devs, qa, project managers, etc. While I did get some great feedback from a few of the attendees, I do remember seeing a few faces that looked lost. Maybe I’ll follow up with those people.