Main topic of today is using Agile in an FDA regulated medical device context. Sounds like an impossibility I know, but the folks from Agiletek and Abbott presented a very interesting case study on how they did it. They started off by presenting “the way it used to work”, highlighting an older product development cycle from the 1990s that had very strictly defined dev phases, including a 10-12 week integration cycle – yikes! When they decided to implement Agile on a more recent project they broke up their 3-5 year dev cycle in 6 week iterations. Here were the biggest barriers they found to achieving this:

• Documentation – they tackled this topic upfront. There is a perception that the FDA wants truckloads of docs from medical device manufacturers. The reality is, according to the presenters, that’s not the case… the FDA wants “enough” documentation to demonstrate your process (“least burdensome” in FDA-speak). The biggest area is of course documenting requirements which they did through a Capability Matrix.
• Requirements – this required a big culture shift. They talked about past projects with 14 month requirements definition phases… which still didn’t capture everything! Now, they realize it’s a myth that all the req’ts can be defined upfront, and as the gentleman from Abbott stated: “Your requirements are final when the product is retired from market.”
• Software verification and validation (V&V) – they emphasized a risk-based approach. Run code inspections and reviews on the most critical areas of code. Keep your requirements focused and high-level so testers are testing the important stuff.

Anyway, here are the results they found by modernizing their development with Agile: higher visibility, lower costs (estimated schedule and team size reduction of 20-30%), higher quality product (availability of working software allows for continuous V&V), and overall the project had a steady pace to it rather than mad integration scrambles or backend V&V chaos.

The one big aspect of Agile they weren’t able to implement is the customer feedback component. This is mainly due to the limitations med device companies have around “pre-marketing” their product.

All in all, a very interesting case study. Be interested to hear where anyone else has seen this done in a highly regulated environment.  Signing off from Agile 2009… be sure to follow us on Twitter:

Brendan Harrison
Todd Landry
Alen Zukich

Busy day 3 with a number of sessions.  We attended: Strategies for Replacing Systems in Agile Projects, How to Evolve a Product Backlog, Agile Metrics and Four Core Concepts for Fast User Feedback.

In the discussion for Replacing Systems I certainly got surprised by one of the strategies.  The first release of the replaced system should be inferior to the existing system.  At first I thought Niklas was crazy but this started to make sense when he describes that there are infinite ways to compensate users and make it balance out.

The next session I went to was the “Evolution of Product Backlog” given by Ronica Roth.  This session took us through a couple of real cases (which is always nice) of how they evolved the backlog. Good session but I felt I needed more details.

Probably the best session I’ve attended so far was “Agile Metrics” by Dan Rawsthorne.  The key messages given were that you don’t just measure something just because you can.  Instead you measure things that tell you something about your team, product or progress.  We learned how to measure production during sprints, after sprints and then got into the hardcore stuff of release metrics.  I think I’ll leave the release metrics for another day ;)

Todd also attended “Four Core Concepts for Fast User Feedback”.  Overall Todd thought it was the best session he had attended so far as well. The presenter was engaging, and definitely knew what he was talking about. In the session he went over the 4 key principles required to run a good interview, those 4 being Context (talk to users while they work), Partnership (let the user lead, after all, they know more than you), Interpretation (figure out the meaning of what is happening), and Focus (know why you are there).

Watch for our Day 4 summary tomorrow and be sure to follow us throughout the day on Twitter:

Brendan Harrison
Todd Landry
Alen Zukich

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

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!

Tom Johnson’s recent blog article (a must-read, involving ice picks and eyeballs) reminded me of one reason we want to move Klocwork’s user communication content to a Wiki: we want to talk to our users. Crazy idea! Let the doc team talk directly to the users? What stupid things might those literary types say?

I confess that it’s taken me a long time to get to this point. Johnson says tech writers are often subject to figurative lobotomies, like “don’t bother the subject matter experts; they’re busy”, “don’t use your own voice on video tutorials”, and “don’t talk to your users”.

So we’re crippled from the start, and some of us take years to discover that we produce the most helpful help when we become more of an investigative journalist, actively engaged with those who create and test the tools and those who use them. (It seems fitting at this point to mention that one of the writers on the team is a former newspaper girl who recently created a video tutorial for Klocwork Solo, using her own voice.)

I’m also inspired by Sarah Maddox, who regularly blogs and tweets on tech writing, especially on using Wikis for user documentation, chatting with customers about the tools she documents, blurring the line between documentation and product management.

So, we’re going to expose our soft underbellies. We want to hear from our users directly, rather than the usual generic rants transmitted through our product managers (a recent example: “Need better documentation”). When you rant to us, we’re going to want details. How exactly is the help not helpful? What page made you throw up your hands and curse us? And telling us what works can be just as effective as telling us what doesn’t.

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.