Good start to the Agile 2009 show… seems bigger than last year and well organized so far.

Interesting, we’re seeing lots of people from safety-critical shops – medical devices, telecom, military & aerospace, etc. Anecdotally seems like a big change from last year. Todd attended an Agile in safety critical talk that was a good general overview of why Agile is better than traditional development methods for these shops, but lacked specifics on how, why, etc. There’s an FDA & Agile presentation later in the week which will present an actual medical device case study – that should offer more specifics on how to reconcile the process-heavy, documentation-centric approach to a typical regulated environment with Agile.

We also attended Effective Code Reviews in Agile Teams.  Good overview from the Spartez team.  Originally thought this might be vendor specific (Mark’s blog also touched on this) as Spartez does lots of work for Atlassian Crucible but overall it was a good overview even though all the demos were with Crucible.  Despite that, they kept it vendor neutral and described the challenges of adopting code reviews and the keys to success. They reviewed a bunch of common code review misconceptions and pitfalls.  Namely that people see this as a frantic bug hunt and that it will find all bugs in your code.  Also many developers see this as a “big brother” tool where metrics including every comment will be tracked. For managers, they warned not to expect a clear picture that code reviews have saved you x amount of time.  Well that would be nice. ;)  In terms of how this fits in an Agile context there is definitely one clear message, everyone can join/review/invite/modify a code review.  It’s all about the team (of course!) and about learning, not blaming. They see code reviews not as a tool-centric activity but basically a way to enhance communication or emphasize individuals and interactions, to use an Agile Manifesto term.

Be sure to follow us throughout the day on Twitter:

Brendan Harrison
Todd Landry
Alen Zukich

The exhibit hall was also quite busy, lots of good discussions with attendees.

Off to Agile 2009 next week in Chicago where Klocwork will be both attending and exhibiting at the conference. We’ll blog throughout the week to keep people updated and let you know the latest. There are a few sessions in particular that we’ll be sure to report on and let readers know anything useful we learned (or not):

• Adopting Agile in an FDA Regulated Environment
• Java and Ruby Tools for Code Quality
• Effective Code Reviews in Agile Teams
• Zen and the Art of Software Quality
• Scrum and CMMI – from Good to Great

Be sure to check back often!

I sat in on an iteration review this week and came away feeling great about the team, the process and the strategic direction we taking our products.  Reflecting on the meeting I asked myself what was the magic in the meeting? The strategic direction of the product had been hashed out months ago in a grueling multi day session,  almost all of the members of the development team that were present for the review have been with the company since it’s inception back in 2001  and the meeting covered what it was billed to cover –  there was no “ oh by the way we got this new cool feature into this iteration.”

The magic of the meeting was in what I will call  “The Unspoken Agile Advantage.”  We are working towards our next major product release with 2 week iterations.  We are coming up on the end of an iteration and the team got together to review a demo of a very significant new feature. I sat in unannounced to see our progress first hand.  The demo was solid and it was one of those good news – no surprise meetings.

So what is this magic I keep referring to?  The chemistry of the team’s interaction.  In short order, major new functionality was designed and brought to life.  The team could see the results with very fast turnaround –  2 weeks, while it was still fresh in their minds.  The Agile process lends itself perfectly to “very cool, hey can we do this now” or what about changing that adjacent part of the screen to better expose these capabilities….and on and on.”  The magic was in the rapid review, the visual context of the new functionality in relation to the rest of the product and the dynamic interaction of cause and effect of the new capabilities – all centered around making the overall user experience even better than “the plans on paper.”

I am sure every Agile Evangelist would look at me and say duh…yeah that is what Agile is all about.  As a CEO it is one thing to hear we are on track with the new release and be shown multi-colored spreadsheet or dashboards,  but it is worth its weight in gold to actually see the progress maturing and the ensuing feeding frenzy of ideas amongst the development management and team members in quick iteration bursts.

I recently read a very good blog on the Triangle Offense and Scrum, and it inspired me to write a basketball related item as well.  I used to play a lot of basketball growing up. I played point guard, and was in charge of running the offence, calling out the appropriate play for each time down the court. In order to get the best possible opportunity to score, a lot of things have to go right…1) the proper play for the defence presented must be called; 2) the play has to be communicated properly (from the bench, to the PG, to the rest of the players on the floor at that time) so that everyone understands what to do; 3) Execution…the team needs to execute on the play that was called; and 4) sometimes you need a bit of luck.

Now I’ve been a Product Manager for software companies for a number of years, and developing/releasing a product is very similar  to the basketball scenario above.

1)    Proper play must be called …From a software perspective, this is knowing about the market you play in, as well as the competition you are playing against. You need to understand the weaknesses (or opportunities) so that you can take advantage of it, and get that easy score.

2)    Play has to be communicated properly… Communication is crucial in the development/release of a software product, especially if your team is Agile. Everyone needs to understand the big picture, and this knowledge has to be consistent. What would happen if the PM, chief architect, and VP of Sales all had a completely different understanding of the deliverables for the upcoming release? I’m sure you can figure it out… Also, over-communicate (if that’s even possible). More on communication in an upcoming blog…

3)    Execution… Each team member is a part of that team because they possess a key talent. So whether it is the lead developer, or the QA lead, or the UI designer, they all need to execute ‘the play’ to the best of their ability. If this occurs, then you’re team has given itself a great opportunity to succeed.

4)    Luck… Okay, so back in the day, I’ve hit the odd jumper as a result of a broken play, and while I would like to attribute that to pure skill (ha ha), my reasonable/practical side realizes that there was probably a fair bit (okay, a lot!) of luck involved. Software teams sometimes need a little bit of luck as well because things don’t always go as expected. So when you hear that developer say, I stumbled across this, while fixing that… consider Lady Luck to be on your side.  

