Podcasts!!!

So about 3 years ago I moved to Atlanta and have had a daily one-way commute between 45 and 80 minutes long.  In order to more effectively use that time, I have joined the podcast community.  With almost 3 years of experience, I wanted to share some of the podcasts that I regularly listen to.  I'm sure that I'll add and subtract from the list as time and tastes change.  Understanding that everyone is a unique individual, your mileage may vary but I hope that you find something that you haven't previously discovered and expands your learning!

My recommended podcasts

“Thinking in F#” and “Software Craftsmanship and Agile Code Games” Slides

I’ve posted the slides from my recent presentations at Utah Code Camp 2014.  If you missed it, I’ll be presenting “Thinking in F#” at Boise Code Camp 2014 on April 5th and “Software Craftsmanship and Agile Code Games” at Mile High Agile 2014 on April 18th.

Check out these and previous sessions on my Sessions page.

StrengthsFinder Team Activities

While I was at Ancestry.com, we used the StrengthsFinder assessment to give us insights into ourselves.  If you haven’t taken it, I highly recommend it.  You can purchase a code, or you can get one with a copy of StrengthsFinder 2.0 or Strengths Based Leadership.

While it’s interesting to know about yourself, when in a team setting it’s equally important to know about your teammates in order to work effectively with them.  To help my team with that, I designed some activities for us to do as a team.  Here are my notes to facilitate the activities.

StrengthsFinder Team Activities

Team Top 5 Grid

Team Top 5 Grid - Google Sheets version

A few months later, we did an activity with multiple teams in order for those other teams to get to know each other better and the teams to know and understand each other better.  This includes many of the same individual team activities while adding some activities that have the teams interacting.

StrengthsFinder Multi-team Activities

Again, many of these are to help team members understand and appreciate each other.  Also as you do these activities, keep in mind that the debrief (the questions and conversation after the activities) are where the real action is.  The point of the activities isn’t to teach but to facilitate learning.  You’ll want to give clear explanations (possibly have slides to show instructions) and then walk around, listen to what’s going on, answer questions and offer gentle suggestions.

Hope these are helpful to someone!  Feel free to use all of these, cherry pick and/or remix with your own ideas.

This work is licensed under a Creative Commons Attribution 4.0 International License.

After the Offer Come the Questions

There are some questions that are appropriate to ask in an interview and some that should be reserved until there is an offer.  Somehow I became “famous” for the questions that I ask after I’ve been extended an offer.  For me, these are important to give me a more complete view of the working environment and attitude of the company and team that I might join.  It also gives insight into specific policies and practices.  I like to have as much information as possible when considering an offer. I also want to reduce the number of surprises after an offer has been accepted.
I’ve been asked several times for the “list of questions” that I ask and I’ve promised a blog post for a while, so here it is!  Here are the categories that I am interested in with questions that I’ve used in the past for each.  These, of course, need to be suited to the particular situation and some you may not care about.  And some I will ask in an interview depending on how well I know the interviewer.  Enjoy!

