As I write this, I’m sitting at the Dallas airport, suffering through a 3 hour delay on my flight to Washington D.C. to present at our 2nd Agile in Action Roadshow with our friends from Electric Cloud, Perforce, and VersionOne. As I have the time, I’ve been reflecting on my time here in Dallas, and the phrase “Everything is big in Texas” is bang on. Before I get to that though, I have to say that I do love Dallas…I’m not totally sure, but I truly believe I’m treated a little more special because of my last name (which I casually mention whenever I get the chance). Nothing like having the same surname as a famous coach from the Dallas Cowboys!

Okay, so why do I think the Everything is big in Texas is accurate. For starters, my big delay is due to a big thunderstorm. My rental car preference is a Compact car, and what do I get? A Yukon…I’m not sure what is bigger, this vehicle, or the Canadian Territory with the same name.

I saw big hair, big hats, big rings, big belt buckles, big omelets, big waffles, and big enchiladas. What I also saw was a big enthusiasm for Agile development. We had a great turnout that was fully engaged from the instant the roadshow began, asking questions wanting to know more, sharing their experiences with others, visiting with the vendors and not leaving until they got the information they needed. I wrote a few weeks ago about Agile adoption and where it currently was, and participating in this event, and speaking with the attendees, it allowed me to gain some additional data points that only strengthened my beliefs on this…Agile is definitely growing, and in all industries. As I said before, I truly believe almost all organizations have some Agile developments teams.

Hopefully the enthusiasm I encountered in Dallas will follow us to Washington D.C. And I’m thinking I may want to introduce myself as Todd Ovechkin…

We try not to plug Klocwork on this blog too much and keep the discussions around general software development issues, topics, and trends (with an obvious bias towards static analysis and software verification since those are our areas of expertise).

So, today I’ll go ahead and break that rule and encourage you to visit our new online resource library that includes videos, webinars, whitepapers, analyst reports, etc. All the assets are organized by category and tagged with their subject/content so everything is easy to find. I encourage you to check it out… here’s an example of the kinds of demos we’ve put up there so people can quick see what our tools are all about.

Part III – Joy is All Around Us

When you think of a social activity, what do you think of? Perhaps a rave? Or maybe a quiet bridge foursome is more your style? Or even a Matrix-style meet-and-greet complete with latex and contortionists? Ahem…

Or maybe you’ve finally let go of this old-world requirement to actually be in the presence of an individual to enjoy a social encounter with them, and instead have embraced the reality of the 21^st century, that society and social interactions no longer require physical presence, and instead surround us every day, at every minute, as long as we (virtually) get out there and find them. Speaking as a long-time online gamer, I have a circle of folks I consider friends, with whom I talk most evenings, with whom I’ve spent quality time learning and beating goal-based activities, yet none of whom I’ve ever met. And whilst their reaction to some family tragedy on my part may result in no more than a weak “dude, that blows…” on some forum or other, in every other aspect of social interplay, they fulfill exactly the same role as those few- and far-between actual, you know, friends that each of us cling to throughout life.

According to a study on the topic conducted earlier this decade, friendship is becoming something of a luxury for the average American adult. Rather than expanding our circle of friends as travel has become more reachable for the masses, we’ve instead decreased that circle from an average of 3 to just above 1. So are we all just becoming obnoxious, introverted, “bah humbug!” Ebenezer Scrooge wannabes? Perhaps, and certainly that’s the trite response to the statistics for people in search of a quick buzzword or appliance to blame.

But perhaps instead of this reflecting a net diminution of our quality of life, we’re simply replacing much of what was considered necessary in previous generations (beer with the boys, poker night, ice fishing trips, whatever floats your boat) with a more constant, more consistent, but at the same time more arms length notion of friendship and social interaction. Though different, it fulfills everything we need in terms of communication and support, but leaves us free to concentrate on our family lives, or personal hobbies, or whatever else makes us happy to be, well, us.

Friendship when we want it, on our terms, and only then.

One potential projection of all of this can be found in the ongoing trending of the social nexus of life, business and relationships towards the online marketplaces that have sprung up around activity-, or focus-based requirements (I referred to this in my first post on this topic, drawing the correlation between Facebook and dating, LinkedIn and prospecting, etc.).

