Kane Mar wrote recently about the difficulty teams have adjusting to finishing within an iteration:

Typically what this means is that the software will be code complete at the end of an iteration, but will not have been fully tested.

A comment that was frequently heard during the early retrospectives was that code was delivered late to the testers; usually just a day or two before the end of the iteration.

Over a year into our official Agile (PM/Excecutive sponsored) rollout this has continued to be our biggest common struggle. Keeping our QA staff busy on Agile projects often involves writing a few test cases up front and then slamming in the testing in the last 3-4 days of a 30 day Sprint.

The current mitigating ideas are:

• Actually use an acceptance test tool like Fitnesse to give testers work to do defining and writing acceptance tests.
• Break up functional deliveries to smaller pieces of functionality.
• Just do the testing for the last Sprint in the current Sprint.
• Writing GUI based regression tests on the past Sprint’s functionality.

We’re just rolling out Fitnesse on one project now so that strategy remains to be tested.

On the idea of delivering smaller pieces of functionality, we keep running into two roadblocks. One, is that on many projects we’re splitting development between web based OO software and legacy mainframe development. On the mainframe side they have been pretty consistent in sticking to a delivery in line with the end of the Sprint. So far no progress in getting that habit to change. Second, developers see a nice time box of 30 days and they want to fill it up with coding, not figure out how to deliver small bits of functionality that can be tested individually. We’re getting better at this, but often the argument is well I want to finish all of some module before I turn it over to QA and on the QA side they don’t want to ‘retest’. This has been getting better with practice though.

Kicking testing over to the next Sprint is pretty much an admission of defeat, but on one particular Agile project which involves a lot of parallel mainframe development the argument just comes up each Sprint that we should just throw in the towel and test the last Sprint’s code in the current Sprint. The dangers of this are numerous and we haven’t done it yet, but it’s a common refrain in retrospectives.

Finally, we have the idea of keeping QA utilized during the Sprint better by having them write automated regression tests. This is probably one of the better ideas, but we haven’t been able to implement it all that widely. The other issue is if the GUI is going to change significantly with new functionality the QA group often argues that they don’t want to write a lot of tests they’ll have to scrap and rewrite.

No clear best solution yet, but it is an area we’ve really struggled with.

This week I have 3 standups a day:

• 9:15am Scrum Master on a Proof of Concept project.
• 9:30am Chicken on an internal project.
• 9:45am Chicken on a large systems project in another building.

The disadvantage is I’m running around a lot. The advantage is I get a view into every project on my team every day.

I hadn’t quite grokked symbols in ruby for some reason. Somehow the definition from the PickAxe book wasn’t quite clear enough:

A Ruby symbol is an identifier corresponding to a string of characters, often a name.

OK, I can see that but what’s the point. Then playing around on Why’s 15 minute browser intro to ruby on the ruby language site I came across this definition:

When you place a colon in front of a simple word, you get a symbol. Symbols are cheaper than strings (in terms of computer memory.) If you use a word over and over in your program, use a symbol. Rather than having thousands of copies of that word in memory, the computer will store the symbol only once.

I like Why’s explanation of the why to use a symbol.

Simon Baker posted some pictures of his tracking white board. He actually has a velocity column on the far right end that occurs to me is a really good idea. Puts a visible focus on how much your actually able to accomplish for the Sprint instead of just the remaining hours for tasks.

Yesterday I got to hear two experience reports on our Agile/Scrum pilot projects from two peer managers who aren’t exactly strong proponents of Agile. I assume this is happening more places now that Agile is moving beyond the early adopters. Anway onto the experience reports. From a web development manager:

• The idea of less useless documentation was really appealing, and he found it to work well in practice.
• Collocation worked really well as the team all gained a sense of camaraderie.
• Refactoring can get out of control. On this project they went from iBATIS to Hibernate to SDO to Hibernate in the course of three Sprints. Partially this was because they got bad advice from some consultants on using SDO for all projects.
• It seemed like even though it was an Agile project you still ended up with a lot of slack. Developers would have to wait at times for business requirements. QA would be waiting for things to test as the developers were coding. (We haven’t used something like Fitnesse for acceptence testing yet, and we’re still adopting from very siloed team roles.)
• As a resource manager sometimes it’s hard to juggle your resources when some of them are on an Agile project.

From a mainframe manager: (Yes, we are crazy enough to try something like Scrum on a traditional mainframe project.)

• Starting off he admitted he is heavily biased against all methodologies Agile or not because he doesn’t believe they work. He came out into the workplace when James Martin was selling his Information Engineering Methodology as the way to do perfect projects.
• His developers hated collocation at first since they didn’t want to move out of their cubes. Within a few weeks though they all agreed that collocation had worked really well and they actually really liked it.
• From the manager’s perspective since the product owners are more involved they’re not constantly dropping into his office to talk over things which has been a relief.
• He hates the 30 day iterations. He thought that iterations should just be planned around how long it took to completely code something. Say a three week iteration followed by a two week iteration and then a five week iteration to deliver a project. (Sort of blows the rhythm idea out of the water, but could work in something like Crystal if everyone agreed to the try the flucuating iteration lengths.)