An Agile Coach is a talented professional developer who is brought in to a team to help them raise their bar of excellence. This person is a servant-leader, an advocate, a teacher, a helper, and a technical resource as well.

A coach is there to guide the team, help them to do their best. This should be true of a coach on any team. An Agile Coach is someone who is well versed in the practices of an agile developer - XP, SCRUM, LEAN, etc. They have been around a few blocks and have some experience in various teams in various circumstances.

This person is sought out for their experience and their ability to convey their knowledge in a positive way. They are an active and participating member of the team - not someone on the outside. The Agile Coach should be developing code right along with the rest of the team. Sometimes the coach can be the team's representative to outside meetings also, where a developer is needed rather than a scrum master.

The coach should work directly with the scrum master, and be aligned in being able to protect the team from outside influence, as well as randomizations from meetings and questions from other groups. The Agile Coach should show leadership in how code should be written, and the behavior expected from the development team when it comes to coding both main-line and tests.

The coach should encourage continuous learning and growth, facilitating this wherever and whenever possible. He should encourage the team members strive to improve, while being there to assist and support them while they do, and ensure their success. The coach should set the tone for the team in modeling the attitude that will best serve the client, customers, and users.

COACH: Champion, Observer, Advocate, Cheerleader, Helper

I ordered the new 2GB chip from Crucial (2GB, 204-pin SODIMM Upgrade DDR3) and got it today. around $28 shipped. The machine has only one slot for a single DIMM, so 2GB is the max for this netbook.

I flipped it over and looked on the bottom, to find about 9 screws. Don’t undo them – they are NOT required to be removed to replace the RAM module. Instead, on the bottom of the netbook is a large plastic panel that takes up most of the bottom of the unit. This is the only thing that needs to be removed to swap out the memory. Be sure to remove the battery of course before proceeding.

You will need a sturdy knife and a 1/8” flat blade screwdriver. Begin by prying up the plastic panel (carefully) with the screwdriver near the battery lock slide switch. Then, you will need to use the knife probably to get in under it and pop up the remaining areas, just working your way around the edge.

Note: there are three glued areas where they have put in tabs that connect the electrical shielding on the underside of the plastic plate to grounds on the internals of the system. You will need to break each of the three in order to pry the plastic plate off the back of the unit. They are pretty tough, so be careful you don’t damage the plastic as you pry it loose. There is one in particular that gave me a bit of trouble on the rear of the unit, back by the battery about an inch in from the battery slide switch on the right side of the unit. This was so tough it actually left a dimple in the plastic panel because I had to pry it so hard.

Once the plastic panel is off, just locate the ram module (directly under the FN key on the keyboard) and slide the release catch on the module (on the left side looking at the unit bottom-up) with the screwdriver and it should pop up and out. Replace it with the new 2GB module and snap it into place.

Replace the plastic cover by just pressing it back into place, and you should be good to go. Fire up the unit again and voila! You now have 2GB ram! Nothing else needs to be done on setup, configuration or anything – it will just all work!

Total costs

Costco Netbok: $299.99 +tx

Crucial RAM $28.50 including shipping

It’s a great netbook, but just needs some RAM to make it really work well Enjoy!

Unit tests (and indeed all automated tests) are meant to be a safety net and status indicator for the project. They tell us when we have a problem, or if something is behaving differently than it did before. Sometimes, tests can be written that are inconsistent, erratic, or just downright flakey. I am of the opinion that these kinds of tests are not trustworthy, and as such, should NOT be part of a build.

Sometimes, tests are written with inherent problems that cause them to be unreliable:

• race conditions
• incomplete test data
• relying on external data
• date/time calculations dependent on the current date/time
• many other factors

If any of these kinds of issues are causing the tests to be inconsistent (that is pass and/or fail when run multiple times with no code changes), then these tests can’t be relied upon to give us the safety we require in a test suite. I recommend that teams immediately identify these types of tests and either exclude them or outright fix them so they can be trusted to give the right feedback.

Writing good tests is not just something we’re born with, it takes practice and skill. Skills like these are very important and very much required for developers to be successful. There are a lot of good books that we can read to acquire these skills, here are a few links which may help.

xUnit Test Patterns

http://www.amazon.com/xUnit-Test-Patterns-Refactoring-Code/dp/0131495054/ref=sr_1_1

Agile Testing

http://www.amazon.com/Agile-Testing-Practical-Guide-Testers/dp/0321534468/ref=sr_1_1

Testing Extreme Programming

http://www.amazon.com/Testing-Extreme-Programming-Lisa-Crispin/dp/0321113551/ref=sr_1_6