Find a marketplace, find a life (or maybe, a Second Life) – and frankly, is that really any different from the actual bricks-and-mortar reality of the rat-infested, smelly locales of the distant past (minus, you know, the scary crone shouting on the street corner, and the propensity for picking up the Black Death at a moment’s notice…)?

Indeed, my Chief Architect likes to describe an attendee at a recent conference as saying something like, “But what should we do about all these old people who can only e-mail or even worse need to use the phone? I mean, how am I supposed to communicate with somebody who doesn’t have a Facebook account, or doesn’t keep up with Twitter?” Note that this wasn’t a casual conversation over a beer, but rather a key point in a presentation (presumably to a room full of people with the requisite qualifications to be able to laugh affably at such an observation).

Whether we like it or not, whether we can personally deal with our relationships migrating into the ether, that’s where they’re headed, at double-quick time. So are you the guy with a red flag making sure that cars only drive at the same speed as horses, or are you busy building a Formula 1 car in your back yard?

And actually, perhaps more importantly, whether you’re either of these, you’d better believe your staff are busy climbing onboard with everything the new paradigm has to offer, so do you really want to be left playing catch up?

At a recent customer meeting I was surprised to hear that this highly compartmentalized, classified installation was putting a social media strategy in place (they termed it “our space”) to embrace what was happening anyway, and obviously to attempt to contain it within the security mechanisms required by their business. If they can do it, with all the restrictions and fenced-off classified strictures they have to deal with, why can’t we all?

Code review, you say? Social code review, more like. The current means of accomplishing the goal is fundamentally broken and will never scale, just like the requirement to only befriend people you could physically reach out and touch. The paradigm is changing, time to keep up…

And now in a deferential nod to the awesome Douglas Adams, this trilogy of posts on code review as a social activity will be continued in part IV, coming to a blog near you soon.

At the risk of sounding like a co-dependent, in this post I discuss coping mechanisms that a “big picture” technical  writer (say, like my friend Beulah) can use to adjust to working in the granular conditions of an agile environment.

Don’t give up the big picture

Wouldn't it be great to use XPlanner for everything? Just imagine the velocity I could achieve.

When you work on a bunch of stories or tasks, it’s trees, trees, trees everywhere  you look and not a forest to be found.  This means that a nice concise how-to could be a long way off while you document myriad  features.

My advice is to finish the pieces and try to get to the minimalist documentation afterwards. In fact, Shannon Greywalker suggests going back and fixing things up later, but mentions that the business case for this can be a bit weak.  I think it’s worth the effort if you can swing it.

I’ve blogged before about how workflow can be helpful in getting the big picture. If the feature is big enough, workflow is your friend and can really pull you through.

Go for “What’s New” first
For each release, we document the cool new features on a “What’s New” page and “What’s New” is where I like to start.

If you can neither summarize nor explain why people would want to use a new feature, you have no business documenting it. “What’s New” keeps me focused on the whole point of the development work in the first place.

“XPlan” everything
I was a slow adopter of XPlanner, which is the tool our team uses to document development, testing and now, documentation.

Documentation has a separate project in XPlanner where we track our stories. At first, I found it difficult to update XPlanner regularly because some of our work can be difficult to account for.

For example, one our sales engineers is a prodigious reader of documentation who meanders over for his (thrice) daily “found a spelling mistake” or “did we document?” or “why can’t titles be printed on the PDFs generated by the wiki?” questions. All good points, with some requiring immediate action and others requiring medium and long-term planning.

But after reading Getting Things Done, I can really see XPlanner as a great life planning tool. See the screenshot above. For low self-esteem days, I recommend first completing tasks such as “Wake up”, “Shower” and “Eat breakfast” under the Personal Maintenance story.

Targeted procrastination
We’ve gone from blanket procrastination, which was a two-week offset, to carefully picking features that could benefit from a little more “fleshing out” before documentation. I like this approach because we show great planning with our procrastination.

For example, I like to spend bigger chunks of time on one thing, so I may delay documenting a bigger feature in favor of knocking some smaller stuff off the list one week, so I can string together several days in a row for the big stuff. I work better that way.

Ask a lot of questions
My modus operandi is asking as many questions as possible. Be annoying, but in a friendly and charming way. There’s an art to asking good questions, but sometimes it takes a bunch of stupid ones to get there. Dive in.

