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…

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.

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.

Refactoring is a vital component for software developers, helping to prevent their projects from becoming unusable, and unmaintainable spaghetti code. Equally important to some developers, is the notion of refuctoring…check out this tongue in cheek look at Refactoring vs. Refuctoring. Be sure to check out the slide deck at the end.

Refuctoring describes the process of making your code unmaintainable by anybody but yourself.  I love some of the examples of Refuctoring such as “Pig Latin”, “Treasure Hunt” and my personal favorite “Stating the Bleeding Obvious”:

For example:

//initialize a to 1
int a=1;

Not that I’d ever do that (pause while I go clean up some code). Ahem, right anyways I thought I’d throw out some other refuctorings:

1.    “Catch me if you can” – Use so many goto statements that it will make anyone’s head spin.  Especially when you start adding backward goto’s.  Take a look at the CVS source code,  they have some nice (nasty) examples.

2.    “Giant tar pit of hell” – This is hard to blame one single developer as it really encompasses many developers getting together to create one big cohesive piece of crap.  You know you have a problem when you run out of printer toner trying to print these.

"Giant tar pit of hell"

3.    “WTF” – Using names that no one will know…ever.  If you create a bankaccount object, instead of calling it ‘x’, here’s a wild idea, why not call it ‘bankaccount’.  Let’s face it we are all guilty of this.

Now if you really want to be special (I don’t mean in a good way), try combining #1 and #3:

int afunction()
{

there:
   ...
   if(something)
   {
      goto here;
   }
   if(somethingelse)
   {
      goto there;
   }
here:
   ...
   if(somethingelseagain)
   {
   goto end;
   }
end:
...
return;
}

I have to admit, I’m not winning any awards either. It is certainly time to get on the refactoring bandwagon.

Thought I would take a moment to share with you my experience at this year’s IP ESC show in Grenoble, France. First off, Grenoble is beautiful sitting at the foot of the French Alps. If you get the chance, go!

Back to the show. This is typically the IP Show, but this year is the first that ESC has been added to the agenda. I don’t think it helped attendance-wise. From what I can tell, there are maybe 200-250 attendees in total. I spent the last couple of days sharing booth duty with our friends from Emenda, France. Today, I spoke about how source code analysis fits into Agile development teams. I had about 15 attendees, which by all accounts was a good turnout.

I was able to cram about 40 minutes of material into 20-minute slot, and even had time left over to answer a few questions. Unfortunately, this show did not allow Exhibitors to attend any of the sessions. Too bad really, I was hoping to attend a few of them.

Next week, I am off to a similar show in Stuttgart, Germany, where I will have more time to present. Check back here next week for a recap of that event.

My first day at the SWA forum was actually the 3^rd day at the conference, and from all accounts it has been a very productive and relevant first 2 days. Today was no different as it was kicked off with a panel discussion on the Evolution of Software Assurance Processes, and included speakers from Lockheed Martin, Waters Edge LLC, SEI/CERT, and SafeCode. I thought it was an entertaining discussion from a group definitely passionate about the topic. Something seemed missing though as I came out of it hoping for something more…Some good questions rounded out the first session.

Next was my turn to be on stage. I was speaking as part of the “Understanding Technology Stakeholders: Their Progress and Challenges” panel which was made up of John Giligan (The Giligan Group), Djenana Campara (KDM), Bruce Weimer (US Army), and Sean Barnum (Cigital)…and myself. It was an interesting mix of speakers representing various sectors of the software assurance community including assurance ‘consulting’ stakeholders, assurance ‘standards’ stakeholders, assurance ‘consumer’ stakeholders, and assurance ‘tool’ vendor stakeholders. My basic message was that the DHS Forum had done a great job of communicating their message to the assurance community (including a large number of our customers), but fundamentally flawed in a number of other ways.  Unfortunately, the panel part went long, so the Q&A with the Plenary was shortened. The feedback I received was all positive, and that it was refreshing that we didn’t sugar-coat our thoughts.

As I mentioned earlier, there just seems to be something missing from the sessions I’m attending. Perhaps it is too much talk, and not enough action…not sure yet. Hopefully the next two days will leave me with a more positive feeling on this.

