Shifting from Scrum to Kanban

My team had been following (more or less) the Scrum process for two years. The Scrum rhythm of biweekly planning, demo, and retrospective with daily stand-ups served us well most of the time. However, we have since shifted to a process that looks more like Kanban. 

The Transition

We had the most friction with the Scrum process after initial releases when our focus turned more toward support and training of our customers. The two-week planning cycle does not accommodate this kind of reactive, responsive work. The dissonance between our stated process and the reality of the work day felt like a process breakdown even though what we were doing was clearly the most important thing for out team. It tended to make everyone a little cranky. Since agile is all about inspect and adapt and choosing a path that gets results, it was time for some adapting.

Our Flavor of Kanban

Unlike Scrum, which has identified creators and a set of doctrines that define orthodoxy, Kanban is more loosely defined. Our idea of Kanban starts with Scrum and and makes a few modifications.

We no longer plan a sprint. We simply pull stories from the backlog as we need more work to do. The VersionOne storyboard gives us a visual of how many items are in each status, and we only pull in a new story if the inventory level are low across the board.

Instead of planning for an entire day before a sprint, we now plan stories whenever the backlog of planned stories is low (less than a few days worth). We still demo the product and hold retrospectives every two weeks.

Since we no longer have sprint boundaries, we needed to make some changes to the way we integrate stories so that we always have a potentially shippable product. We now do all story or defect development on an activity branch in the repository and only merge back to the trunk after it has been thoroughly tested. This creates a bit of new overhead, but we’ve found it worth the effort.


Now we are able to be responsive to new items that come in. The development team feels less jerked around when support issues come in and priorities change. We’d all like to get back to pure product development, but better to face reality as it is than to pretend it is something it is not.

Peopleware: An Aging Classic

Peopleware: Productive Projects and TeamsSome months ago I was telling a friend at work how everyone in the software industry should read Peopleware by Tom DeMarco and Timothy Lister

I have always said that Peopleware should be required reading for anyone who manages software developers. I’ve also said that if you want to know my philosophy as a manager, just read Peopleware.

However, the first edition was written in 1987 and the second edition, which I had read, was written in 1999. I decided to read it again. I was curious to see how it holds up more than ten years later.

On second read, it is clear that Peopleware was written prior to the agile wave in software development. However, Peopleware was such a prescient work that in 2011 I still found it to be insightful and compelling. Much of what they call for has become more commonplace since 1999.

As DeMarko and Lister railed against public address systems in the office, I felt like I had taken a trip back in time. However, the principle that management too often optimizes the wrong factors in the workplace is as relevant as ever. I’ve seen too many situations where more care was put into color schemes and aesthetics than the mechanics of how the software team would work together (acoustics, workstation configuration, etc.).

The insights and anecdotes on management of software people made the second reading worth the investment. The chapters on building a high performing, jelled team were especially valuable.

Bottom line… I still believe that everyone in software should read Peopleware and that managers must read it.

Working with Recruiters

Where I work, we needed to add some capacity to our product development team. It was a short term need that could have turned into a long-term need if things go well. We were looking for a contract developer for a three to six month contract. Sounds easy enough, but there were some complicating factors:

  1. In order to help with the short term need, we had to get the person in pretty quickly.
  2. We’re didn’t have a lot of time to devote to recruit someone.
  3. Our current team is very effective.

The first two items are typical of any team needing to increase capacity. Item number three is where it gets interesting.

When I say that the current team is effective, I mean that we get a lot done, we enjoy the work, and we enjoy working together. We believe that the product and the codebase is getting better with each sprint.

I attribute this to core values we have as software developers:

agile: We believe in deferring decisions to the last responsible moment to keep our options open and to be able to adapt.

object oriented/domain driven: We start with the domain concepts and the object model and not the database. We’ve leveraged NHibernate on the server and object serialization on the device to eliminate buggy hand-coded SQL.

software craftsmanship: We view software as a craft to be mastered, not by learning a new technology like WCF or WPF, but by developing sound judgment and applying the basics like those expressed in the SOLID principles.

XP/Scrum: We embrace the engineering practices expressed in eXtreme Programming: collective code ownership, continuous integration, pair programming, and automated testing.

The developer we add to the team must already value these things or must adopt these values to work effectively. A developer arguing to implement a stored procedure on the next feature because it would be more efficient (whether right or wrong) would be counterproductive. Someone opposed to pairing on tasks would reduce the team’s energy and be a distraction.

The first problem is that it is difficult to communicate the values that make our team effective to a recruiter that doesn’t have the context.

Recruiters tend to fall back on what they know… more experience and greater sense of leadership is better. This leads to a paradoxical problem: the more experience a developer has and the more leadership he has shown, the more important it is that he (or she) be a fit for the team. Less experienced developers are 1) more moldable and 2) less responsible for their experience.

The Advantage of Inexperience

Less experienced developers tend to be more open to learning new skills and adopting new values. The good ones recognize that they have a lot to learn—both in techniques and what fundamental values lead to better software.

Less experienced developers also tend to have less control over the the technology and methods they use on the job. They often don’t know what to look for in accepting their first job or two and don’t have the influence to change the direction once they get there. So, I hold less experienced developers less responsible for their lack of experience with object oriented, domain driven technologies and insistence on agile methods.

The Burden of Experience

Developers with many years of experience tend to be the leaders within their teams and organizations. They are the ones who drive the technical decisions and shape the values of their organizations. Because of this, we have a higher expectation that these developers are experienced in the techniques we use and hold the values that we hold. If they don’t, it is mostly likely that their convictions are more settled and they are much less likely to change.

Communicating to Recruiters

Evidently, I was ineffective in communicating this idea to the recruiters who were helping us. Recruiters continued to send people to us touting ten years of SQL Server stored procedure experience or any combination of Microsoft technology TLAs. I don’t think they understood what I meant when I would said that a particular person had too much experience (of the wrong kind).

So, I brainstormed with the team and tried to spell it out with a diagram that looked like this:


I thought maybe the picture would do what the thousand words hadn’t. No such luck… I had to explain the chart to guys on the team; so, there was no way this would help the recruiters. Undaunted, I made one more attempt, this time with a simpler drawing:


I thought maybe this “magic quadrant” style graphic would work better, but consensus was that it still didn’t make it simple enough.

So, I gave up on the conceptual approach, and boiled it down to some questions, based on the years of programming experience the person has.

For developers with 1 to 4 years of experience, only one question:

Would you like to work on a agile team?

I went on to explain that we think a less experienced developer will adapt to our style of working if he/she is interested in learning the way we do things. We also think it will be very valuable and marketable experience.

For developers with 5+ years of experience:

What are the SOLID principles and why are they important?

What are three principles of Domain-Driven Design?

What does CQRS stand for?

What is your favorite ORM and why?

What CI tools have you used?

The candidate should be able to answer at least 3 of the 5 questions without hesitation. Someone without the experience we are looking for will probably not recognize the terms and won’t be able to answer them.

The idea was that an experienced developer who does not embrace the agile/DDD approach would not be familiar enough these terms that are peculiar to that world to answer the questions. The answers themselves are not that important (anyone does not use them won’t be able to interpret those answers, anyway), but familiarity with the terms indicates that we should talk to the person.

Because of some short-term issues, we put off the hire. I am hopeful to give this approach a try soon, though.

Reflecting on the Past… Looking to the Future…

I have just finished up my time at VersionOne and am a couple of weeks into my new position at Agentek. It was a tough decision to leave VersionOne. The company is well positioned to capture a large share of the growing agile project management tool market, there are a lot of talented people there, and I have a lot of friends there.

However, the opportunity at Agentek was too much to pass up. Here I will guide the development of the complete application stack on the .NET platform for desktops and handheld devices. The company is also early in its transition to agile methods.

While VersionOne is loaded with senior people and mature processes, Agentek is in the beginning stages of moving to the next level of maturity–both in terms of process as well as engineering practices. I’m stoked about the opportunity I have here to impact the overall success of the company.