I was originally going to write about how software development and golf were related, but other than the amount of cursing I do in both, I couldn’t come up with 3 other good similarities. If you can come up with a few more, then I’d love to hear them. For that matter, I would like to hear how you relate software development to other sports as well…Cricket anyone??

Over the last few weeks, we’ve been working on cleaning up our product backlog, and the one thing that I always find to be the most challenging is the prioritization. I’ve worked on a number of different products over the years, with a number of different teams, and have used a number of different methods to prioritize a backlog, and I thought I would take a few minutes to share them with you now.

1)    Feature rating – This is the method where Excel really shines, because you get to create a cool matrix consisting of your features and a number of categories that are important (such as revenue generation, importance to existing customers, competitive differentiation, and so on). You then put a rating (usually 1-5, with 5 being the most important) in each of these categories for each feature…add them up, and the feature with the highest total becomes “most important feature #1”. Now, you can make this even more interesting by giving a weight to each category, to show which categories are the most important. So, for example if revenue generation is the most important factor in your company, then give that category a .5. Give your remaining categories a weighting, ensuring that the total weighting equals 1. This method can give very clear results, but can tend to be biased (I really like this feature, so I will give it a higher rating than this feature I don’t really like…)

2)    Baseline prioritization – In this method you pick a feature that you feel should be in a release, then compare all other features to this one. If any of the features are more important than that initial feature, then they become a higher priority, and conversely, those that are less important become a lower priority. I have found this method okay, but difficult to get a really good prioritized list…yes you get a list of the most important features, but not really fully prioritized list saying feature 1 is the most important, followed by feature 2, etc.

3)    Gut feel – This method is certainly the least scientific of the bunch, but it still relies on instinct, and can work well if you have a really good grasp of the market and your customer base. In the times I’ve done this, I’ve also tried to take the concepts of method 1 above, and apply that… so for example, Feature A has 6 different customers crying for this, will definitely generate more revenue, and further differentiates our product from our competition…sounds like our top feature for this release! This is the method that I find the most effective because you get to apply a number of concepts from a number of different methods.

There are a number of other methods out there that I haven’t used, so I would be interested to hear what experiences you have had with them, or with the ones I’ve listed above.

There was a recent blog on whether or not you should have bugs (that were not found during the most recent iteration) added to your product backlog, or kept in a separate bug backlog. Here at Klocwork we have a defect database that is closely monitored by Support, dev, PM, and so on…suffice it to say, it has a high degree of visibility within the organization and will probably never go away. Being an Agile company we also have a product backlog that is reviewed daily and prioritized regularly. Every two weeks (coinciding with our iteration planning) PM and Support get together to discuss the highest priority bugs, and to determine if those bugs should/need to be added to the backlog for the next iteration. A key piece to this process is using tools to maintain this backlog. The backlog tool, which also has an integration with our defect tracking system provides a tight correlation between the two, and a level of automation that makes life a little easier for everyone. Once added, these bugs are prioritized just as we do with all of the other features (stories) we have in the backlog. We also have weekly status meetings where the most recent bugs are discussed, once again to ensure they receive the proper attention.

Since we are in the bug-finding business, we take bugs very seriously and adding them to our backlog (and as a part of our iteration planning) helps ensure we address them quickly.

There was a recent blog on the top 10 good reasons for Scrum, so in the spirit of equality, I thought I would do one on the top 10 reasons not to go Scrum. Now, before I get started, let it be known that I am a huge fan of Scrum and agile (so much in fact that I am certified as a Product Owner), but there are definitely situations where it just might not make sense to go that route.

1. Your development team is geographically dispersed. In my opinion, this is the main reason why it would not make a lot of sense to go Scrum. Scrum (and agile) are all about communication, and even though technology has made it easier to communicate across the globe, a winky-face over MSN cannot get the same message across as a face to face conversation.

2. If you are currently meeting deadlines and release dates. I’m a big believer in the adage, if it ain’t broke, don’t fix it. Why would you want to mess up something that is working for you? Short answer…you don’t…

3. You cannot get complete buy-in or 100% commitment from management, development, PM, etc. If a PM cannot actively attend meetings, or management wants to make rash decisions outside of the team, then it just will not work…don’t even bother trying.

4. If people need complete clarity about the solution before even starting the project. The very nature of agile/scrum lends itself to this just not happening.

5. You have a fixed deadline, with a fixed set of requirements. This happens all the time…perhaps you have specific functionality planned for a big event, or a big customer. If this is the case, then it might make sense to manage this using more traditional project management methods.

While the original blog that inspired this had 10 reasons, my time this iteration is up, so I will only provide 5. If you have others you’d like to share, feel free to leave a comment.

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…

Interesting paper and presentation (pdf) from Emmanuel Chenu at Thales Avionics that describes how they’re using several Agile concepts as part of their safety-critical avionics software projects. With the exception of pair programming, my read is that much of this is mapping activities that have been done in a safety-critical environment (e.g. test driven development) to several Agile principles, rather than the introduction of concepts that are foreign to safety-critical development. The other one that probably hasn’t been done in most safety-critical shops is continuous integration, but I’d argue that CI (or at least a “build early and often” philosophy), has transcended Agile and is just becoming “the way things are done”, regardless of whether you’re a “Big A Agile”, agile, or iterative development shop.

Either way, it’s interesting how even the most heavy, formal, process-driven development teams are looking at aspects of Agile they can embrace to make their development more flexible, responsive, while still producing highly reliable software. Of course, as he notes, there’s obviously a limit to how “Agile” an avionics development team can really become given the level of formal documentation required through all aspects of a DO-178B project. I’m pretty sure if you ever submitted this kind of documentation to a certification authority they’d probably not accept it:

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?