Just came across this post about the 5 code metrics you need to watch.  I thought it was worth mentioning as I just blogged about this below (including something similar a while back).  These are interesting metrics and more high level, but certainly important.  I like labeling duplicated code as something important.  I think we often forget how much we reuse code and have the same mistakes in many places.

In a previous post, I talked about different types of metrics and how they can apply.  These were mostly focused on a system level and provided insight into system complexity from  release to release or build after build.  Now, let’s take a look at some other metrics and how they can be used effectively with the developers.

There are literally hundreds of metrics you can measure, so what is really important?  That’s a tough question because it depends on your organization.  Perhaps you have some coding standards in place or simply want to measure some basic functionality to help developers improve code quality.

Here are some of the more common metrics I’ve seen used in practice:
•    Lines of code
•    Number of functions/methods
•    Commented code
•    Nested includes
•    Number of compiler directives

Most of the metrics listed above are about maintainability.  The more lines of code you have or the more of functions/methods, the more you have to maintain for an individual file.  If these values are high, then perhaps it deserves a new file or new function.  The opposite end is commented code, where you obviously want more code commented.  Nested includes are a great way to alert the developer that adding a new include has all of a sudden added a long compile tool chain, potentially increasing your compile time and size of your system.  Tracking compiler directives is something, I think, is really useful–especially with platform specific code.  Compiler directives are a great way to give you visibility on how much you are using conditional compilation and hopefully, gives you a good understanding of the scope if a new platform is added.

Thresholds are the way to use any of these metrics.  For example, create a threshold that would throw an error if the number of functions per file is greater than 100.  Or,  first give a warning to developers when the number of functions exceeds 75 per file and then, if it goes over 100 print an error.  But what values should you use?  You can use the standard deviation to figure this out or use coding standard guidelines.  For example, many standards say that a method should not reach over 1000 lines or code, or the maximum level of include nesting should not exceed 8.

If you find that these metrics are not enough, start combining them.  Any good tool worth its  salt will let you customize these core metrics, so you can start creating your own calculations.  One example is using the lines of code metric with the commented code metric to create a calculation on the percent of comments.  We are all guilty of not documenting our code.  Use percentage of comments to make sure everyone knows when they are under the norm,  so if you have less than 10% of your file commented you get an error and less than 20% you get a warning.

Showing developers potential areas of concern will help them to be smarter at what they do and spend more time focusing on what they are good at–innovating.

So awhile back, I was begging for some good statistics on Agile adoption, since at that time, there really wasn’t anything substantial to sink your teeth into. Well, a new report from Forrester came across my desk, and it helped to strengthen what most people believe…that Agile processes have overtaken Waterfall as the development methodology of choice. In this report, which cites information gathered from a Q3 2009 survey of IT professionals, it states that 35% of respondents said that Agile most closely reflected their development process, while waterfall processes came in at 13%. I would even argue that iterative development could possibly be included in the Agile bucket, not because it is full-fledged Agile, but it is a baby-step in Agile’s direction. Perhaps I’m stretching things there…

Secondly, the data supports the fact that people are adopting the aspects of Agile that work for them and there’s no monolithic Agile implementation approach, something that is consistent with the many Agile teams I’ve spoken to over the last 3 ½ years or so. I’d be curious to know how many teams out there are doing , say, Scrum “by the book”…if there is such a thing.

Finally, the other thing that the report hinted at, that I have seen firsthand, is that while most organizations are not completely Agile today, they almost all have some groups that are. I honestly believe that the percentage of organizations that have small pockets of groups doing Agile development is very high…perhaps in the 80s or 90s. I don’t have any hard data on this point, this is more of a gut-feel, but I would be interested to hear from our readers as to what they think.

Spend 80% of your time on One Thing.

As a manager of a small tech writing team in an agile environment (are there any large tech writing teams left out there?), it’s easy to lose myself in how-the-heck-can-we-keep-up-with-myriad-coders-frantically-coding thinking.

So when my manager scheduled a meeting to ask what innovations my team has planned for the next release or two, I thought of a few choice responses, such as “Um… how about documenting the new features in time for release? Is that innovative enough for ya?” and “Innovate THIS.”

