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.