When I first started at Klocwork, I didn’t really know a lot about source code analysis. I understood the basic concept of how it finds bugs in software, but that is was essentially it. Sure I knew about Memory leaks, but I truly believed that they were only found a day or two before the GA date…at least, that was when our testing team always found them.

In one of my teams prior to joining Klocwork, we used Scrum. We were hard core, with daily 15 minute scrums, retrospective meetings, sprint planning sessions, defining “done”, secret handshakes, the whole 9 yards. We also broke our features down into small tasks, and those tasks were written on cue cards and then stuck to a big wall for all to see. What a great way to see the progress of a sprint. We had green cards for development tasks, blue cards for testing, yellow cards for documentation, and red cards for bugs. I remember how after 2 or 3 days into a sprint, the red cards would start showing up, and developers would then start addressing them. Since one of our team ‘rules’ was each person could only have a single task checked out at one time, our developers had to check-in the green card they were working on in order to tackle a red card. By the end of a sprint there were always a number of red cards left, which by definition, needed to be addressed first in the next sprint. I’m sure you can imagine the enthusiasm of heading into the next sprint knowing there was a wall of red cards to address first.

Anyways, my first few weeks at Klocwork consisted of talking with a lot of people; customers, prospects, etc. These people knew source code analysis, but they only knew the traditional way of source code analysis (SCA), and not the new generation of SCA where developers check their code before they check-in their code. I remember thinking I must be missing something…why is this so hard for these people to understand?  Source code analysis turns a lot of those red cards into green cards.  For more info on how SCA and agile can work together, check out this webinar I recently did…

Ever had to work on a “special” project and really didn’t know where to start? A team I worked with was faced with this not too long ago…we had to put together a complete business plan for our products. This complete business plan included understanding everything about your business, and I mean everything…average deal size, average discount per deal, regional breakdown of deals, deals with multiple products included, SWOT, positioning, and so on. There was a ton of information we needed to pull together in a relatively short time, and we really didn’t know the best approach to take to address this. Having been working on a scrum team for about 8 months, I suggested we try to tackle this using some of the principles of scrum. So we proceeded to break down the effort into a series of tasks, and then prioritized these tasks, thus creating our backlog. Tasks would be assigned, and daily meetings were then used to report our progress on them. If a new task popped up, which usually happened, we added that to our prioritized backlog, and continued on. Everyone on the team knew exactly what had been completed, what was being worked on, and what was still outstanding.

There are probably a number of other approaches you could take to deal with this type of project, but I thought applying some Agile principles worked out very well. Anyone have any other applications of Agile, not related to software development they can share?