What is "The Forge, By Pillar"?

If you weren't at Agile and Beyond 2012, you may have missed the announcement by Pillar Technology (my employer) that we will be leasing a large space in Ann Arbor's Tech Brewery, a 1850's era building that started life as a brewery and is now a tech startup community with over 30 member companies. The space, and the activities there will be known as "The Forge, By Pillar".

My understanding of this new sub-brand its that it will a place where Pillar can:

• bring client teams to to a space "away from home" to help them create software in ways radically different than what they are used to, while we provide coaching on principles and practices of Agile, Lean, Speed to Value, and others
• bring clients to show them the exciting way our teams create software to generate business value and, if clients desire, quickly assemble team a of skilled software development practitioners to rapidly build valuable software for them
• offer training courses on topics like: Writing User Stories, TDD, BDD/ATDD, enterprise transformation
• host user groups, CodeRetreats, coding dojos, givecamps, etc

I've found that people often want to start writing software differently but feel held back by various forms of inertia in their company. I imagine The Forge being a place where people can come, individually or as part of a company team, for an afternoon visit, a training course or workshop, or for weeks of on-site coaching and development.

Please join us for an open house on May 17th (note the updated date:) Thursday, June 21from 6-9 pm at Tech Brewery and see for yourself what The Forge is about! (map)

Pair Programming Harmful? Says who?

There's been a lot of attention on Twitter to an article by Jon Evans at TechCrunch that takes a fairly broad attack on the agile practice of pair programming, only to advise readers to use their best judgement about it. I find the piece to be a sensationalist attack on a practice that the author doesn't seem to understand. He cites the ineffectiveness* of "brainstorming", which pairing is nothing like; and the dangers of allowing people to hide and let others do the work, which good pairing actually mitigates. Even if you grant his, in my estimation, weakly-supported hypothesis that it harms superstars, it completely misses the accelerated learning and distribution of knowledge that pairing affords agile developers and newbies. The article also misses the natural instinct that we developers have to work on what we find fun and interesting, even if it's not trying to solve the business problem at hand - how many times have you seen a cowboy rewrite working code because s/he didn't like it or because  it was a prime candidate for a flashy new technology? Waste like that doesn't happen in good pairs. Neither does finding yourself at the end of a couple of hours having achieved little besides some web surfing, a few personal calls, and having reduced the size of your inbox? Or haven't we all seen great, creative solo work, that isn't what the business needs?

Evans doesn't acknowledge that pairing is a skill that takes practice to get good at, and for some developers getting good at it requires some people to step out of their comfort zones. Rather than his arguments against pairing, I'd like to see an article discussing personal challenges that pairing poses for some developers and the courage that it will take for them to become good pairers, if they want to avail themselves of the benefits of pairing.


* This claim may not even withstand scrutiny: http://bobsutton.typepad.com/my_weblog/2012/01/why-the-new-yorkers-claim-that-brainstorming-doesnt-work-is-an-overstatement-and-possibly-wrong.html

A New Big Visible for the Card Wall - State Change Criteria

I have a team that's just starting agile. During Sprint 0, we decided on a Definition-of-Done, but the team also wanted a way to make the criteria for moving a story card from one column on the wall to another big and visible. Being new, they thought it would help them to see, as they move a card from one column to the next, what had better be complete at this stage. If they had missed something, they have a chance to catch up before they actually move the card. We came up with yellow boxes that sit on the physical boundaries between columns on our card wall (see right). I'm calling them State Change Criteria (since there's already been a CCC since early XP days). The team left room to hand-write new criteria as their understanding grows and their process improves.

We came up with two more big visibles (not shown) that address the flow of "defects". One says: "In-sprint defects are moved back into Sprint Backlog." This is to remind the team that we don't track problems with in-play cards, we just fix and finish them within the sprint. The other says: "Escaped defects are written as new user stories and moved back into the Release Backlog." This is to remind the team that the Product Owner may choose to prioritize new functionality above fixing the defect.

Trying to get .Net Metrics Computed and Displayed with Jenkins

I'm helping a .Net team stand up Jenkins as their CI server. The build steps we have so far are building a solution and running fxCop against the debug build. Using the Jenkins Violations Plugin, which supports fxCop, we can display a nice trend chart and have hot links to drill down and see the violations in context.


My next goal was to run metrics that my team agreed on, specifically Cyclomatic Complexity and Coupling. I was hopeful because Visual Studio 2010 can already compute them. But I found out that Visual Studio's code metrics can't be called on the command line. 


Fortunately, I found Visual Studio Code Metrics PowerTool 10.0 for that purpose. There's lots of information already out about using it: Jeff Bramwell has a blog post about the PowerTool and Cameron Skinner wrote one about it.


Unfortunately, the Violations Plugin doesn't support the xml output, and the PowerTool doesn't have an option to output to HTML. Fortunately, though, Skinner also wrote a post that provides an xslt and a .css file that will turn the results into HTML.

So my next step was to make a build step that runs a command-line tool to apply the transform. I couldn’t figure out or find enough documentation on msxsl.exe, but I found this CodeProject project and it works. (Anyhow, it would only take a few lines to write your own in C# because you can use calls from MSXML.)

Now I need to figure out how to use the HTML report in Jenkins. I'll investigate the Jenkins HTML Publisher Plugin.

Why Pair Program?

Pair programming is one of the agile engineering practices that developers give me the most pushback on (probably second only to TDD). Here are some of the reasons I give for why we pair program:

• progress (driver) and research (navigator) instead of progress or research (solo dev)
• may avoid the need for code reviews, which can be contentious
• second set of eyes, catches silly mistakes
• less thrashing between QA and dev and back
• less time wasted down rabbit holes, as navigators offer perspective
• less time wasted on non-work distractions
• keep each other honest on practices like code quality, TDD, checkins
• reduces a team's bus factor, a significant business risk for IT projects

I'd like to write more about some of these, but I'm not sure when I'll get to it.

Refactoring - Is It Only Removing Duplication?

Today a colleague was looking for a TDD poster that showed Red-Green-Refactor with detailed emphasis on Refactoring. We found a diagram that simply said "refactoring = removing duplication". This got be thinking about a post by JB Rainsberger in which he said: "...if you master removing duplication and fixing bad names, then I claim you master object-oriented design." (If you see this, JB, do you still make this claim?)

There are lots of kinds of duplication, and JB's assertion makes sense to me especially when I think about the kind of informational duplication (as opposed to code duplication) that DRY is intended to avoid.

After Agile Coach Camp 2011

I spent this weekend at Agile Coach Camp in Columbus, Ohio. It was my first open space conference, and I loved it! Learn about Open Space unconferences on Wikipedia.  I won't even try to explain it.

Friendship, community, sharing, equality, questions, suggestions, personal revelations, self-examination, laughter, fun - I received all these things and more. Zee Spencer summarized some of the sessions here, and I'm sure there will be others. There's a picture of the sessions board showing most of the Saturday sessions.

You can get a small taste of the amazing energy of the event by reading the #accus hashtag on Twitter.

In 2012, Agile Coach Camp will be in Minneapolis. If you can, you owe it to yourself to go.