1. Hardware
1. What is the hardware setup for developers?  Desktop/laptop, monitors?
2. Would I be able to choose anything about my systems or is there standard hardware across the company?
3. How often is hardware replaced?
4. With hardware, would I be able to choose my own mouse and keyboard? 
5. Is it okay to bring in personal hardware?
2. Software tools
1. What software tools does the company provide?  (Resharper, NCrunch, profiler, etc) 
2. Does IT have heartache over what's installed on a developer's box (other than file sharing software or other things that would eat bandwidth)?
3. What source control repository do you use?
4. What sort of testing environments are there?
5. What test testing frameworks do you use? nUnit, xUnit, mbUnit, mSpec?  Acceptance tests?  Fitnesse or something similar?
6. What sort of tools do you have/build/maintain around the health of your systems (to monitor, alert, etc)?  Is this something the dev team works on or is there an Ops team?
3. Physical environment (usually you get to see this as part of a tour at your interview, but if not for some reason)
1. What type of desk and chair are provided?
2. Would travel ever be a part of this position?
4. Learning
1. What sort of policy does the company have around budget for learning?  For example book purchases, conference fees/travel, online courses.
5. Company Policies
1. What does the performance review process look like?  What criteria are used?  Are employees evaluated on an absolute scale or on a curve (with respect to their peers)?
2. What does a "typical" annual raise look like?  What does an extraordinary annual raise look like?  What criteria determine this?
3. What does the title/level system look like?
4. Is there a Moonlighting Policy?  For example if I write a project at home (on my own time, on my own hardware with my own tools) am I able to retain rights to that software?
5. Is there a policy on contributions to open source projects, either out of something at work or on my own time?  What about use of Open Source Projects?
6. Dress code - is there one and if so, what is it?  (and is it strictly enforced if there is one)
7. Is there a policy on bereavement leave?
6. Team Culture/Process
1. Iteration/release cadence - What does an iteration look like (planning, retrospectives, review)?  Do you have a daily standup? Who attends?
2. Requirements - how are requirements expressed in the team?  User Stories?  Use Cases?
3. How are they tracked?  Is there a big visible board somewhere or is it tracked electronically (and if so, what software is used).
4. Where do these requirements come from?  How is the backlog generated?  Are stories decomposed into tasks or is a story the unit of work?
5. Estimation - Do you generate estimates and, if so, what method/process is used?
6. Are you currently doing continuous integration? If so, what platform are you using to do that?
7. What about continuous delivery?
8. How much code is the team responsible for?
9. What is the test coverage like?  Is TDD used on the team?
10. What percentage of the time is the team pairing? What activities does the team pair on and which do they not?
11. How does this team interact with other teams in the company (if there are other teams)?
12. What is the team culture around lunch?  Do most people work through lunch, eat at their desk, go out alone, go out as a team, go out with other people in the company or outside the company? (I'm guessing that all of these happen occasionally, looking more for what the norm is)
13. Are there any snacks/food provided by the company?  Any pot luck events?
7. Career Path
1. Are there continued growth opportunities available without moving into management?
2. Are there opportunities to move into management?
3. I'm interested in knowing what you feel I would bring to the team (how I could contribute immediately and longer term), how you see me fitting on the team, what the main attributes that you see that led you to extending an offer and what things you see that I would need to work on.

There are also questions about benefits and such, but those are very specific based on the information provided.
There is another list that I’m starting for the team that I’d be working with.  Here is what I’ve started with:

1. What do you enjoy about your job?  What are some of your favorite things?
2. What are some of your least favorite things?
3. What changes would cause you to leave?  (as a fill in the blank: If ______ changed, I would leave.)
4. What would another job offer that would cause you to go somewhere else (excluding money)? (as a fill in the blank: If another company had _______, I would go there.)
5. What, if anything, do you miss from a previous job?

So there it is.  I hope these are useful but you’re probably thinking “duh, of course I ask those things.”  In that case, the curtain has been pulled back.
Is there anything that I should add to these lists?

Published on Ancestry.com Roots Tech blog

Posted a blog entry on the new Ancestry.com Roots Tech blog called “Games at Work?”

Here’s the opener…

Agile Games are a way for teams to learn and apply agile concepts in a fun, playful, safe environment. Play is important as it brings aliveness to our work environment that allows for creativity and our best work to flow.  Games provide a safe environment where people are more open and willing to take risks and embrace change.  The safety of games also allows us to talk about work… without necessarily talking about work.

Go check it out!

Employer Investment in Employees

Uncle Bob has a pretty clear opinion on who has the responsibility for a programmer’s practice/learning:

Professional programmers practice on their own time. It is not your employer’s job to help you keep your skills sharp for you.

Uncle Bob in The Clean Coder Chapter 6

Here Uncle Bob is talking to programmers, to employees.  What I hear is “don’t expect your employer to help you out.  If they’re not, that’s not an excuse.”

So, my question is, does that mean that employers should not provide any learning opportunities for it’s employees?

Sure, programmers are responsible for their own learning opportunities but could part of that be making sure to find an employer that provides those opportunities?  I personally take some time outside of work to sharpen my saw, but I also look for an employer that cares enough about me to invest in me.

Here is my reasoning why an employer would want to provide learning:

• Hiring is hard and expensive. If you have people that are a good fit, it’s usually easier to improve their skills than to hire someone new.
• Learning opportunities at work can inspire people to pursue outside work opportunities.  I have has several people that I work with start attending Utah Software Craftsmanship, Utah Code Camp and Coderetreats because of things that we’ve done during working hours.

What do you think?  Should employers provide opportunities for practice and learning?

If you happen to be a psychic: Quote of the Week

Just started reading Refactoring to Patterns.  Starts off with a good reminder that YAGNI.

When you make your code more flexible or sophisticated than it needs to be, you over-engineer it.  Some programmers do this because they believe they know their system’s future requirements.  They reason that it’s best to make a design more flexible or sophisticated today, so it can accommodate the needs of tomorrow.  That sounds reasonable – if you happen to be psychic.

Joshua Kerievsky, Refactoring to Patterns p.1

Look at the code you’ve written recently.  Were you pretending you’re a psychic?

Retrospectives and Local Maxima

 

Sometimes we feel like this:

We are at the top of the mountain!  We’ve climbed, we’ve improved and we’ve made local, incremental changes such that we’re not quite sure where to go from here.  We don’t know where else we could possibly go to move higher.

What we’re missing is this:

Yeah, there’s a higher point behind us that we can’t quite see.  In math this is a “local maximum” where we’ve found the “highest point” but only if we constrain the graph we are looking at.

So can we find a global maximum?  Or at least a higher local maximum?  Why can’t we see it?  And how do we get there?

Most retrospective practices (Stop/Start/Keep style activities) will generally get us incremental improvement and will usually lead us to these local maxima.  I’m a big fan of retrospectives and incremental improvement so I’m not bashing these in the general case.  We need to do this once we find a hill to climb, but sometimes we need to find a new hill.

So what can we do to find a new hill?  We need to shake up our team and give them a Jolt.  While I have several ideas how to do that, today I’m going to focus on one: Defining and Focusing on Team Values.

Team Values?

Whether you’ve defined them or not, your team has unspoken values. The value in defining them and talking about them is ensuring that there is common understanding in the team and giving a common language for the team to use.  The values give you a framework for decision making, especially around how you will execute. 

For example, if your team values “time to market” they might take shortcuts and hack something together but a different team that values “maintainability” may take more time to deliver, but will be more maintainable in the future.  (We can debate the relative merits of each of these and if they are really in conflict but this is just an example.)

Team Values Round 1

On my team, earlier this year we came up with eight team values.  When asked what our team values were, we struggled to remember all eight.  We didn’t really know how to focus on all eight or even did a good job of picking one to focus on.

Lencioni’s Value Model

In The Advantage by Patrick Lencioni he describes four different types of values.

• Permission to Play – These are values like “integrity” that if you don’t have them, you’re not going to be around long anyway so they are really just a required baseline.
• Core – These are the values that you currently believe in and embody as a team.  They are also central to what the team is and how they do things.
• Aspirational – These are values that you want to have as an organization but you’re working on.
• Accidental – These are values that the organization has developed but you’re not quite sure if you like them or not.

This, in some ways, is a Start/Stop/Keep (Aspirational/Accidental/Core) activity, but at a value level that makes you step back and take a wider view.  In our original list, we didn’t differentiate between different types of team values which didn’t give us a place to focus.

Team Values Round 2

So in a recent retrospective, I explained Lencioni’s model of value types and then challenged the team to refine the list to 5 values and classify them as either Core or Aspirational.

The concept of “Permission to Play” gave us a term to talk about certain values that were proposed and exclude them.  Using Lencioni’s model helped us to clarify why we wanted to certain values listed.

We started with the eight that we had originally come up with and I threw out several additional ideas including the XP values, the values from the Agile Manifesto and Software Craftsmanship Manifesto and other sources.

As a framework for voting and subsequent discussion, we used Fist-to-Five voting (we nick named it “Fist voting”) to decide if values were in or out and if they were Core or Aspirational.  While it might seem silly to quibble over such things, I often go back to this quote:

Often the true value of a thing isn’t the thing itself, but instead the activity that created it.

-Dave Thomas

I found the discussion and the clarification of thoughts and terms to be one of the most valuable aspects of this exercise.  We came to a better common understanding by forcing each other to clarify what we meant with different values.

One example of this was one of the original eight values was “teamwork”.  As we talked about it, it seemed like this might be “permission to play” or at least too broad and poorly defined.  So we debated about words.  What word or phrase would better embody what we really felt we had or needed as a team.

Eventually “Team Ownership” was proposed.  The team liked it but the team was split on whether or not it was Core or Aspirational.  This might seem trivial, but the divide produced a valuable discussion around what that really meant.  Half thought “well, we help each other out and pitch in when needed already, seems like it’s Core” while the others thought “we often have our own areas we’re working in and not really collectively owning all the code or even all the tests”.  Clarifying how we wanted to define Team Ownership drove us to decide it was Aspirational.

Now we have them… so what?

Once we defined what our values were, we used a variation on the Values-driven Retrospective.  Specifically we used the Believe Statement format (which is We Believe in [insert value], therefore we will [insert what we do]) to generate ideas of what actionable items to work on.  From there we used dot voting to narrow the field and decide.

The other value that our values has given us is the framework to talk about what and how we are going to do our work in a more focused way. 

I hope that this method can help you and your team to jump off your local maxima and find a taller hill to climb as a team.

Addendum

For those interested, our team values are currently (in no particular order):

• Core
• Learning
• Testability
• Sustainable Pace
• Aspirational
• Ease
• Team Ownership

They actually ended up very similar to our first eight, but more focused.  As a side note, I fully expect to reexamine these again in the future.  As our team changes and grows, our values will likely need some tweaking.

Global Day of Coderetreat 2012: Utah Style

Global Day of Coderetreat (GDCR) is coming up on December 8th this year.

Don't know what Coderetreat is? Check out http://coderetreat.org/about

Don't know what GDCR is? Check out http://globalday.coderetreat.org/

Pluralsight (@pluralsight) and Ancestry.com (@Ancestrydotcom) are sponsoring two Coderetreats in Utah. David Adsit (@davidadsit) is organizing both (I personally think he's a little crazy for doing that, but David is a little crazy). They will be at the two Pluralsight offices (Layton and Lehi).

You can register for one of the two events below on Eventbrite.

If you’re in Utah County or South Salt Lake County…
Facilitated by Kay Johansen (@utahkay)
http://lehi-ut-coderetreat.eventbrite.com/
http://coderetreat.org/events/global-day-of-coderetreat-2012-lehi-utah-us

If you live further north…
Facilitated by Jim Cooper (@jimthecoop)
http://layton-ut-coderetreat.eventbrite.com/
http://coderetreat.org/events/global-day-of-coderetreat-2012-layton-utah-us

If you have any questions, please feel free to contact David or me directly or check out http://utahsc.org/ for more updates.

Agile and the Chasm

In the book Crossing the Chasm: Marketing and Selling Technology Project, Geoffrey Moore discusses the idea that technologies start with early adopters and at some point must “cross the chasm” to majority.

At the recent Salt Lake Agile Roundtable meeting, there was a brief exchange on if Agile had crossed the chasm.

My thought (which is informed by recent experiences with the majority) is that the term “Agile” and some of the practices (Scrum/Scrum-like practices) have crossed the chasm but the values expressed in the manifesto have not.

What do you think?  What has your experience been?

Does the Manifesto matter?

I recently had the chance to interview candidates for a position on my team.  I put together a list of questions that I believed would be a unique and effective way of phone screening candidates.  Without giving away the whole list (I may disclose it later), here are the first two questions:

1. Tell me something about yourself that isn’t on your resume.
2. Are you familiar with the Agile Manifesto?

I had two out of seven candidates that I phone screen answer in the affirmative to question 2.  Now not being familiar with the Agile Manifesto isn’t necessarily uncommon, I guess.  But the inconsistency came from the answer to the next question:

“What Agile practices are you familiar with and/or have used?”

I figured the answers would be “I haven’t used any”.  Because if you have done “Agile practices” you’d certainly know what the Agile Manifesto is, right… right?

BUT…

the answers were mostly in the “like, Scrum? Stand ups? Yeah, we do that stuff on my team.”

So… these candidates had presumably been introduced to the term Agile, to some Agile practices but hadn’t taken the time to investigate further, to understand the roots of the Agile movement, to do a quick Google search!  Granted none of them had incredible answers to the Agile practices question, but they did have answers.

I guess I just don’t get it.  I mean, I do.  But I don’t.

Would this matter to you?

CodeRandori.com and AgileCodeGames.com

I recently purchased these domains and while I have plans for them, I haven’t done anything yet.  So I decided to just have them forward here to my blog for the time being.

The plan for CodeRandori.com is to have a “one stop” resource for what a Code Randori is, how to facilitate and some example problems to use.

I’m not entirely sure about AgileCodeGames.com  I was thinking maybe to have a “Tasty Cupcakes”-like site but for coding games (like katas and randori and pairing games) but I’m not sure.

So what do you think?  Any ideas on what to build at these domains beyond what I’ve planned?

On Speaking… and not speaking

So as I mentioned in a previous post, I’m working to expand my speaking footprint this year beyond Utah.  This started out pretty well with a three session gig at Boise Code Camp which was a blast.  There is a great dev community up in Boise and I plan on going back next year.  I was able to attend Agile Games 2012 in Boston which was amazing.  Need to do a write up on that soon before everything leaks out of my brain :)   Again, more great people and I felt super enriched after the three days.

Unfortunately, around that time, my sessions were turned down for MADExpo and Chicago Code Camp.  I was pretty bummed about it, more than I thought I would be.  I plan to try again next year and market my sessions better.  Need to figure out how to get more buzz words into my titles :)

