Cincy Clean Coders – Code You Can Show Your Friends

What would a Monday following an Agile conference be without the announcement of a new group focused on quality practices!


I’m happy to announce that Cincy Clean Coders is really going to happen.  Details can be found at, but suffice it to say the inaugural meeting will be held April 7th at 6pm in the Max Train facilities in Mason, Ohio.

Mark Haskamp was strong armed brave enough to offer to go first with me.  I’ll update the site with the topics for the first meeting soon.

Big Thanks to Ernie Stormann and Parag Joshi who helped push this through.  And a big kudos to the rest of Twitter for being excited about a topic like this.  It says a lot about where our industry wants to be.

Help! You might notice I’m not a designer.  If you want to help, we could use a site design that doesn’t compare to notepad in a browser.  Nothing special, just, you know, some other than black on white text.

Cincy Day Of Agile 2011 is Open for Registration

Cincinnati Day of Agile, to be held March 26th, 2011 at Savannah Conference Center, is open for registration.  This is a cheap ticket with huge returns that sold out quick last year. 

We’ve made more tickets available this year, but don’t expect them to last too long.


Register here:


Topics you’ll find at Cincinnati Day of Agile:

Scrum Defined Phil Japikse
Five Things to Be More Agile  
Agile is Just a Word Chris Nelson
Team Pulse Demonstration Joel Semeniuk

Introduction to Pair Programming

Steve Smith
Moving from Fail Last to Fail Fast Nilanjan Raychaudhuri

Missing Pieces: The Road from Agile Enthusiast to Agile Team Member

Ryan Cromwell*
Seven Habits of Highly Effective Chickens Rob Keefer

High Performance Workspaces

Sean Heuer

Don’t Get Lost in Translation: Effectively Translating Agile into Enterprise Program Management

Mike Kompar
Enterprise Agility Phil Japikse

Common Design Patterns in Web Applications

Steve Smith
Dynamic Languages and Why You Should Care Chris Nelson

*Blog owner bias acknowledged


There will also be an awesome 3 hour, hands-on workshop by Mark Windholtz and open discussion round tables.

Rules of the Game: Effective Group Discussion

Meetings are hard.  They can easily suck the life out of your day, week, or *gasp* job.  Let pain be your guide. (Thanks @coreyhaines)

I recently had to work through a mountain of feedback data provided by a limited product release.  User Experience experts, random individuals, and customers known for their willingness to provide quality feedback gave us excellent information.  The question became how do we effectively process the information as a team. 

Here a redacted version of the meeting notice I sent out:

We have feedback from some users. We need to talk about it, but it’s a lot of info.

Here’s the tentative plan (tentative because someone might think of a better one).


15min · Soapbox

30min · UX Feedback

30min · Customer Feedback

15min · Next Steps


We need a really, really good note taker.  Volunteers?


Rules of the Game

  1. Each person receives 3 uninterrupted minutes for their soapbox.
  2. Interrupt someone during their soapbox and you lose a minute from yours.
  3. Maximum 5 minutes on any one feedback item.  Action item to dig in later.
  4. Fist in the air by anyone immediately halts discussion on the topic and we move to the next. Action item to dig in later.
  5. Add a sticky note to the wall if you want to discuss something relevant by off topic.
  6. Try to have read as much of the feedback as possible before the meeting.

The key to any meeting is preparation and an effective recorder.  By having a timeboxed agenda, audible timer, rules, and an awesome recorder meetings can actually be fun! 

I love the Soapbox for two reasons.  First it gets everyone talking.  Even the quiet person has three minutes (or a really long, awkward silence).  If someone finishes before their allotted time, sit quietly (you kinda have to or you lose a minute yourself!).  They will probably come up with something else right before their alarm buzzes. The second reason I love the soapbox is that you can then get down to business without people interjecting something off topic.

We didn’t make it through everything, people were cut off by the alarm, and people didn’t get to say everything during their soapbox.  It’s ok.  Do it often and people will learn to be direct, to prioritize their thoughts, and to PREPARE.


Now, back to my code.

Cincinnati Professional Scrum Developer .Net Course (Feb 21st)

[Correction: This is the first for the new year.  This certainly is not the first ever.]

