Agile Product Management and a lively talk about modern software development by Alistair Cockburn were the themes of the day. The day started off with a hotel breakfast buffet at 6:30. One thing I rarely miss when I travel is a good breakfast to start the day.

My speaking opportunity was, um, unique. Basically a bunch of stages set up around all the food. Oh, and also starting at 7:45 AM. I was able to rush through my presentation and still answer a few questions.

Next was the keynote speaker, Alistair Cockburn. He arrived in dramatic fashion with a bag pipe player leading him onto to the stage, then quickly started reciting a famous passage from Shakespeare’s Julius Ceasar, changing key words from the original play to a more “Agile” flavour. Quite entertaining really. He then proceeded to talk about the main pillars of Agile, interjecting personal experiences and anecdotes. Everyone seemed quite engaged with his talk and gave him a great ovation when he was finished.

We attended the Product Manager/Product Owner Dilemma session presented by Rich Mironov. Very entertaining presenter who identified the key differences between Product Owners and Product Managers. Key takeaways for me were 1) that the overlap between the Agile community and Product Management was very small; 2) Agile development is a big part of business agility; and 3) the Product Owner role adds 40-60% more work than the traditional PM role. Overall a good presentation that concluded with a spirited Q&A discussion.

Watch for our Day 3 summary tomorrow. Be sure to follow us throughout the day on Twitter:

Brendan Harrison
Todd Landry
Alen Zukich

There I have said it. As a marketer, I am disappointed in my peers in their attempts to get their message in the hands of their audience.  Over the past couple of weeks, I have attended a few webinars from other organizations selling software development tools that were truly atrocious.  So here are a few pointers for my few marketers on webinars:

• Stop talking down to the audience – treating your prospects as unintelligent blobs is not the way to connect or be heard. These people are senior developers and engineering managers of Fortune 500 companies not kids coming out of school. Yes, there is a need to bring everyone up to speed and get them to the same knowledge level but that can be done in the first few minutes; don’t do it throughout the presentation.

• Slideware hell:
  • Have a congruent theme – pick one major point and each and every slide in the rest of the presentation should support that theme. Don’t over complicate it.
  • Don’t read your slides – I can read too;  I don’t need you to do that.  I need you to tell me why your point is important so that I pay attention and expand into examples and facts that prove your point.
  • Don’t cram every possible benefit on to a slide – this goes with the previous point – at most 4 bullet points – highlight what is important and use your oratory skills to expand
  • Balance your text with meaningful visuals – I am going to scan your slide in 10 seconds and then turn my brain off. So to keep my attention, give me a visual containing information not just data and each slide needs to tell me something new

• Don’t try to garner respect, earn it. Don’t tell me in your previous life you shared their pain; it comes off as false. Product Managers, you especially  have been the ones at fault for this one.  I am not attending to hear about you. I have a problem; I am looking for a solution.

• Respect their time: webinars are a great vehicle to communicate with an audience but don’t overdo it.  I personally don’t sign up to webinars that last an hour.  I am not willing to give you that much of my time and I would hazard to say neither does most of the potential audience.  Check your abandonment or engagement rates.

Enough ranting and berating of my fellow marketers but together we have to get better at what we do.

Truepath Analysis

Ever been faced with that glassy-eyed expression, the look of unthinking, unwholesome fear when some long, incomprehensible word escapes your geeky mouth and upsets the maiden aunts around the once-a-year, wear-your-best-tie, try-not-to-die-before-the-cake’s-all-gone tea table? OK, so this paper won’t help you in that situation whatsoever, but if you replace your maiden aunts with a bunch of your best geek friends, and replace the tea with a sturdy helping of Dew, knowing how a real whole program analysis solution works might just conceivably come in handy. Some day. “Dude, I was totally stoked when I read this thing, trust me it’s ahh-some.” Maybe.

Anyway, in the best traditions of self-serving corporate PR blogs everywhere, I give you… drum roll please… Whole Program Analysis, the Klocwork Way.

Enjoy.

!(social media)

I will probably get flack for this but I am going to exclude web developers from this discussion of adoption rates about social media in the developer sphere.

Having moved through the technical streams over to the dark side of marketing, I have learned to challenge assumptions and here is one of mine I think needs testing.   In this new age of “social media” and interaction, I have yet to see the leadership in the developer community make any substantive use of it.   I would love to be proved wrong on this one.   Social media, in my view, is really just branding what people have been doing for years: using peers to converse and exchange information on topics and facilitating interaction, even for niche subjects like the merits of static code analysis in mission critical applications.

The adoption rate of the “formal” social media is what I am interested in.  The blogs, twitters, facebook, digg,  etc, you know the brands that I mean.  I have been looking for weeks to find any concrete data on adoption rate and have been hard pressed to find much.

• Technorati  (March 2008- State of the Blogosphere) – 26.4 million blogs vs less than a handful about software development.
• Google Trends indicates that the ratio of software blogging to the main stream is 258 times less.
• Digg has just over 18583 diggs for software development versus over 3 million for marketing
• Twitter volumes are similar 13 900 versus 1.4 million

Why hasn’t the paradigm shift happen here like in other industries?  Online marketers are eating up social networking on Himalayan scale, so why not in development circles.  Speculating on human behaviour is not without its caveats but are technical people so different from say marketers or bus dev people?  In a nut shell – yes.

It’s  not to say developers aren’t social, in many ways the development community has been the leading the wave [Yes, that is an intentional pun for the upcoming Google Wave]. I would argue that software development has been social for well over a decade as best exemplified by the open source movement.  Some of the greatest advancements in software design and productivity have come from major collaborative efforts such as the  LAMP stack, OpenOffice and Android just to name a tiny few and open source has lead to the rise and fall or changed of direction in many a company – see Apple adopting the Linux kernel etc.

My conclusion on all this: the software development community has voted with their feet.  They do not need yet another vehicle to find their voice when they already use mechanisms (open source collaboration, forums, community websites etc) that do the job quite nicely thank you very much.

So if you disagree, take up the sword and prove otherwise.

PS. And yes I get the irony of writing a social media piece about software development on a blog. :-)

A recent article brings up some interesting discussion.   I definitely agree that high quality code can be created without tools or any automation.

But in organizations where you have tight deadlines, fewer developers and more features than ever, something has to give.  To me, saying that you don’t need tools or automation is like saying you want to dig a hole for your pool with a spoon OR climb Mount Everest jumping on one foot OR you get the point…Sure you can write high quality code, but how productive will you be when you have your customers on your ass for the next feature?

Additional comments by the author goes on to say:
The very point of a tool is to change a process. Usually the goal is replacing a manual process, with an automated process.

Well, how is this changing your process?  Isn’t that taking something that may take 1 hour manually down to 1 minute something that is desirable?

Either way there are plenty of tools that don’t change your process.  The ones I’m very familiar with is static analysis tools.  The whole point of them is to extend and embrace your existing process.

But with that said, let’s look at how some IDEs have evolved.  Going from a text editor to an IDE, I guess is changing your process.  But what are the reasons for this?  A more targeted debugger, auto completion, refactoring etc.  What does that do? It makes you code faster and smarter.  I think I’m more than happy to change the process for that.

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 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…