Every so often I’ll run  into a product owner, project manager or other stakeholder who thinks that “agile” is the best thing since sliced bread. But it’s not really for the reasons you’d consider healthy. “We can change what we want at any time, because we’re being Agile!” they say. Read more

Some ideas that seem perfectly sensible are really disasters waiting to happen, and agile teams are not immune. I’ve started to notice some frequent mistakes that inexperienced, and sometimes not so inexperienced, teams make when they’re trying to be agile. These things seem like perfectly good, common sense ideas, but they have undesirable consequences, and we’re going to see what those consequences are.

Sometimes teams get too enthusiastic, and while enthusiasm is a good thing, it can get out of hand. The temptation to add additional bells and whistles to a story in the sprint backlog can be a temptation that’s hard to resist, but resist we should. Why, you ask? Read more

Some ideas that seem perfectly sensible are really disasters waiting to happen, and agile teams are not immune. I’ve started to notice some frequent mistakes that inexperienced, and sometimes not so inexperienced, teams make when they’re trying to be agile. These things seem like perfectly good, common sense ideas, but they have undesirable consequences, and we’re going to see what those consequences are.

It’s surprising to me that making the sprint longer is such a temptation to a project, but it is. There are lots of reasons that people give for wanting longer sprints, usually it boils down to “we can’t get our work done in two weeks, but if we had three, we could get it finished.”  When questioned about why two weeks isn’t enough, testing seems to be a common sticking point. “We got all the development done, but couldn’t get it tested in time.” Read more

I’ve gotten into several discussions in the last few months with various people who work at my current client, and a surprising number of them think that continuous integration is a tool. The conversation usually starts when someone says something like “We’d like to be doing continuous integration, but we can’t get the server set up correctly.” It’s a this point that I have to chime in and let them know they don’t understand continuous integration. Read more

Some ideas that seem perfectly sensible are really disasters waiting to happen, and agile teams are not immune. I’ve started to notice some frequent mistakes that inexperienced, and sometimes not so inexperienced, teams make when they’re trying to be agile. These things seem like perfectly good, common sense ideas, but they have undesirable consequences, and we’re going to see what those consequences are.

We’re going to talk today about the product backlog. For those unfamiliar, the backlog is the list of functions or features that the product owner or business want in the eventual product. On a Scrum project, these are usually user stories, a sentence in what I call “Cohn Normal Form” is:

I as type of user, want to perform some function so I can receive some benefit.

For instance: “I, as a customer of the bank, want to withdraw money from the ATM, so I can buy a cup of coffee.”

Read more

Some time ago, I posted an article on how to enable dependency injection with a Spring and Struts application.  In the meantime, I’ve come across an inefficiency in that article, and wanted to update my loyal readers (both of you

In the previous article, I mentioned that you create Spring beans for each of your actions in the Struts-Config.xml file. Two such beans could look like this:

<bean name=”/login” class=”com.adeptechllc.myapp.view.action.LoginAction”/>

<bean name=”/logout” class=”com.adeptechllc.myapp.view.action.LoginAction”/>

and beans such as this would work fine, except for a subtle point: because we’ve listed two different beans, but the same class, we’d actually get two instances of the LoginAction created.  Since typically we want only a single instance of our actions, this could cause unexpected and difficult to diagnose problems later.

In order to only create a single instance of the LoginAction class, you can use an alias in Spring.  I’ve started creating a single bean for each action, the aliasing the Struts actions to that single instance,  like this:

<bean id=”LoginAction” class=”com.adeptechllc.myapp.view.action.LoginAction”/>

<alias alias=”/login” name=”LoginAction”/>

<alias alias=”/logout” name=”LoginAction”/>

You can also simply provide more than one name or ID directly in the first bean definition, but if you have a lot of URLs directed at a single action handler, I find this easier to manage.

I’ve recently been working on a project that is making a very determined try to use Test Driven Development (TDD). For those who are unfamiliar with the practice, rather than writing your unit tests after you write your code, you write the tests first.  I’ve known about the practice for years, but this is the first time I’ve worked on a team that’s really doing it, and I’m no less puzzled than I used to be. Well, we should probably talk about first things first. Read more

One of my project teams was having a sprint planning meeting earlier this week. They were having a consulting expert working with them this sprint to develop a web service for their use.

“Have you worked with user stories before?” the project manager asked. “We’ll need you to give us a story point estimate for the work you’re going to do for us.”

I chimed in at this point. “Remember, story points are relative estimates of complexity. If our colleagues here are only doing one story for the project, then their story point estimate can’t really be relative to anything else they’re doing for us: they’re not doing anything else.”

This points out one of the things that I think is so tricky about agile projects. If you forget why you’re doing something, or worse yet if you don’t understand why you’re doing something, then you’re likely to do it at the wrong time.  In this case, the project manager did know why we estimated story points for stories, but he’d forgotten the why, and was operating a bit on auto-pilot: the team needed to provide story point estimates for their work, and he’d momentarily lost track of why.

Agile’s lots of common sense things like this, but if you forget what your goal is, and fall back on patterns of behavior, you can do the wrong thing.

Last week, I posted about our recent success at getting DBUnit working with an in-memory HSQLDB database,  which allows us to more thoroughly test data access objects (DAOs). Further work with that solution has unearthed some rather frustrating problems unfortunately. Read more

Unit testing software tends to break down at the boundaries of a system.  It’s difficult to test the graphical user interfaces (although with some of the new technologies like Selenium, testing browser-based GUIs is easier…) and the database access. I’ll save the UI for another time, today’s topic is the database access.

[Update - Read Some unfortunate behavior in DBUnit for important gotchas in this approach]
Read more