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.

Advice for someone wanting to get (back) into software development

I was talking to a friend today who was doing software development several years ago but has been unemployed for a while. He asked if I had any ideas about what he might to to get back into software.

(An an aside,  Patrick Welsh already wrote a great piece about why people should consider a career in software)

Here are some of the thoughts I gave my friend on how to get (re)started in the industry:

- If you don't have work experience to show on your resume, create relevant non-work experiences and structure your resume to show them.

- If you're not already on Twitter, set up an account and use the search function to find experts in the areas you are interested in. Follow them.

- Attend groups/events where people who do what you want to do gather. Ask people questions about what they do. Ask what blogs they read and who they follow on Twitter.

- Start learning web programming, throw up a website, publish the code on someplace like github, and keep updating it. One place to start might be: http://railsforzombies.org/

- Expose yourself to new languages and technologies: ruby, scala, functional languages, automated testing, continuous iteration ...

- If you're not currently working, ask about an internship someplace you'd like to work at, even if it has to be unpaid.

- Be helpful - volunteer for anything related to your targeted field. People remember/like you better if you've helped them. Less cynically, it gives people a chance to see who you are and what your attitude and skills are.

- Don't get hung up on getting/finishing a degree if you don't already have one, especially if it would take away from getting real life experience.

- Read this book about managing your software career:
"The Passionate Programmer: Creating a Remarkable Career in Software Development" by Chad Fowler

- Consider reading this book about agile software development:
"The Art of Agile Development" by James Shore


Finally: Don't follow my advice without deciding for yourself if it makes sense for you. Ask other people about it as well.

Coding in the Clink IV - my second coding retreat at Marion Correctional Institute

On Saturday, I attended Coding in the Clink IV at MCI. It was great to see the inmates again. We all agreed they have made great strides in their learning since the last time we worked with them in March.

This was my second time spending a day programming with inmates at MCI. The first time in, I got to have my stereotypes blasted. As I said in my previous post about Coding in the Clink, one thing that struck me most was how similar the day was to a full-fledged CodeRetreat on the outside.

This time, I was reminded all day of just how careful I need to be when pairing with or coaching a less experienced developer. If I'm not careful, it's easy for me to press ahead with my own ideas and simply explain to my pair what I'm doing. That doesn't always leave my partner room to struggle with ideas, and in that moment I'm not letting them succeed in solving a problem or explaining something to me or probably other ways.

On the outside, while pairing in this way is not what I strive for, a little bit of it isn't necessarily a disaster. Unless they are in way over their head, most devs I pair with will assert themselves and claim their role a partner, even when I'm not sharing well that day. When that happens, I often "wake up" and start "playing nice" again.

But in prison, inmates are predisposed to not assert themselves to outsiders. Dan Weibe mentions it in his post "But-but there are CRIMINALS in prison!":

...The program is seen by the prisoners as a very good thing, and any attack on it ... could get the whole program ejected ... [and] life would immediately become very dangerous for the offending prisoner. Everybody knows this...

Here's the part that illustrates why I have to be extra-careful to be a good pair in the prison:

... in some cases the normal give-and-take of pairing can be hamstrung when a volunteer and a prisoner pair together because the prisoner strains to be pathologically accommodating.

To some extent, I let myself fall victim to that this weekend at CitC IV. I still think the inmates that I paired with had good experiences this time, but I would have liked to offer them more. Looking back to my first visit to MCI, I was better pair/coach that day, doing a good job at things like:

• meeting the man where he is
• inviting him to try things
• asking him some questions that he knows the answer to
• asking him harder questions so he has to stretch himself to come up with an answer
• making small suggestions when he's stuck rather than giving answers
  
• putting aside my desire to make progress in the code in favor of getting to know my partner a little and facilitating his learning

Now that I've spent some time thinking about this, I feel prepared to be the kind of coach/pair that I know I can be at the next CitC. I just wish the institution could accommodate more than one event like this per quarter.