I have posted the acceptance test code in both Selenium and WatiN on the AgileBUG.com site. This code is a short demo and example of how we can do acceptance testing using both tools. The presentation is a short one on what ATDD is, and why we should do it. It serves as a prelude to the tools demo.

Join us at the Owl and Thistle tonight in person for a pint and some good agile discussions!

The UW Extension for Professional Development and Continuing Education now has a Certificate Program in Agile Development. It's being taught by some guys I used to work with first-hand, so I happen to know they are all pretty good at Agile Development. They are certainly highly qualified, and this certification course is a good opportunity for those folks who may not be as familiar with Agile principles to get some good instruction on how to do it well. Be sure to apply now, as this course is likely to fill fast.

The next Agile Beer Night is on Thursday August 21 2008 5PM to 8PM at the Owl and Thistle Irish Pub and Restaurant at 808 Post Avenue in downtown Seattle.

More information can be found here at the AgileBUG.com web site. There will be a presentation on Automated Acceptance Tests, and UI testing. It's a great opportunity for networking and just having a fun time.

Please tell everyone... track it back... spread the word... oh - and SHOW UP!!!

Carpool if possible. Bus if able. The location is on the corner of Post and Columbia, around the corner from the Mae Phim Thai restaurant, and just below the Fado Irish pub.

The food is good, they have lots of beers and it will be happy hour, so it's $3 burgers, $3 fish and chips, and $2.50 beers and well drinks!

Today's nerd dinner was successful... let's make this event successful also!

Practice agile? Want to? Like to meet some folks who do it well? Then let's get together in Seattle for a pint and discus Agile!

See you there...

I have heard a lot of discussion lately about the use of the "#region" directive in C#. There are various camps (some religious) on this topic, so let me throw in my twopence.

Many developers like to use regions to collapse sections of the code because it makes it easier for them to focus on a particular section. That's nice.

If there is that much code in a single file (which *should* be only ONE class), then there is probably too much code in that class. Class design should be focused on one specific thing. According to good OO principles, classes should be autonomous, and do one specific thing. Classes should be intelligent groupings for functionality relating to a specific, focused purpose. The use of the region to group code bits together in a file is a good indication that there is probably too much code.

Simplicity is a highly desired principle in software development. It's the simplest thing that gets the kudos, not the most complicated. Developers who try to write complex, convoluted code so that they can look good to their peers are really doing the opposite. Added complexity is very costly, in time for other people to understand it, debug it, and maintain it.

Here are some ways to determine some code smells in this area.

• Do methods have more than 25 lines of code? If so they are probably too big - this is a code smell.
• Do classes have more than 12 methods? If so, this may be another code smell. Classes that have lots of methods probably are doing too much. See if they can be broken out into more focused pieces.
• Are there more than 3 constructors? Sometimes a lot of constructors could be a code smell indicating using a class for different things in different places.

Anyone else have any metrics that they use? Please respond with comments below.

These kinds of things should be completely discussed on a team, and woven into working agreements, and coding standards guidelines. Teams that work within these are the most productive because everyone is on the same page and playing by the same set of rules. If your team doesn't have a guideline for these kinds of things, I would encourage you to write one up today and get input from your team.

How to Fix Problems on an Agile team - Examining the Evidence
In this article, I discuss how we can look at the artifacts produced by an agile team, to assess the fundamental health of the team and the business value the team can produce. Then, I offer a means to fix the underlying issues that we discover as symptoms of the problem. Here is one example of a practical approach at looking at some specific assets and artifacts, tracing back to a possible root cause, and an idea on how to fix it.

Artifact                       Cause                                  Fix

Engineering Debt                   Not refactoring design iteratively        Train developers in refactoring
Developers need to understand what it means to refactor a piece of code. It isn't enough to explain what refactoring means without giving some good examples. Many times I have seen what I call "superficial refactoring" where only a few things are touched, so as to minimize changing the code that's already there. I have heard developers say "well, I don't want to touch that code because [it is currently working | I don't have time to fix it | I don't understand how it works]" so, they leave it alone and just add their blob of new code, which now sticks out like a wart. It was not part of the initial design, and now that the initial design is obsolete (in some form), we now have engineering debt in that the design of the old code was not updated to reflect the now new "whole" image including the new functionality. Watch out for superficial refactoring, and if it happens - be sure to train on how to do a complete refactoring. Note: this might cause developers to estimate stories higher, since they will be thinking more of the actual work needed to be done...