If a story has some defects logged against its implementation, does this mean it's not done? What does your [DoD] Definition of Done say about this? If a defect is severe or blocking other teams or other testing, then I would agree that the story really isn't done. In that case the team should probably postpone other feature work and focus on fixing the defects. However, if the major business value is still delivered and the main functionality is not adversely affected by a defect, then I would support the story being called Done (all other done criteria being met of course).

The product owner of course will want perfection... this is to be expected. There is a line however, somewhere, that separates a story from done to not done. However "no bugs" is probably not it... minor defects that do not block the major functionality, other teams, or other testing / features should be logged as defect stories on the product backlog, prioritized highest (even above other high-demand features) unless they are so minor that the story could ship to production even with the existing defect uncorrected.

Perfection is not in the Agile Manifesto the last time I checked... however the defect vs. done issue continues to remain a gray area.

The recommendation is this: classify defects based on a priority.

Pri-0 - blocking bug, drop everything and fix NOW.
Pri-1 - non-blocking but serious bug, broken functionality. Fix ASAP.
Pri-2 - non-blocking with work-around. Fix when possible.
Pri-3 - non-blocking minor issue, does not block functional testing. Fix if possible.

I support the in-sprint fixing of Pri-0 and Pri-1 defects, but any else should be deferred to another sprint. DoD should include this as a working agreement, and any reasonable [practical] product owner should approve.

So, what's in your Definition of Done?

Ever try to do Agile for a project or team inside a traditionally waterfall organization? It can be challenging... One aspect I noticed is trying to get from Requirements Documents to user stories. This translation is not an easy one typically. So, how is it done?

The Business usually has a set of things they'd like to see accomplished, and they have someone outline these in a Business Requirements Document. Then, it goes to an analyst so they can figure out the in's and out's of what the Business wants, and how best to specify them for development. Neither analysis is usually complete, and there are almost always holes and gaps that neither team has thought through.

After the BRD is produced and the Functional Spec document is written, some analysts may write Use Cases, an actor-action based description of a specific path that illustrates the functionality desired: "a bank customer uses his card at an ATM to withdraw cash." Use cases usually describe the "happy" path of a transaction, and perhaps some anticipated alternate paths, as part of the same case. The great thing about these use cases is they give a more or less concrete example of how something is envisioned to operate.

Use cases can be converted fairly well to User Stories - if this is something the team is using to scope their work each iteration. A use case typically represents multiple user stories, one for the "happy path" and several alternate paths to specify functionality when something does not go exactly as planned. Each of these paths can usually represent a complete and independent story.

When writing user stories based on requirements, using the use case as a tool to map out actors and actions does help bridge the gap between a requirement and a real story. Most often, the true "requirements" can be actually represented as acceptance criteria for a story. For example, if the user story is "a bank customer can use his card at an ATM to withdraw cash," an acceptance criteria might be that he must enter his 4-digit pin, and that pin must be verified by the central bank before any access to money is given, etc.

If we can get the analyst-role people to think in terms of use case analysis for a requirements doc or functional spec, we can much more easily get to user stories that meet the INVEST model (Independent, Valuable, Estimable, Small, Testable). True INVEST user stories can be tricky to write, unless someone is very experienced in this transition, and use cases are a commonly known mechanism that can help bridge this gap.

Today we used a new "Roundabout" mechanism in our daily stand-up, which is in a conference room. We have our artifacts on the walls, and our focal point for stand-up is our sprint status board with our story cards (large post-it's) and tasks on a progress chart. We use this chart in addition to an electronic mechanism to track the progress through the sprint. We have been just each standing around the table and pointing to the story cards and talking about our progress and status.

Today, (at the suggestion of a team member) we each stood by the chart, moved our tasks and story cards as appropriate, and then all the team moved around to the right walking around the table, so the next person could stand by the chart and talk about their tasks. I think this worked very well, as it kept focus on the team member speaking, and the team member was able to focus completely on the tasks and stories on the wall by physically touching them. It helped keep status focused and short. The movement around the room and around the table gave us a new perspective on the room and the chart, each time someone was speaking. Also, it gave us some physical motion to keep our bodies and minds engaged and present. Stand-up was shorter, and more effective. All the team felt that this was a good new addition to the daily routine, and the team is now wanting to add this movement to our working agreements.

Just moving around a table one team member at a time is a small thing, but it's FREE and seemed to help focus and productivity, so I am going to suggest the mechanism to any scrum team I have the pleasure to be part of in the future. Try it out and see what happens!

As you can guess, am not blogging anymore, am using Facebook and Twitter instead.

Catch me on Facebook at http://www.facebook.com/jboal and Twitter id JEBOAL