Way back when, when we were learning Agile as a company, we sometimes hesitated to present it as such to our clients. We weren't sure how clients would take it. We took what might call it a "stealth Agile" approach. Over time we got more confident with it and could point to successes as well as a few failures. But we learned from both. From that experience we extracted a few rules of thumb that are good to remember. In this post, I want to share those rules of thumb with you.

Keeping aligned is really important to Agile teams and, according to the Scrum methodology, daily standup meetings are the tool of choice for that. When done effectively, they provide visibility and transparency to all stakeholders. Just as importantly, they help the team catch problems early.

I have always had a special respect for Excel.  I have thought of it as the one of the best pieces of software out there (along with Unix and the TCP/IP stack of the original BSD).  Sometimes, however, it can be a serious pain in the neck, especially when you are trying to work with it programmatically.

Late deliveries are a nightmare—especially if you are ”the face” of the team and you have to explain the reasons for it to either your customer or end users.  In this post I intend to list three reasons why your project might be late and some suggestions to a) fix it and b) avoid the same problems in the future.

Traditional code reviews are not much fun, particularly for the author.  They are very valuable, but can easily devolve into a bashing session.  Using the Charrette Protocol could be a more effective alternative that leaves the author in control and makes it more fun for everyone involved.  The charrette is also more in-line with Agile practices.

The way a website should look and behave in a mobile device is significantly different than how it does on a laptop or desktop display.  We came up with a plug-in for Joomla! to make it easy to instantiate different interfaces depending on the client platform.

It feels like déjà vu all over again.  A team of experienced developers is having trouble meeting its deliverables.  It feels just like the last team that struggled with the same problem.  Even when you’ve instituted Scrum, you’ll have to pay attention to these issues every day.  Here’s a list of common mistakes and how to address them.

Scrum, unit testing, code reviews and automated daily builds practices are not an end—they’re just the means to creating quality products, on time, every time.

Get a bunch of techies together and you can easily start a war of words over any technology.  Each will claim his favorite technology as "the best."  But it is all pointless because they're just tools.

Most of us are used to creating web forms based on a hard-coded database schema and a hand-crafted HTML form that maps directly to this schema.  This works, but the form will always look the same and do the same forever.