Lots of Bugs                           Not enough tests                                 Unit test, use TDD, train developers in testing techniques (use QA to help)
Test Driven Development is a good mechanism for reducing bug count. But, sometimes it is a hard-sell to developers who have been "traditionally" trained. Also, sometimes it is a hard-sell to management who will only see that it is taking longer (at first) to get main line code written. Over a few weeks, lights will come on for developers, and they will begin to see the benefits of testing the code first, and letting the code evolve as a response to the tests. Bugs will be much fewer, because the developers will need to consider more things when they write tests. Having a QA person assist the developers in writing these tests can be very beneficial as well, as they will be able to give guidance in testing appropriate areas of the code such that bugs will not be written into the software in the first place.

Failure to Complete Stories      Stories Too Big / Too vague               Focus on DONE criteria, swarm on stories, better task breakdown in planning
I see not completing stories is a process smell. There are a variety of reasons this might be the case. Perhaps the team does not have enough clarity on what actually needs to be accomplished in the story. This is usually evident if the planning for a story goes very quickly and no/few tasks are broken out. Also if stories are too large ("epic" stories) we should break them out into separate smaller stories that are easier to estimate. Many times during a sprint, I have to add tasks to a story because I hadn't thought enough through the component pieces that needed to be modified until I actually got into the work of the story. Sometimes this is unavoidable, but mostly I consider that I should have spent a bit more time in planning for the story so that I had a better grasp of the work involved. If I get my team to help me work on tasks on a story rather than starting a new story ("swarming"), this can be an effective means to get stories done. This is not always practical, as some stories have tasks that are very interdependent, and it's difficult to get a lot of people to be able to work these effectively. However, if the team has enough discipline, focusing on stories that aren't completed before starting new ones is a great way to have stories finished at the end of the sprint.

Customer Dissatisfaction          Customer is not the Priority                PO focus on customer value, get customer in the room
The customer (or stakeholder) doesn't like what the team produced. It can be a variety of issues that causes this problem. Perhaps the PO didn't get the right idea from the customer. Perhaps the ideas did not get properly communicated to the team. Perhaps the team is more interested in some technology than giving the customer working software... Sometimes relevant stakeholders (Operations or Management, for example) were not involved or represented by the PO adequately. The team needs to make sure they understand what the customer's priorities are, and why. Satisfying the customer also must be the primary focus of the team. This information should be given to the team during planning, by the PO. The team then has the opportunity to ask all the questions they need, to be able to understand the customer's needs fully. The PO and the customer should be accessible by the team during the sprint, so that if there are questions that come up during the work, they can have answers in very short order.

Use these strategies as a starting point for assessing issues. These aren't the only things that can be analyzed, but in my experience I have seen all of these come to light on one team or another. These are only starting points, ideas to get an analysis moving. Please respond with comments if you have some different specific experiences that could help other readers as well.

First off, let's get something out in the open. As an agile software developer, I have a couple of strongly held beliefs.

Design isn't optional.
Architecture isn't optional.

DTSTTCPW doesn't mean "no up-front design, we'll just wing it." [That's DO THE SIMPLEST THING THAT COULD POSSIBLY WORK for all y'all who don't speak acronym.]

When we fail to refactor our new code into the existing code, we get odd bits of functionality that stick out from the existing design like warts on a bowling ball. The idea behind refactoring is that we intend to make sure that we *always* have a round ball. Refactor doesn't mean just change a signature or two. Sometimes it means we need to go back to the design white board and figure out what we need to have *now* given the current functionality requirements. We almost always need to change the existing code's design and integrate the new code so that all appears cohesive, each and every time we write new code. Iterative development doesn't intend that we make a bunch of atomic changes and just glue them together.

Code design at each check-in should be able to withstand scrutiny of any outside reviewer, and the design should be up to engineering standards. We still call it software *engineering* not software *art*. Many teams I see are missing this point completely and are producing code that should have been re-designed rather than just having new code glued on. With each check-in we should be able to look over our classes and functionality and say, "yes, this is something that would withstand the scrutiny of a code reviewer not on my team, without excuses or explanation." If I have to couch it and say "well, we will be fixing that in the next release" or "we'll revise that in a later check-in" this is technical debt, and therefore a process smell. Developers that are stuck in this rut need to be re-trained that they aren't "done" with the code until it is production-quality.

If there are warts on your software, this is a very loud process smell, and it should be addressed directly. Make sure that the team understands that this is not an acceptable way to work on an agile team. Re-design in refactoring and adding new code should be common, and discussed among the team after the stand-up meeting daily. "Yesterday I re-factored and re-engineered the Widget classes, so that they now have the new functionality we need in story XXX and are more streamlined to what we are delivering this sprint. Today I plan to have a half-hour review with the team so everyone is on the same page with the re-design. Then I will incorporate all the feedback, get the final code reviewed and coordinate the check-in with the rest of the team to make sure I don't block anyone. I'll make the appointment for the review with everyone after the stand-up."

