This post may be somewhat of a ramble, but it puts to paper as it were my experience on software process.

I’ve been fortunate enough to be part of a company and team that has started small and seen significant growth. When I began I was one of 3 new hired developers adding to a team of one other person. Today we have around 15 developers, and 15 others in related professions. Along that path of growth I’ve seen many things change. Some for the good and some for the not too bad compromise.

When we were small you can imagine what it was like. Typical startup with cowboy code and process type mentality. I can remember many long nights for releases and numerous points of regression when we released code. As we began to grow we got more serious about testing and added a QA team. We began learning about testing practices like unit tests, integration tests, etc. Around this time we were of the mindset that whatever Microsoft produces is AWESOME. This lead us down a path of using Team Foundation Server and other VS tooling for tests. Honestly, things worked fine. Until… we began to work with less technical people. We began interacting more directly with stakeholders. We hired less technical QA people to help with more manual testing. Our design team also typically worked on Macs. This all began to add a lot of friction to the workflow.

The problem with the workflow we were using is that it was focused on one stakeholder, the developer. We were forcing tools and processes on users that didn’t really want to participate. This is really when we began to explore new ideas.

Our first forray into sans TFS was Agile Zen. The kanban board was the latest rage and Agile Zen had a very user friendly interface and a reasonable pricing model. From our stakeholders point of view it was a huge improvement. We were now on our way down the path of continuous improvement, we just didn’t know it yet.

Kanban for us started out well, but the longer we used it things began to turn into waterfall again. Each column on the board represented the next step in our waterfall process. Later we heard the term “waterboarding” and knew that the term hit too close to home. We brought in a consultant to help us zero in on where we were going wrong. One of the nice things brought up in conversation is that it doesn’t really matter whether you use Kanban or Scrum. You need to look at the whole picture from when an idea occurred to when it was delivered to users. You also need to continuously re-evaluate and improve. You mean continuous improvement isn’t just for code quality? If you’re only analyzing velocity and story points you’re missing a big part of the equation. How did that story end up on the board? How long did it take to get there? Who had to talk to who in order for it to get attention, or approval? In my opinion this is when things began to really improve. We removed many of the unnecessary or wasted steps, and began to focus on getting value into users as quick as possible. Oddly, because it wasn’t the cool kid anymore… ended up switching to Scrum.

Scrum? Don’t you realize that time blocks suck? It messes with the natural flow of things. Sure, but it also helps us keep scope to a minimum. It also gives us a goal of deploying every two weeks, which was a big improvement from where we were. The point here is to do what makes sense for you, not you as a developer, you as an organization. Including all the stakeholders from developers, designers, QA, business stakeholders, product people, etc.

Next post I’ll discuss briefly how we as an agile development team deal with regulations like Sarbanes Oxley, HIPAA, etc.