Happily I have been accepted to Agile Roots.  I’ll be running “Hands-on Group TDD with Randori” (title pending).

Additionally, I’ll be presenting at the Utah .Net User Group this Thursday (May 10, 2012) on “Linq (from the inside)”.

I’m still waiting on Portland Code Camp and Seattle Code Camp which I hope to still speak at.  I’ll likely go to Portland Code Camp either way as we’ll be in Portland to visit family.

I am hoping to attend SCNA in Chicago in November.  And that should round out the year.  Should be exciting!

Utah Code Camp Spring 2012 Slide Decks

I had the opportunity to speak at Utah Code Camp again (my fourth code camp presenting Fall 2011 Spring 2011 Fall 2010) which was a lot of fun. Not sure if I would do three presentations again, but it was a lot of fun and I met a lot of great people.

If you attended one of my sessions, please take a minute to rate the session at SpeakerRate (not official eval… please do that too):

• Rate Code Katas: Practicing Your Craft
• Rate Randori: Group Practice 
• Rate Linq (from the inside)

Here are the slide decks. Contact me with any questions!

Randori: Group Practice

View more presentations from Mike Clement

The Randori starter project is available at https://github.com/mdclement/NumbersToLcdRandoriBase

The Code Katas session was presented as two slide decks.  One with the introductory material and the other with the guided FizzBuzz kata.