I speak again on Friday when I share my experiences and observations on the Static Analysis Tool Exposition 2009. I guess it will be another ‘refreshing’ session…

The first instalment in my ‘Going Agile’ series will reflect on the earliest days that led up to our development team becoming an Agile development team. Before I get into this too deep, I should first set the stage a little. This organization is a medium sized ($500M in revenue) software company, with no other teams using Agile techniques. We were going to be the first. The product was well established, having been on the market for about 5 years, and traditional development methods were fairly effective from a delivery and quality perspective. The team comprised of about 12 members, which included all developers, testers, documentation, the Scrum Master, and myself as the Product Owner.

The first meeting ever held with the whole team was intended to introduce Agile (Scrum) to them and get their buy in…we did not want to ram it down their throats and say we are doing this. At the time we were doing this, the concept of an Agile Coach was pretty much non-existent, so we were on our own. Our Scrum Master had been on some training, and thought for this meeting it would be good to try an exercise with the team to illustrate how Agile could work. So without any preamble or mention of Agile, everyone in the room was instructed to pick a partner, and then the goal of the exercise was explained. The goal was to navigate your team member around the room as many times as possible in 1 minute. Seemed pretty easy, until we told them about the twist…the team member that was walking around the room was to be blind folded. To add to the fun, our Scrum Master played the role of a roadblock, stepping in front of the blind folded people as they tried to circle the room, requiring new instructions to be shouted out to navigate around him. Once the clock started the chaos broke out, as 6 different people were simultaneously shouting out instructions trying to navigate their team member around the room, and around the roadblock. By the end of the 60 seconds we tallied total trips around the room, and came up with a number in the 30’s.

The 2^nd part of the exercise was quite a bit simpler, and merely had all team members walk around the room (no blind folds), and make their own decisions to navigate around the room and the ‘roadblock’. I’m sure you can imagine how much calmer the room was, and by the end of the 60 seconds we again tallied our results. This time we were well over 120.

So what was the purpose of this exercise, and how did it relate to Agile? Basically it illustrated the power of a self-managing team, and how the productivity of such a team can be magnitudes better when team members are given the ability to make decisions on their own, in real-time. After the exercise, we then introduced the idea of the team adopting Agile, what it is, how it could work, etc. In my opinion, doing this exercise first (and doing it without ever mentioning the term Agile) did more than a week’s worth of powerpoint sessions on why Agile is the way to go. The team was very receptive to the idea (at least most members, more on that in another blog), which set the stage for a series of follow on meetings to further flesh out what was really involved, and what needed to be done to prepare for our first Iteration. The next instalment in this series will delve into that preparation.

After attending Agile 2009 in Chicago, and speaking with so many people about their experiences with Agile, I thought it might be an interesting opportunity for me to do the same. So with that as my inspiration, I’ll be putting together a blog series that will cover a number of topics ranging from introducing Agile to your team, through to the release, with a number of other interesting subjects in between.

The series is in no way an attempt to tell you how to do things, but rather is intended to share experiences that I have had…perhaps you will read them and say to yourself, “I’m glad we’re not the only ones who went through that!”

The series kicks off next week discussing our team’s early days with Agile. This will introduce you to some of the key players in the team, how Agile was introduced internally, the training we went through, and so on. Other topics I have planned for this series include the 1^st Sprint preparation and planning, Retrospectives, team communication, developer issues/concerns, and finally the product Release.

Hopefully these blogs will strike a familiar note with you or give you something new to think about. In the meantime, if you have a particular topic you would like to see discussed, feel free to email me at todd.landry@klocwork.com, or find me on Twitter at http://twitter.com/todd_landry.

Succinctly communicating what Klocwork does and how it helps improve productivity during code reviews, integration builds, and of course for developers is always a challenge. We’ve tried to capture this visually with this simple SDLC image, and of course we always talk about the importance of finding bugs early.

Then somebody else comes along and makes the point in a way you never thought of… here’s a funny that’s been going around for some time, but I figured it’s worth passing along to the Kloctalk readers.

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