Category Archives: Agile/Iterative Development

HDC ’08

Last week was the Heartland Developer Conference in Omaha and, as usual, it did not disappoint.  This was my fourth year attending the conference and I always enjoy the sessions that happen.  Also at the event was a demo Microsoft Surface table that I got to play around with; and the Microsoft booth had Rock Band 2 set up. I was able to get in one quick jam during the conference; thanks to whoever sat in on the drums…

Some of the more interesting sessions I attended this year include:

  • Rod Paddock on “AJAXing Your .NET Applications”: Very good presentation, especially for the more novice AJAX developers, like myself.  The biggest payback was seeing his demo of the Fiddler tool.  Very cool stuff!
  • Dennis Kirlin on “Estimating in the Abstract”: This was one of my favorites.  Dennis’ presentation was unique in that he presented a number of agile concepts and practices without using any of the associated buzzwords. By doing so, the presentation sounded refreshingly new, even to those already familiar with the concepts.
  • Javier Lozano on “The Zen of ASP.NET and MVC”: I attended a presentation with the IADNUG earlier in the year over this same topic, and it’s amazing the number of changes that have occurred between the earlier CTP and the recent beta release of the MVC framework.  I was unimpressed with the former, but Javier’s presentation won me back.  Now if only they could get the thing out of beta…
  • Clint Edminton on “Modeling in Visual Studio Codename Rosario”: This demo was cool until he told us that these features were for the Architect Edition of Visual Studio Team System.  Does Microsoft not think that developers use UML?  At least they now acknowledge that developers do interact with databases.

The other interesting thing to note was the increase in agile-specific topics, including sessions on using Scrum with Team Foundation Server, and the aforementioned Agile Estimating session.  I’m looking forward to what is to come in 2009.

A Coder’s Challenge

I was recently “challenged” by a fellow agile member who claimed that Java developers have a higher maturity level then their fellow .NET developers.  His claim was that .NET developers rely too much on the mouse when programming, which makes them slower because their hands have to leave the keyboard more frequently.  Java developers, on the other hand, are more familiar with their tool (e.g. IDE) and all the keyboard shortcuts that are programmed into it.

So, I considered his claims and his challenge.  I scoured the interwebs, searching for the knowledge I sought that would help me master the .NET coder’s tool of choice (the great Visual Studio), until I found what I was looking for.

And so, for my fellow .NET “adolescents”, I share with you this, straight from our god herself:

You threw down the gauntlet, B.C. and I accept your challenge.

Scott Ambler Presentation

Scott Ambler was in town earlier this week to be a keynote speaker at the local BADD 2008 conference, and I was fortunate enough to attend a separate presentation on Thursday night at the West Des Moines Marriott, where Scott talked to around dozen of IT individuals about strategies for scaling agile development in real-world environments.

Overall, it was a great presentation. Scott has a reputation for speaking his mind about topics, and there was no shortage of that here. However, he is also known for making arguments based on factual material and he shared a number of research data with us around the adoption and success rates of agile (of which some of the data can be found here).

It definitely had a flavor of IBM Rational bias, but a lot of the messages were applicable beyond the scope of IBM and its RUP product to agile practices in general.

Overall, the message was clear: Agile is making (or has already made) its way into the mainstream, and it is going to be around for the long term.

The Definition of “Done”

There is a good post over at the Agile Advice blog regarding Scrum’s definition of “done” and how to customize it to your own team environment.

This is something my team has been struggling with lately. We’ve been implementing a Kanban-like approach to managing our work items. For most of our work items, we have common activities that we need to accomplish, such as:

  • Holding peer design reviews
  • Writing unit tests
  • Filling out PCM requests (gotta love SOX)

However, we don’t keep a list of these activities out in the open which means we sometimes forget – or “forget” – to do a particular task.

By creating a checklist of tasks required to call a work item “done” and posting it in a visible location (like a wall), this helps keep everyone on the team honest and makes sure that no tasks are forgotten.

The Fallacy of Written Communication

I recently stumbled upon a good post that Mike Cohn wrote a a while back on his blog about the problems that often arise from textual communication.

It is especially meaningful how he relates this, from a software development perspective, to requirements documentation and the impact it can have in that respect, as well as the day-to-day e-mail traffic that goes into and out of… mostly into… my Inbox.

I often find myself among the minority of developers who, instead of firing off an e-mail, opts to pick up the phone, or stop over for some face time with my fellow business users, business analysts or project managers. Perhaps that is the weakness of IT: brilliant (usually) at analytical and technical skills, but lackluster in social interaction skills…

Think back on the past week. How often have you opted to write an e-mail to a co-worker instead of pick up the phone or walked 10, 20, (or, god forbid, 50) feet to the person’s desk? Worse yet, how often have you been part of a conversation that took place entirely via e-mail. You know, the kind where a dozen (or more) people are included in the e-mail chain — 18 of which could care less about the discussion?

(I know I’ve brought that issue up once before…)

It is at times like these where I stand up, blow the virtual whistle (loudly) and suggest (strongly) that we schedule some face-time to hash out this discussion in person (or at least via conference call).

Now, think about what agile methodologies and practices propose to combat this issue…

Daily scrum meetings?

On-site / Nearby customers?

Manifestos?

Importance of Business and IT Connecting

Mike Vizdos has a great cartoon / blog entry about the importance of IT understanding the business(es) that they support.

I must say that I was surprised by his take on who my real customers are (or should be). It definitely gave me pause about how I should go about developing solutions for my business users.

If nothing else, the article gets you thinking outside of the norm. How very… agile.