I’m happy to announce that our first Professional Scrum Developer course of 2011 is scheduled for February 21st.  This is a course which practices 5 days of craftsmanship, collaboration, and sustainable pace via the Scrum framework.  Practice is the key to success and there is no better way to build a successful Agile team than to work together, continuously with a coach available to guide you through unfamiliar terrain.

Every team has it’s own happy path to a successful, self-organizing, self-managing Scrum team and it is not an easy one to navigate.  During these 5 days we will experience brown-field product development using Modern Engineering Practices such as TDD, Continuous Integration, Refactoring, and more.  Our case study is an ASP.Net MVC application.

Register for the course with who graciously provides the facility and infrastructure., founded by Ken Schwaber to improve the profession of software development so that developers love their work and our customers love working with developers, describes the Professional Scrum Developer course in detail.  You’ll also find the course syllabus here.

Look forward to seeing you there.

Where Scrum and Craftsmanship Converge

"Your team may be dysfunctional … but at least you can see the impediments. Now you have the ability to do something about it!"
Kane MarScrumology, Scrum Coach

This fantastic statement about Scrum highlights the most important aspect of Scrum that is invariably lost in most Scrum implementations in which an experienced member or coach is not present.  In the context of your Team’s skills and the quality of your product this is an incredibly powerful statement.  One which enables developers to produce high quality software they can be proud of at a sustainable pace.

What is often perceived as a failed transition to Scrum is, in actuality, an organizations first, all be it scary, encounter with the power of the Scrum framework.  By committing to a minimal portion of the Product Backlog to be delivered in a relatively short timebox and, finally, asking the Team to demonstrate this potentially shippable product we ask the Team to expose their weaknesses early and often to a large audience.

Some of the most common weaknesses include misunderstanding customer needs, poor estimation or over commitment, and skill gaps.  These issues existed all along, but Scrum makes them more apparent.  All are essential to the successful delivery of a product where success means a satisfied customer, but some are more recognizable than others.

Misunderstanding customer needs is immediately evident during the sprint review in which Working Software is demonstrated.  An effective Team will increase Customer Collaboration to avoid a future embarrassing sprint reviewThis is also where an effective Scrum Coach makes their mark in guiding the Team into effective practices.

Poor Estimation is also one of those obvious problems, but it takes time for a team to become effective in estimating.  The more critical problem is habitual under estimation or over commitment.  By making available the Team’s actual velocity in the sprint review it becomes difficult for the team to continue over committing time and again, but an effective coach can highlight the importance of velocity when planning a sprint and projecting a Product Backlog.  Transparency has a wonderful way of solving many problems naturally.

Skill gaps, not surprisingly, are the most likely to be overlooked (and often ignored).  A Team which neglects its craft will eventually see decreased velocity as a result of rising bug rates and complexity.  The Team alone is responsible for the quality of the software delivered to clients and it is here that we see the convergence with Software Craftsmanship.

“Scrum’s purpose is not to be sufficient: it is to set the team into an improvement loop whereby they try to build software, observe what is wrong, and fix it.”

– Ron Jeffries – XProgramming, Co-founder Extreme Programming

Software Craftsmanship is an extension to the Principals behind the Agile Manifesto which compels developers to challenge their skills in the craft of software development.  Scrum provides two important tools which integrate this notion of Craftsmanship: the Definition of Done and the Sprint Retrospective.

Definition of Done is whatever the Team means when it commits to a Sprint.  It should be influenced by the environment in which a team operates and be made apparent to the Product Owner and other teams, though the Team is ultimately responsible.  The Definition of Done acts as a valuable tool to enable evolution of a Team’s skills and a product’s quality through expansion and refinement. 

An example of the evolution of “Done” might be seen as initially stating that all new features must include at minimum one automated test.  While rather abstract and vague, this allows the team to experiment and learn the techniques for testing while building an inventory of tests which can validate the existing functionality.  During a Sprint Retrospective a team may come to the conclusion that it has sufficiently exercised its skills and resolve to expand the Definition of Done to state Code Coverage will not decrease from Sprint to Sprint.  This improvement loop continues with each Sprint.

Software Craftsmanship relies on the initiative, abilities, and imagination of the Team.  Scrum provides the framework for a self-organized team of Craftsman to enact their skills.  The result? An engaged team producing ever higher quality software at a sustainable pace.