On Monday of last week, our network and desktop support team (what we call our “IT Team” as distinct from our software development teams) began experimenting with Kanban as our project management framework.  Heretofore, we’d simply been handling our project management and priorities in a sort of ad-hoc fashion.  We knew we wanted to ratchet it down, but didn’t want to use Scrum since the IT team is more of a support organization that would not operate well using time boxes.  We decided to experiment with Kanban for multiple reasons, including its suitability for support organizations and its focus on lean principles.

Our first week of experimenting with Kanban went quite well.  The major benefit we saw was the visualization of our work and workflow.  On Monday, we held our first retrospective and identified the first major process issue we want to address: widening the ownership of the backlog to the entire team.  Up until now, I had generally been the one ultimately responsible for what we worked on and in what order.  Obviously, there was input from the rest of the team and other stakeholders but there was a sense that I was the gatekeeper for priorities.

Kanban has highlighted the inefficiencies in that arrangement and we’re now trying to actively discuss the backlog and new issues at least once a day in our daily meeting – if not more often throughout the day.  This is definitely going to be an ongoing improvement effort so I expect we’ll keep this as an action item for at least several weeks until we get to a point where we think the entire team has full ownership of the backlog.

Comments Off on IT Experimenting with Kanban
 | Posted by | Categories: Kanban |


19 March 2010

Today was the opening of AgileCoachCamp 2010 (#ACCNC) here in Durham.  So far, we’ve had a few rounds of lightning talks which were limited to 3 minutes and no slides as well as a lot of networking and generally good conversation.

In my lightning talk, I mentioned that I like to refer to our previous methodology (what we were doing prior to moving to Scrum) as “Waterhocking.”  I think it accurately captures the nature of our previous process.  It was definitely ad-hoc in so far as we weren’t following any particular project management framework and just handling things as they came up on a case-by-case basis.  It was similar to heavyweight “waterfall” methods in that we had extensive requirements gathering and documentation phases (BDUF), lengthy periods where the team would keep heads down and just try to build exactly what was documented, and too little user and acceptance testing too late.  Lastly, our releases often felt like we were hocking the product up since we were often under a fixed deadline and killing ourselves to get a product out the door only to find that the customer wasn’t happy with what was delivered.

Apparently, this label struck a chord with my fellow participants – it has a few mentions on twitter.  I’m definitely looking forward to tomorrow’s sessions; my only regret is that I can’t be in six or seven places at once.  There are so many really experienced, really insightful people here it is impossible not to miss great talks.

Comments Off on Waterhocking
 | Posted by | Categories: Software Development | Tagged: , |

Our company has been in the habit of doing periodic EPPs (Employee Performance Plans).  We’ve evolved from doing them once a quarter to once every four months to twice a year.  We’ve gradually lengthened the amount of time an EPP covers because of the overhead involved in putting them together and reviewing them.

When the Engineering department moved to Scrum, we obviously had to change the way we conceived of an EPP.  As usual, the problems we encountered weren’t caused by Scrum – just highlighted by it.

The main problem we encountered was “how can we say we’re planning on doing anything since we don’t set our own priorities?”  In the past, this didn’t seem like a problem because we just subtracted the amount of time needed to complete our EPP objectives from the amount of available time for “PM-sponsored” projects – or we built in the fact that we wouldn’t be working 100% of the time on those projects.  Either route is a problem because it reduces visibility into what the team’s priorities and capacity are.

Another problem was “how can we claim to be agile while putting together six month long personal plans?”

The latest problem we’ve encountered had to do with personal/career/team development, e.g., writing more unit tests, peer reviewing code, experimenting with peer programming, networking with peers outside the company, etc.

I feel like we’ve addressed all three problems fairly well.  Here’s how:

Regarding EPP projects, we realized that engineers making themselves personally responsible for entire projects was simply the wrong approach.  Granted, we wanted to get these projects (mostly technical debt reduction projects) done and granted they are important, but cutting out the rest of the team and the Product Owner is simply not the best way to accomplish them.

We realized that we should not be focusing on the whole project but simply that piece which is under our control.  Thus, we are now adopting EPP goals such as “Advocate for refactoring product X” – with objectives such as “educate Product Management about the costs and potential benefits” and “submit requested user stories and Definitions of Done to our Product Owner”.  In this way, we’re doing everything we can to see that these projects get done without sacrificing the prerogative of the PO to set priorities.  We’re also doing what only we can do: identify, explain, and plan to reduce technical debt or capitalize on new technologies.

Regarding the fact that we’re using six month EPPs, we are very explicit that EPPs – like all plans – should not be written in stone.  Thus, we’ve taken the approach of having quick, monthly reviews of our EPPs to see if there is anything we want to add, remove, or change given our evolving situation and knowledge.  These reviews sometimes only last five minutes; sometimes they last 30.  The point is that they don’t introduce much overhead and they allow us to course correct fairly frequently.

Regarding personal/career/team development goals, the problems we were running into regarded how to measure success.  If we had an EPP goal to “ensure unit tests are written,” what defines success?  What do we say at the end of six months if we didn’t write as many unit tests as we could have for the first month or two, then were pretty good for the rest of the period until the last week when we again may have missed some opportunities for tests?

We realized that we were not focusing on the real issue.  At the end of the period, we didn’t so much want a code coverage percentage as we wanted to be able to say that we had adopted or internalized certain practices.  That is, that we had developed certain habits.  Thus, at the end of the period, the question we ask ourselves is not “what is our code coverage like?” but rather “have we developed the habit of always writing unit tests?”  While this is more subjective, we feel it is still more valuable and it more accurately reflects what we actually want to do.


  • Plan to do those things where you add unique value – bearing in mind that no one person can tackle an entire project alone and, therefore, should not be solely responsible for that project.
  • Review the plan often, making changes as necessary.  The plan is not written in stone.
  • Don’t be seduced by “vanity metrics” like “how many units tests have I written per story?”  Rather, focus on those habits or practices that you want to develop or internalize and then judge yourself against how well you have become the engineer you want to be.
Comments Off on Scrum & Employee Performance Plans
 | Posted by | Categories: Business, Human Resources, Scrum, Software Development, Uncategorized |