Code Katas Spring 2012

View more presentations from Mike Clement

FizzBuzz Guided Kata

View more presentations from Mike Clement

Linq (from the inside)

View more presentations from Mike Clement

The code base that I started from (tests and methods without implementation) is available at https://github.com/mdclement/Linq--from-the-inside--Presentation-Base

Expanding my Speaking Footprint in 2012

So one of the things that I plan to do more of this year is presenting at Code Camps and the like.  I’ve presented several times at Utah Code Camp (Spring 2011, Fall 2011), but want to expand my footprint.  So, I’m currently submitted to Boise Code Camp, Chicago Code Camp and MADExpo.  Over the next few weeks/months I’ll see how well my session topics are received outside of the Utah community.  I also plan to submit to Portland Code Camp and Agile Roots this year once their calls for speakers are open.

If you’ve attended (and hopefully enjoyed) previous sessions that I’ve presented, please rate me at http://speakerrate.com/mdclement

The topics that I’ve been submitting (and that I’ll be presenting at Utah Code Camp Spring 2012) are listed below along with the abstract.  I’m looking forward to an exciting year of meeting with developer communities both inside and outside of Utah!

Linq (From the Inside)

Knowing how to use Linq is useful if you're doing any coding using .NET 3.5 or newer.  But have you ever thought about what is going on "under the hood"?

