In the 1950’s, Solomon Asch, conducted a series of experiments designed to understand the phenomenon we know as conformity. In his experiments, a group of participants were seated around a table and asked to examine a series of vertical lines. They were then asked to tell the group which vertical line, A, B, or C, matched the test line. The vertical line series looked very similar to these:
A question I field frequently is “When should we start and end our iterations?” For a long time, I worked on teams that started our iterations on Monday and ended them two weeks later on Friday. We did our planning meetings on Mondays, and our review, demo and retrospectives on Fridays. But, the more I think about it, the more I’m now inclined to answer that the best iteration start and end dates are midweek.
I would suggest that you start your iterations on Tuesdays or Wednesdays and end them on Wednesdays or Thursdays. The logic behind this is simple. Think about it: Monday morning, folks roll in from the weekend and are kind of groggy. They’re not 100% focused. Is this really the best time to be thinking about planning your next iteration? The planning meeting is the place for robust, intelligent conversations to happen when nailing down the details and tasking a user story. If your team is half asleep, or still getting over the weekend, this is probably not the optimal day for planning. By Tuesday or Wednesday, the team is awake and engaged, ready to think. This is probably closer to optimal for planning sessions.
OK, so if you didn’t guess it, quality software has been on mind a lot over the past two weeks. And why shouldn’t it be? It should be foremost in all of our minds (if you’re in software development). It’s what our customers expect and demand. They don’t want buggy, defect ridden software. Unfortunately, things like software quality and testing are usually seen in a budgetary/cost light instead of the customer satisfaction light. I’ve beaten this point to death already and by now you already know that in my opinion customer satisfaction is paramount. And, anything we could do to improve the quality of our products should be pursued vigorously.
We’ve discussed the CIO commitment to quality already, and we’ve looked at ways to tightly couple QA/testing into our iterations. Today, I started thinking about other places in our development cycle where we could really show great strides in improving software quality. I think I found one: Lets take a look at pair programming. The first thing most people say when I mention pair programming is “Why would we do that? We’ll have two developers doing the same work that one developer can in the same amount of time!”. OK…fallacy number one: This simply isn’t true. Studies have shown that pair programming doesn’t reduce productivity by 50% as implied by the previous statement. In fact, pair programming reduces productivity by only about 15%. WHAT!!!! Yes, I admitted that pair programming reduces productivity. But, the 15% loss in productivity is made up for by gains in reducing defects.
In the past few weeks I’ve been asked about and have been considering exactly how to fit QA and testing into a two week iteration. A primary concern of the folks I’ve been talking with is that QA’s and testers on an agile team have nothing to do at the start of an iteration. The second concern is that we can’t keep writing new code up until the last minute of an iteration if QA is to adequately test the code, and as such, what do the developers do at the end of the iteration. Of course, the underlying concern in both of these cases is keeping the QA’s and the devlopers effectively utilized during an iteration. Software quality always seems to boil down to a utilization/cost equation doesn’t it? Well, after giving it some thought, I think I’ve come with a basic schedule for QA’s and developers over a two week iteration. Here’s the plan:
