As an agile developer, I think it's fair to say that there is a bit of pressure to deliver software on a regular basis. In order to do that effectively, I need to be able to produce readable code that my team members can understand, and vice versa.

Every org I've been a part of has its own quirks about what it will allow for coding standards. The worst is when there are no standards, or they aren't "enforced." Lots of shops have these cowboy coders that love to do things their own way. It doesn't matter to them that the whole team is going to have to read, understand, and potentially update the code they are writing. The concept of "collective code ownership" is lost on these folks.

What can we do to reign in these cowboys? I proposed a coding standards guideline. It specifies in some detail how code should be written and formatted. It specifies the style, structure, and conventions. I recommended that code follow these guidelines specifically, unless there was a "really good reason" why not. "Really good" reasons did NOT include the phrase "I just didn't like it" or "I have just always done it this way." Being set in ones ways is one thing but being a professional and being part of a team is another.

Does anyone have a practical solution to this issue? If so, I'd love to hear about it... please feel free to post a comment.

How do you handle bugs? There are many ways organizations handle bugs in software. I have what I think is a very workable approach, see if you agree.

The environment: The team is a dozen software developers and testers (total) and the project is run as a Scrum project. Iterations are 3 weeks.

Scenario 1:
QA is testing the build, and there is a bug discovered. The date/time field data that's entered in local time is stored in UTC, but the data comes back as UTC (not local) when retrieved.

1. QA logs a bug. Priority 2 Severity 2
2. Bug is assigned to the Product Owner for the team.
3. PO looks at the bug, and makes the call that the currently signed-off stories are more important than this bug.
4. The bug is estimated in story points by the team as 2 points.
   
5. The bug is put on the product backlog, prioritized along with the other bugs and stories.
6. The team can't "ship" the sprint's release with this bug outstanding, but the PO knows that they aren't planning a release for another two sprints anyway.

Scenario 2:
QA is testing the build and discovers that if a name is entered that is longer than 50 characters, the site crashes with an unhandled exception.

1. QA logs a bug, Priority 1 Severity 1
2. Bug is assigned to the Product Owner for the team.
3. PO knows that this bug is serious enough to warrant being fixed right away.
4. PO meets with the team, and the bug is estimated at 5 story points.
5. The team's velocity last sprint was 80, and they have committed to 78 points for this sprint. The team left only 2 points "spare" and didn't allocate time for bug fixes.
   
6. PO suggests that the bug be fixed this sprint, but the team does not feel they will have time enough to do that along with the other stories.
7. PO removes the lowest priority story from the sprint backlog, and replaces it with the bug instead.
8. The story goes back on the product backlog as the top story in priority.

There are also other permutations that may work in different organizations:

1. Abort the sprint, and replan a new sprint including the bug fix.
2. Allocate some time and time-box it just like a spike. The team may not be interested in working overtime, but try to negotiate it anyway. Most teams will want to fix bugs like this even if it means they work a few extra hours. Buy pizza.

The current team I am on doesn't follow these guidelines, and they insist that every single bug be fixed for every sprint, or the story can't be accepted as done. While I think this is a lofty goal, in my experience it just isn't practical. Maybe it's my old school days at Microsoft where "done" meant it was "code complete" but not "bug free." I think that Scrum gives us the ability to continue the current sprint and continue to develop the features as committed, and delay bug fixes until the next sprint. The only time when this doesn't work is the case where this sprint's story delivery is scheduled to be the release. And even in that case, most organizations allow a small window for last-minute fixes which could be used to take care of the bug.

If the developers are doing TDD, they won't be writing bugs in the first place... I see more than a handful of bugs per sprint at a clear process smell. In that case, the process should be evaluated to see why the bugs are being created in the first place. Is it unclear story descriptions? or more likely, is it a lack of testing in the functional, integration, and acceptance areas? Any way it goes, bugs seem to be a symptom, not the actual problem. Every bug I have written myself was due to a lack of a test for that area. Find a bug, write a test! Please make sure that your developers realize that when they estimate fixing bugs, that it should always include writing tests that first fail when the bug is present, then pass when the bug is corrected. Bugs should not be able to be resolved without at least a unit test to illustrate that they are really fixed.

Handling bugs can complicate a project manager's life, so if they are cropping up, be sure to address the root cause, and all will be happier.

OK, so this one isn't about agile. But, it's such an annoying pain point I thought I would share. And, I couldn't find much info on this error message out there in the ether.

Visual studio complains every time the solution is opened: "... discrepancy between the solution's source control information ..."

When using Team Foundation server for source control (also the same issue with VSS I presume), someone on my project decided it would be better to use the source control server's IP address in the project SccAuxPath entry, instead of the server's name. They may have been experiencing DNS issues, or something like that. I recommended to the team that if this were the case, and DNS was not dependable, to put the IP and the server name in their c:\WINDOWS\system32\drivers\etc\hosts table. This "discrepancy" confuses the poor little source control system, and it senses that there is a difference between the server's name (to which it has a TCP connection already) and the target destination specified in the project.