Join us as we dive into the guts of Linq and implement Linq extension methods such as Where, Select, Any, All and Sum.  Not only is it interesting to see what's going on, it'll help you to build better code using Linq.

Code Katas: Practicing your Craft

One of the key values as part of the Software Craftsmanship movement is to be "skill-centric" and as part of that, practicing our skills as software developers is key! The Code Kata format is a coding exercise that is repeated and perfected. It provides one of many ways to practice the craft of software development. We'll discuss the Code Kata format, introduce a few katas and discuss some other practice formats.

I will be guiding the Kata in C# (no previous knowledge necessary though). As this is hands on, to take full advantage of the session have Visual Studio or SharpDevelop installed, NUnit installed (or via NuGet) and an integrated unit test runner (recommend Resharper or NCrunch for VS).

Randori: Group Practice

Looking for a new way to practice your craft? Randori provides a complementary way type of training when compared with katas.

Elements of Randori are: Pair Programming, Pair changes with mechanism (Time box, Ping Pong), Start from scratch, Use TDD, Everyone should be following, Pair should be explaining, Audience gives suggestions only with when Green

An example is at http://vimeo.com/2499540 . This is a hands on session!

But I really learned from writing: Quote of the Week

Note: Might be silly to call this a “quote of the week” given that it’s been years since I posted one but… oh well.

