PhatBoyG.com

While the MVPs descend upon Seattle for the 2008 MVP Summit, I’m getting ready to head to Seattle for the ALT.NET Open Spaces Conference this coming weekend. Many of the people attending the ALT.NET conference are also MVPs, so there are likely to be some tired folks by the end of this week(end).

Based on the experience I had in Austin at the first ALT.NET conference, my company has agreed to send me to Seattle along with a couple of coworkers. A fellow developer and our agile project manager are going along to share in the experience and join the conversation. As an organization, we’ve seen many improvements since converting to agile development (XP-style) and I’m hoping the conference will help identify some new ways to help us grow and educate the rest of the team.

From a project perspective, Dru Sellers and I are trying to wrap up a 0.1 release of MassTransit in time for the event. We’re hoping to be able to share some of what we’ve done with others who are approaching a distributed application architecture, and even more importantly learn from others with similar experience so that we can improve MassTransit and add some new routing and management features. We’re getting there a couple of days early to have some time to pair up and knock out a few last minute tweaks before calling it good.

I’m looking forward to seeing a lot of the friends I met at the first event, as well as making some new friends. I’m excited to have “Doc” facilitating the event, his coordination of the first event was an inspiration at the start of each gathering (regardless of how many beers were consumed the night before).

As the event unfolds, I’ll be adding pictures to a web gallery for the event. Be sure to check it out (or add a subscription to the feed) if you weren’t able to attend in person. I’m sure there will be plenty of tweets as well, along with an RSS feed overload after every gathering.

I came up with this a month or two ago, but finally decided to share it. While working on Mass Transit, I was joking with Dru Sellers about how nice it was to have really good test coverage when making design changes to some all-new development code. I’ve had very limited opportunity for a completely new projected started purely from unit tests, so I was just impressed at how easy it was to make code changes knowing that a passing set of tests meant all was well in the world.

You see, not all parking lots are paved with quality asphalt, generally flat, and void of any obstructions like islands and lights (see my other hobby). At work, our application is a lot of vintage C++ code, a ton of stored procedures packed to the hilt with domain logic, and nearly zero percent unit test coverage. Since adapting agile development, it is something that has been missing from our process. In our latest iteration, we’ve started using unit tests (with NUnit) to design our interfaces and classes. At the same time, we’re integrating Mass Transit to support the loosely coupled layer of application services (which include object translation, communication with high-latency remote systems, and lazy auditing of transactions). Aside from a few basic web services to support remote client application support tools, this is the first C#/.NET development that is being done as part of the main application.

So back to our story, my first project with really good test coverage exposed me to a lot of new things. From a TDD perspective, I’d read about it, used it to build some basic tests for various classes, and thought I had a pretty decent understanding of it. In this new project, I also learned how to use Rhino.Mocks (which took the test run time from 40-50 seconds down to 1.83 seconds on average), a very powerful tool for making an interface behave as you would expect an implementation of that interface to behave. The use of mocks has really helped me focus on actually writing tests and building a single class at a time. Prior to using mocks I would jump around creating additional classes as I defined new interfaces just to be able to continue writing my unit tests on the original class. By using a mock, I’m able to simulate the behavior of the other class without losing focus.

As my appreciation for TDD grew, I jokingly dropped a slogan into a chat window (using Skype, of course, aren’t you?):

I got a few chuckles, and thought it would make a great t-shirt to wear to tech events like code camps. So I threw together a quick online store so that I could order one for myself. I showed it to a few others (like Joe Ocampo, who suggested the slightly less offensive, yet subtly more suggestive variant) and decided to make it available to anyone that wanted one. So if you like it, grab one for yourself and maybe I’ll see you wearing it at ALT.NET Seattle!

Since early last year, I have been using Resharper to increase my .NET coding productivity. After seeing the product used at a Code Camp, I was intrigued by how it make test driven development so much easier. I started on version 3.0 and JetBrains dropped 3.1 on Christmas Eve so I checked it out over the holiday break.

One of the features that first interested me was the Solution Wide Analysis. I turned it on, looked at the badly drawn green circle in the corner of the Visual Studio 2005 IDE, and went, OK. It took me a bit more time to recognize how this new feature was going to improve my skills yet again.

The first thing I learned was that the blinking light was not the real power behind solution wide analysis. The power was that Resharper was working hard eating up those idle CPU cycles to verify the integrity of my entire solution. It wasn’t until I double clicked and put the window as part of my IDE into practice that I saw the true power (of the force?).

The above image shows the errors in solution window with a clean bill of health, no problems with compilation. The next image shows what it looks like when things get broken:

I slipped the window right under my solution explorer, giving me a constant view of my code status. When refactoring, it makes it easy to see all the affected files at a glance. Very cool. But I do have a couple of nags on this feature:

• I really don’t need a tall bar eating space at the top of the window for a repeat of the red/green indicator — get rid of it
• I would like the option to expand all the nodes in the tree by default instead of only showing the file names

The new solution wide analysis feature is a great red/green indicator to see the impact of code changes. If you haven’t upgraded to 3.1 yet, what are you waiting for? And if you aren’t using Resharper yet, what is holding you back?