Make sure that everyone understands that the code as a whole should be well-designed at each commit point, and that this isn't optional. It needs to be expected behavior on the team. This also means that estimation of effort may (and should) go up, for complexity on tasks in both story points and hours. We don't look at revising design as "additional work" just like we don't view unit tests as "additional work." These things are both fundamental parts of the iterative process. Without adhering to these principles, iterative development just won't work, and we might as well go back to waterfall.

If your team has the process smell of needing to budget additional work for refactoring the design, perhaps it's time to go to the team and discuss what Agile software development really means, and that it doesn't mean lower-engineering quality software.

What's your team's truck count? No, not how many SUV's do your people drive... Truck Count refers to how many key team members would need to be hit by a truck before your project fails. Not a very nice thought, but it gets the point across. It means, if a key team member leaves your team (and presumably the company) how would this adversely affect the project? Lower numbers are BAD.

About the best you can do is one less than the team size. The worst you can do is "1." Think about your project, and think about who is keeping the brain-share of knowledge. Are they passing it around the team, or does the knowledge sit under one person's cap? If so, that person makes your truck count lower and your project riskier.

Team knowledge sharing is a fine idea, but it's not always easily accomplished. We use tools discussed below for information sharing and actual knowledge transfer.

Tools
    First of all, let me just start out with: EMAIL IS NOT A TOOL FOR TEAM KNOWLEDGE TRANSFER. "Well, I sent you an email about that last week..." it's just not an effective mechanism. Don't be tempted to use it. Email should be for temporary and archival type information communicaton - NOT knowledge transfer. Here are some things that DO work.

• Wiki
• A Wiki is a good tool for a central information repository, allowing team members to add and update information easily and frequently. There are many wiki tools available, but mediaWiki currently is the leader. The ideal wiki site would allow team members to use it without having to "log in" as this is a barrier to getting the information into the site. Even more ideal would be the ability to have remote access to the site from home (with the proper security of course).
• Online team services like Rally, Scrumworks, and others
• Online team service sites allow individuals to have access to the stories, backlog, burndown, and other communication tools from anywhere. This removes a hurdle to information sharing by not requiring physical access or the hassle of having to fire up a VPN client.
  
• Pair programming, and promiscuous pairing
• Pair programming is probably the most effective way for knowledge sharing and information transfer in a team. Pair programming is an XP concept, but unlike Scrum, tenets of XP can be adopted individually on a team, rather than buying the whole program. Each tenet ads value on its own, even if others aren't adopted. Concepts like test-driven development, continuous integration, shared workspace are all good tools for development, but each ads its own value, and all are good for increasing truck count.
• Arlo Belshee calls it "promiscuous pairing" when a team doing pair programming switches pairing partners regularly, and frequently. He advocates pairing different team members together rather than the same set day after day. I have experimented with this on a highly performing team, and with the size of the team at 5 and the dynamic there, we decided that half-days were a good mix. After lunch we would switch pair partners, and information flow among the team increased without a large adverse affect on performance.
  
• Shared workspace
• Simply co-locating team members is a fine way for information sharing to occur organically. Just simply removing cubicle walls allows sounds and communication to flow freely. Removing physical barriers is an effective way to increase information flow and increase truck count.
  
• TDD game
• The pairing game is where one person writes a test, then the other person writes the code. Then, they switch. This is a very effective way to have both parties fully engaged.
  
• Code Review
• Reviewing code from other team members is a marginally effective way to get information spread across the team. I am not a big fan of code reviews, but I recognize that they are a necessary evil for those teams not actually doing pair programming. The review must be willing to put aside distractions and interruptions to concentrate on not only what changed, but also the whole of the code - making sure to understand it and verifying that it's doing the right thing.

These are just some of the things I have used for information sharing and helped my teams in distributing the brain share for a project. There are probably others as well, feel free to collaborate by adding your comments below.

Our scrum master on the team I am working with has advocated a mid-sprint checkpoint meeting, to see how things are going, and take a progress pulse. I said this sounded a bit like  to me, but that didn't go over very well. I left it at that, but was just thinking about it some more. Why would we need a mid-sprint checkpoint meeting? The burn down chart clearly shows our progress on the sprint, trend lines are good, and everyone is reporting progress and no impediments in stand-up every day. Another meeting? Sounds counter-productive to me, just to see where we are - when we should all know where we are. There are now even have a couple new wide screen monitors displaying 4 rotating web pages, used as information radiators for the team. Everything seems to be good, and going by the book for scrum, so just little things like this that remind me of my Microsoft days cause me to take pause and say hmmm.....

Perhaps a 3 week sprint is too long if we need a mid-sprint review. See the prior article for more information on sprint lengths...