Heard this this morning on NPR from an interview with the composer Philip Glass:

What this amount of music has done for me is taught me how to write music. Oh, I had great teachers. Boulanger was one. Another was Ravi Shankar. And I went through the Juilliard process, and that was good, too. But I really learned from writing, which is how painters learn to paint, and writers learn to write, and how even dancers learn to dance. In a way, that's true. But what was the value of being so prolific? It's how I learned my trade.

Philip Glass from Philip Glass At 75: Listening With Heart, Not Intellect

What I heard in there is "But I really learned from writing, which is how painters learn to paint, and writers learn to write, and how even coders learn to code."

Utah Code Camp Fall 2011 Slide Decks

I had the opportunity to present at the Fall 2011 Utah Code Camp on September 10, 2001. I have uploaded my slides to Slideshare.
If you attended one or both of my sessions, please take a few minutes to evaluate the sessions at SpeakerRate.

• Rate "Code Katas: Practicing Your Craft"
• Rate "Power of Patterns OR More than Programming with Objects"

On both of these presentations, you’ll be able to glean things more from the speaker notes than from the slides.  I plan on posting more on each of these subjects later.

Power of Patterns OR More Than Programming with Objects

View more presentations from Mike Clement

The Code Katas session is divided into two slide decks; one for the session specific slides and another for the slides for the Bowling Game Kata in C#.