Over the past two weeks, my department has been working on our first iteration using agile practices. Yesterday, we wrapped up with a retrospective to go over our progress. We used a fish bowl to keep the conversation centered and focused — a method that once again proved to be useful for controlling a discussion without controlling the discussion.

We setup a whiteboard with columns for the following topics:

Start
Things that we should start doing on the next iteration.

Continue
Things that we should continue to do every iteration.

Stop
Things that we should stop doing.

Debt
Things that we did (or didn’t) do that will contribute to our technical debt.

We started with an introduction to the retrospective, a declaration of our goals, and a quick recap of how the fish bowl works. We also identified a remote advocate — a single person who is responsible for coordinating communication with our remote team members. Our company uses Live Meeting for conferencing, so we explained how to use the seating chart and how to use the Raise Hand feature. The advocate also had their IM client up for any out-of-band questions or issues with the meeting client. Once that was up and running, we opened the discussion.

Some of the topics discussed:

• Start making sure the acceptance criteria are well defined before starting the story.
• Start pairing throughout the development of the engineering tasks and not just at the end for review
• Start keeping an audit trail of initials of people who worked on a story or an engineering task
• Stop putting incomplete stories into the backlog
• Continue the daily stand up meeting format

There were many more, but you can see how the structure worked. In all, we identified around 20 items that we need to either start, stop, or continue.

Once that segment of the meeting was over, we went over some of the methods being used to track things like burn down. Our project manager (whom we have yet to designate with a more appropriate agile title) went over the spreadsheet she uses to track story points, engineering task estimates, and actual hours worked on each task. She then showed some web sites from other groups in the company doing Scrum and how they had organized their Wiki, how they posted pictures of their planning board and burn down chart, and their honorary stuffed ScrumMaster.

We did have a few bumps towards the end of the iteration with our test environment and the number of defects coming back from testing (which is why we want to start pairing earlier). We hope to improve with each iteration (of course) but for our first lap around the track I think we did pretty well!

On Monday, we started our first iteration. We spent the previous two weeks discussing the process, preparing stories, and learning how we can adapt extreme programming (XP) practices into our development process.

We kicked off with iteration planning to identify the engineering tasks associated with the stories in the iteration backlog. We gave estimated in ideal hours for each of the tasks and added them to the story cards. Once the planning was done, people picked up tasks they were going to work on (some were assigned, others volunteered) that day. We made a point to assign a peer to work with the task owner until the task is finished.

Every morning at 9 AM, we have a stand up meeting with the team to go over each member’s progress from the previous day, plans for that day, and any roadblocks that are inhibiting forward momentum. Once each person was done, we got down to business and started work on our tasks. Full-time pairing has been limited so far, only a few have been pairing for the engineering tasks. I’m sure it will take time to adjust to what works best for the members of the team.

For project tracking, we are using a physical planning board with the cards pinned to the board. We tried a number of electronic methods to improve collaboration with our remote team members, but the tools just got in the way of the process. We are going to follow up in our retrospective with the remote teammates to determine how we can improve their involvement in the daily workflow. For now, they are communicating via e-mail and phone with our project manager who is working with me for our daily focus (like a scrum master, but in XP terms that I can’t remember).

One of the initial things we found is that it is really important to mark on the cards WHO is working on the engineering tasks associated with the story. Without this step, members of the team sometimes lost track of what they were doing and ended up working on other things. The ownership of the story once picked up really needs to be communicated well with the team to make sure multiple people don’t end up doing the same work.

I paired with another team member on a forward deployed application that is part of our system. I’m fairly experienced with the program whereas my pair-mate (?) had no experience with it. We managed to complete a couple of stories in the first three days of the iteration, some solid progress in my opinion. We spent a lot of time testing various scenarios to ensure the changes we made didn’t break anything. Once each story was complete, we did the paperwork to integrate our code changes into SVN. Yes, we have paperwork for each change to ensure compliance with SOx.

We had a couple of stories that we found did not have a sufficient level of detail in the acceptance criteria to complete. After working with the stakeholder on the story and acceptance criteria, the estimate changed and we’re trying to determine if there is room enough in this iteration to complete it properly.

Our application has been live for several years, so we have members of the team that handle support for our production systems. Starting this week, defects that are found in production are red-carded and put into the Inbox on the planning wall (we are using red cards for defects). We then take a few minutes to estimate the defect and depending on the size either add it to the iteration or put it into the release backlog for the next iteration. This allows us to quickly get production issues fixed and delivered for system testing by our SQA department.

This week we’ve also been working with product management on stories for large upcoming features that are being added to the product. That has been a very good experience, particularly in how we are building our knowledge of the user behavior that is being requested. I’m even thinking of how we could write a series of how-to documents on using the new system features based on the stories we are writing — I’m sure our documentation team with love that!

So I’m encouraged by our progress so far, but overwhelmed with the pace at which we’ve adapted these new practices. It seems like only a couple of weeks ago I was having meetings with our management team about moving to a more agile development process and here we are today almost midway through our first iteration. Let’s hope we can sustain our pace, keep the backlog full, and finish our first iteration with success.