So, it checks out the file, expecting that it will have to change something. Then, it is able to connect using the IP, and everything's fine. Except, the files are left checked out with no changes.

 

Here is the fix:

 

simply change

    <SccAuxPath>http://10.10.10.10:8080</SccAuxPath>

to

    <SccAuxPath>http://TFSSERVER:8080</SccAuxPath>

and problem is solved.

 

Just remember that TFS is relatively easy to confuse... Now, just go ahead and retire TFS and use Subversion like the rest of us

scrumbut [skruhmbut] noun.
1. A person engaged in only partially Agile project management or development methodologies
2. One who engages in either semi-agile or quasi-waterfall development methodologies.
3. One who adopts only SOME tenents of the SCRUM methodology.
4. In general, one who uses the word "but" when answering the question "Do you do SCRUM?"


You wouldn't want your surgeon to follow just *SOME* of the steps in that procedure you're getting, would you?

SCRUM works great, if you can just follow the (whole) program. It's not surprising how many organizations say they have failed using SCRUM, when they have only picked and choosen a few of the aspects to implement.
For those of you who need a 12-step program... and you know who you are...


1. Use a 2-week or 4-week sprint. 2-week preferred
2. Appoint a scrummaster who will hold the team accountable, AND also keep the wolves at bay.
3. Make sure the entire team is jointly accountable for the success of the project.
4. Have a prioritized product backlog ready before the sprint. This can include both bugs and features
5. Have a REAL planning meeting where the team commits to stories and they are thoughtfully tasked out and estimated.
6. Team members commit to stories, and then break them down into tiny pieces (tasks). If any estimates are over 4 hours, break them down further.
7. Do a daily stand-up. What did you do, what are you going to do, and what's blocking.
8. Don't do anything that's not estimated and in the sprint backlog.
9. Establish, post, and meet DONE criteria. It's only real if it's posted and visible to everyone.
10. Post a sprint backlog task burn-down chart and update it daily.
11. Keep the product owner in the loop at all times.
12. Hold a stakeholder review a the end of the sprint - this is the fun part!
(13) Then, have a retrospective meeting to discus what went well, what could use improvement, and action items.

That's SCRUM!
Now, you'll never have to be a SCRUMBUT again!

Once upon a time, there was an Agile team that was working on stories in a sprint. The team was going on fine, until the product owner decided it was time for him to go on a month long vacation (and then leave the company).

Life Goes On
So, being a good scrum master, the SM appoints a new PO to make decisions on the specifics of the stories that were already in progress (and some finished). The new PO was a pretty sharp fellow, but he didn't have any background for the feature, so he was a might confused. But, the team had fairly good direction on the feature, so they persevered and completed the tasks as they understood them.

The Shadows
Now then, from lurking in the dark shadows, there emerged the original PO's Boss. The Boss of course looks at the feature nearly complete, and decides that there were a couple minor tweaks here or there - hey, he's the boss - he can do that. No worries, the changes were slight, and easy. Done deal. All the stories were completed, as well as the automated acceptance tests that verified the now-completed tweaks, as well as the remaining story criteria. All the words had been blessed by the Documentation folk, the UI had been blessed by the User Experience folk (this was the Second iteration of the UI design also BTW).

Demo Day
At the end of the sprint, we all get together with the interested stakeholders in a room, and review the stories, the functionality that was delivered. The managers, the development director, the project team, scrum master, and QA were all represented. Keep in mind now, that everyone has actually seen the feature at least once... "We can't have it do that..." says the boss. Well, apparently a modal dialog with OK and Cancel doesn't work the same in Boss-World as it does everywhere else. So, he fires up his argumentation engine and proceeds to corner the entire meeting with a redesign of not only the UI but also the functionality of a standard modal dialog. Nothing was up to par for the Boss, and - remember - he had seen it all demonstrated for him before...

The Outcome
None of the stories in the sprint were accepted. Sprint velocity: ZERO points. Bad day. Alcohol was required.

The Moral
The moral of this story is this: Have a Product Owner who knows what the feature does. Make sure the product owner has input from ALL the stakeholders - oh yes - in a TIMELY manner as well. Make sure your scrum master has the ability to keep lurking skeletons at bay. They can have their say in the next sprint. But at the end of the planning meeting, the stories should be pretty much fixed and everyone should understand the acceptance criteria for them. Stories shouldn't just have arbitrary criteria appended, grafted, attached, pasted, or otherwise affixed to them after the planning meeting, even by skulking lurkers.

We all know what design patterns are in software design and development. These kinds of patterns also are recognized in unit and other kinds of tests as well.

While it is not necessarily a new idea, it is a good idea. Here are some links I have found on the subject. Further research should yield a whitepaper soon, if I ever get time to write it.

Brian Marick's testing.com: http://www.testing.com/test-patterns/patterns/

A great example at CodeProject: http://www.codeproject.com/KB/architecture/autp5.aspx

RBSC: http://www.rbsc.com/pages/TestPatternList.htm

TypeMock Unit test patterns for .net: http://www.typemock.com/Docs/TestPatterns.html

Book: xUnit Test Patterns: Refactoring Test Code