Code Katas: Practicing Your Craft

View more presentations from Mike Clement

Bowling Game Kata in C# Adapted

View more presentations from Mike Clement.

Utah Code Camp Spring 2011 Slide Decks

As I’m sure at some point they will not be available on the Utah Code Camp downloads page, I’ve gone ahead and posted my slide decks from my sessions on SlideShare.  They are not entirely comprehensible, especially the Rhino Mocks one since the majority of the time was spent in code.  I’ll get that posted soon as well.

Using Rhino Mocks for Effective Unit Testing

View more presentations from mdclement

Software Craftsmanship

View more presentations from mdclement.

Lessons from Laser Tag: Metrics and Feedback Loops

Recently the Utah Development Center at Microsoft (where I work) had a “morale event” (I still think it’s funny that they explicitly call them that) where we visited a local laser tag place.  We played three times and each time I ended up in the middle of the pack (yeah, I’m not that good).  But I did see some interesting lessons that could be taken from the experience.  Here is one of those lessons.

After the first round, an interesting thing happened.  We each got a printed “score card” to tell us how we had done.  It had how many kills, how many timed you were killed, breakdown by opposition player (friendly fire was off), number of shots fired, accuracy percentage and some overall team stats.  The one additional number on the sheet was “rank”.  Being good little programmers/engineers, most of us started to try to reverse engineer the ranking algorithm.  It appeared to be surprisingly simple.  We were ranked by number of kills. (I don’t think this was confirmed, but we suspected that number of timed you were killed was used as a tie breaker.)

It was like the game totally changed.  Because it did.

Suddenly the feedback loop from the metrics used gave us this: Don’t worry about accuracy percentage, don’t worry about the number of times you get killed.  Kill the most people and you win. The only thing that matters to your rank is number of kills.  The next game the overall kill count went up significantly (about 20% increase).

Metrics have the tendency to focus us like this, which is super powerful.  But remember, with that great power comes great responsibility.  While many still played for “team pride”, for some people the individual ranking became the most important personal metric of success.  If you no longer care about the success of your team, the number of kills that you sustain no longer matters.  It is not a metric that you care about. All that matters is getting the most individual kills.

Choose the metrics that you use with care.

A recent real life example that I heard went something like this: The manager of a development group doing SINO (Scrum in name only) set a goal for the group that “this year, we’re going to get everything done that we commit to for a sprint done in that sprint.”  This is a well intentioned goal.  Basically do what you say you’re going to do.  BUT, if that is the metric used, what happens to the amount of work committed to in a given sprint?  In order to do well against the metric, the amount of work committed to drops (or estimates are WAY high).  Suddenly half way through a sprint (or less) the developers have completed the work that had been committed to.  All that matters is getting the work committed to done.

Some managers reaction would be to think, “Well, that didn’t work, lets add some more metrics to get what I want.  Let’s continue to try to control the system.”

That may or may not be the best approach.  Eventually you may end up with a system that is so bogged down with itself that no work actually gets done.

I’m not saying that metrics are bad.  They can be very, very good and are very, very powerful.  Just be sure that you’re using the right tool for the right job.  Don’t use a nail gun where the gentle tap of a hammer is the right thing.

Prime Factors Kata in C#

I recently led a practice of the Prime Factors Kata in C# at the Utah Software Craftsmanship Group.  I couldn’t find a C# version, so I adapted the Java version that Uncle Bob posted back in 2005.  I’ve done a recording of me practicing the kata so that others can practice it.  I recorded it at a fairly high resolution (approximately 1920x1080) which means you’ll need to watch it on a screen around that size in order to make out the text in most cases… sorry, this is my first attempt at screen capture of a coding exercise… I’m sure I’ll get better with practice!

Enjoy!

Prime Factors Kata in C# from Mike Clement on Vimeo.