Since we had our agile fishbowl at work, we’ve moved ahead with adapting agile practices in our development process. For our projects, we’re working on creating user stories to fill our product backlog. I’ve read several threads on writing good user stories and gotten advice from several people on what makes a good user story, but I never realized how hard it is to actually write good user stories.For user stories, we’re using a format that includes:

• The role for the story, is it a user, a specific type of user, or a customer
• The context of the story, describing what the user is doing
• The want of the story, describing how the feature should behave

The clarity of user stories over requirements is both amazing and overwhelming. The amazing part is understanding the intent of the story in the context of the user and how it affects their usage of the system as a whole. The overwhelming part is negotiating with the stakeholder to ensure both the context and the behavior have been properly captured and an adequate number of acceptance criteria have been defined. While this certainly increases the amount of time spent on a particular story, the number of details revealed by the discussion is well worth the effort.Finding Good ExamplesOne of the stumbling blocks I found when learning to write user stories is finding good examples that go beyond the typical “As an account holder, I want to withdraw money from my checking account so I can buy crack.” These textbook examples don’t really provide a significant level of depth, something I deal with when identifying improvements to an existing system. For example, here is a story that could be written:

As a customer, I want to verify the correct billing codes were included on the claim before sending it to the payer to avoid rejections.

This enhancement to an existing claim submission system might include a number of checkpoints where such a verification could be performed. The context really helps clarify this story to ensure it is properly implemented:

When importing claims, the billing codes in the 2100 loop of the 837 file should be compared to a list of known, valid billing codes and claims with invalid codes should held.

This additional context indicates that the billing codes should be checked when importing claims, a process that likely occurs on a daily basis. It is assumed that the user would then take the list of claims containing invalid codes and correct them in the originating system. This assumption, however, is just that as the story doesn’t attempt to describe any behavior of how held claims should be handled.

When a user is modifying a held claim, changes to the billing code elements should cause those elements to be reverified. If the billing codes are changed to valid codes, the claim hold should be removed.

This one gets a bit tricky. While dealing with the verification of billing codes on a claim, what is really being described is a new behavior. In my eyes, this means it is a different story.

As a user, I want to be able to correct the billing codes on a held claim so that I don’t have to re-import the claim for it to be sent to the payer.

Here we are describing the new behavior — the ability to modify the billing codes on the held claim. For this story, the previous context would be more applicable since it is dealing with the user activity of modifying the billing codes on a claim.Stories That Aren’t User StoriesSo what about things that are needed to support the above stories? No, really, that’s a question since I don’t have a really good answer at this point. Do you write a story to import a list of valid billing codes? Or do you write a user story to automatically download and import a list of valid billing codes from the payer every night? Where do those system-level stories go and how are they written? There really isn’t a role associated with the story, so I’m still struggling with that type of story.One such example might be something like:

As an application administrator, I want to be able to import a list of valid billing codes so that I can update the verification tables.

The context of such a story might include:

When an application administrator uploads a file containing billing codes, the existing billing code table should be cleared and the new codes added.

OnwardI didn’t really get into acceptance criteria in this post because that in itself is a series of posts. I will mention that having a deep set of acceptance criteria on a story will make it easier to estimate (size) the story, as well as improve your chance at success in implementing the story.If you as the reader have some good examples of stories that aren’t associated with a particular role, please share them in the comments as I’m really looking for some better examples of how these stories would be written.

Earlier in the week, I posted about an introduction to agile development that I gave at work. Afterwards, I talked to several of those that attended and figured out that I left a lot of things out of the presentation. This was partly due to some inadequate preparation on my part and a pretty narrow time constraint. As a result, I presented a lot of information without a sufficient amount of supporting information. I also failed to provide enough clarity as to how these new methods would integrate with our existing processes.

To address the issue, I scheduled a Fish Bowl to have an open discussion about agile development methods. We arranged the group into an outer perimeter and set up four chairs in the center of the room. I took a chair and two other volunteers joined me and I started the discussion. I opened with some general conversation about the items presented in Monday meeting. The participation from that point forward was wonderful — everyone took a seat in the fish bowl and shared their concerns, asked questions, and proposed solutions.

The end result was a greater understanding by the group of:

• why we are looking at using agile methods in our organization
• how these methods can address some of our problems
• what we expect to achieve by adapting agile processes

Based on my original experience with the Fish Bowl at ALT.NET in Austin compounded by another great experience this week, I highly recommend the format for group discussions in any organization.

In adapting agile methods, the User Story is a key element. David Laribee suggested taking a look at Dan North’s post on What’s In a Story.

An excerpt from the introduction:

Behaviour-driven development is an “outside-in” methodology. It starts at the outside by identifying business outcomes, and then drills down into the feature set that will achieve those outcomes. Each feature is captured as a “story”, which defines the scope of the feature along with its acceptance criteria. This article introduces the BDD approach to defining and identifying stories and their acceptance criteria.

Great stuff!