Eventually I calmed down, since he’s the boss, and I have a mortgage.

I looked at the presentation I’d given after our last research period, that oh-so-short breathing time between releases. I reviewed the precious feedback we’ve gotten from a few customers and thought hard about it. I felt a bit better when I realized several of the goals we’d set for ourselves were already underway.

I dutifully wrote up a wiki page (because I can’t think without writing) that summarized a bunch of initiatives under each of our themes: process, community, quality, coverage, usability, and media. And I decided whether they’d fit into this release or the next. And I sent it off to my manager before our meeting.

He said OK, but where does all this get us?

He called my list depressing. Death by a thousand cuts.

He told me that to be successful, you need to put 80% of your time or money into one thing.

He suggested creating completely different help for just one tool. Throw out the old stuff and start over.

Once I played devil’s advocate for awhile, I began to see where he was going with this. I suggested a tool that I thought would be a good candidate. So I think we’ve picked our One Thing for this release.

Here’s how I’m thinking about our One Thing so far:

• Make sure everything the user needs to know is accessible from one place.
• Target two very different points of interacting with the help: the getting started phase and the troubleshooting phase.
• Use media that are best suited to the user and the information that needs to be conveyed.
• Make the help interesting, fun and effective. Grab and keep the user’s attention long enough to convey what needs to be understood. Defuse frustration.

And again (annoyingly), my manager is right; it’s much less daunting to try to make one thing better than to try to make everything better.

Now to persuade a few of the developers to star in our walk-through video….

The last entry in my Going Agile series will look at the retrospective meeting.

The retrospective meeting is held at the end of every sprint/iteration, and it is the time to discuss what went well, and what could be improved in the next sprints. Some people will say the Product Owner should be in attendance, and some believe the PO should not. IMHO, the PO is a part of the team, and should be there…and in our case, I was. We weren’t sure how to solicit input from the team, so we decided that everyone should take a few minutes to write down their thoughts, and then the Scrum Master would read them out. This was a good way to eliminate the classic, “I was just going to say the same thing as Bob” response. After all the responses were collected, we realized we had 3 main things to address:

1)      Testing and documentation struggled…they were too heavily back-loaded

2)      Code reviews were determined to be essential but weren’t being factored into estimates, etc.

3)      Our team velocity was nowhere near what we thought it would be

From these things we made a few adjustments for our next sprint (again, these decisions were made by the team as a whole). Our developers stopped working on new stories 2 days before the end of the sprint, and would then focus on testing and documentation. This would help alleviate the avalanche of new functionality that would hit the testing and documentation team on Friday afternoons. Code reviews were added to the definition of ‘Done’ and were factored into to estimates.  For the 3^rd issue,  we found one of the key issues to be that developers just weren’t given dedicated time to code, and as such, could be interrupted at any time for an impromptu meeting, or discussion, etc. We decided to implement a Do Not Disturb mode for the developers, and if they had that DND sign up in their cubicle, or on IM, then they were not to be disturbed.

The retrospective is a crucial part of the continuous improvement process, and time must be dedicated to it. The first few are extremely important since that is when the warts are most obvious, but minor tweeking  may never stop.

I’ve enjoyed sharing my experiences about my first Scrum team, and I hope it may provide some ideas for your team. If you have any Agile/Scrum experiences you would like to share, I’d love to hear about them. Chances are others will stumble across the same problems at some point as well.

As Google Chrome climbs out of obscurity in the browser market and expands into a light-weight but fully functional OS, security seems to have become a top of mind issue over at chromium headquarters.

In the Chromium Blog, Chris Evans of Chrome Security announced a cash for bugs initiative, paying between 500 and 1337 USD depending on the severity for any previously undiscovered flaw.  I am glad to see Google encouraging the community at large to participate in hardening my current browser of choice.  As Chris points out, Mozilla was one of the first to embark on this type of program, but I am happy to see Chrome following suit.  Me and my online transactions appreciate it.

Hmm.  Maybe I should roll-up the sleeves and  invoke the  ”I’m gonna write me a minivan” approach and get the driveway cleared for the armored cash trucks.

But seriously, if you’re interested in helping out and getting a small reward for your efforts, visit the Chromium Security project.