David shambles up to the Kanban board. He moves a card from “Dev In Progress” to “Dev Done”. No emotion cracks his blank facade. There is no celebration of a job well done. No acknowledgement from others in the room. David glances briefly to his left and then pulls another card from “Ready for Dev” into “Dev In Progress” before shambling back to this desk. Another burst of coding begins. This little scene has occurred four times already this week, 19 times this month, and 271 times since David joined the project 15 months earlier. Is David just a machine in the Lean-Agile software factory? A mindless development automaton?

Relentless Development

For a start, I made David up. He is not a real person. But my question still stands. Does David represent a growing number of developers that are being crushed in a Lean-Agile treadmill? Certainly some people think so. They argue that Lean-Agile, Kanban in particular, turn developers into robotic code generators. Here are a couple of examples of this kind of accusation.

Dan Creswell (@dancres; 06 July 2014) tweeted:

One of the greatest sins of mass “agile” adoption has been the coercion of techies into mindless converters of requirements to code.

For a slightly longer variation, targeted specifically at Kanban, have a look at Brian de Haaff’s post Kanban — The Secret Engineer Killer. Brain talked to 150 companies using Kanban and found that “for nearly every company that’s adopted Kanban, there’s growing misery for product management first and engineering soon after”. Regarding the developers the problem, as Brian sees it, is that “Engineers want to build what matters, and Kanban buries them in incrementalism.” Ultimately this post is a call to “Stop the Kanban insanity” or more specifically, a call to stop using Kanban.

The continuous flow of Kanban is relentless. That can be exhausting. Mind numbing. De-humanising. It is this aspect that has attracted the criticism. Timeboxed Agile development also has a bit of relentless-ness with Sprint after Sprint after Sprint of development. Endless. For ever. With Kanban the relentlessness is more obvious because the tickets tend to be smaller, so there are more of them, and they move faster. With a big team it can feel like there is a flood of tickets heading towards live.

This relentless progress can lead to burn out – not just of the developers but of everybody. But I do believe that is not reason to abandon the method. It is cause for reflection and demands effort to avoid this particular outcome.

Visible development

Lets not forget that the Kanban Method is useful. As I said a moment ago, with a big team using the Kanban Method there will be a flood of tickets heading towards live. But think about that for a moment. I can see the flood of tickets being worked on by my team literally moving towards live. Now that is powerful. That is why I use Kanban.

Cards on a board reflecting the stages in the software development process. Really simple. Really powerful. This makes things visible. And visibility is good for everybody. We know where we are at and we know what we need to improve.

Mindful development

So how to stop turning “techies into mindless converters of requirements to code”? Personally I think developers are employed to convert requirements into code, the trick is to let them do this in a mindful way whilst still using the Kanban method for visibility.

What people miss is that a team’s software development approach can include the Kanban Method but is not, and can never be, Kanban. Personally I use a board and cards to manage tickets in a process – all looks rather Kanban-ish. However there is a lot in my process that is not covered by tickets, the board, or Kanban. The same should be true of all teams.

In some ways timeboxed Agile development guys dodge the relentless grind problem. Within a Sprint there is a rhythm with peaks and troughs – a heartbeat. Developers step away from their desks to do Sprint Planning, Sprint Review and the Retrospective. These are all opportunities to share and discuss with their peers. The Sprint Planning in particular is a chance to discuss technical design issues and approach. Some of that also comes up in Release Planning – often another all-hands team meeting about big chunks of functionality. Chances to share and to take a breather from coding. The moment after the release at the end of a Sprint is the best chance for a real breather. you’re between Sprints and can legitimately do anything you want – including just kicking back.

I think a good process, even using continuous flow, has those elements as well. These are chances to take a break and/or share. You just have to work harder because there is no explicit heartbeat. But there is nothing stopping, and every reason to, call appropriate meetings on an as needed basis. My current team uses the Three Amigos Meeting as a chance to discuss what is coming up. Unlike a Sprint Planning meeting it is on demand and about a single feature. But it is a chance for a break and sharing. We also do regular product reviews/demos and retrospectives – happen to be every two weeks. My guys don’t get the between Sprint breather. But they do get slack time if they are free and can’t either help with existing tickets or pull in a new one.

I also think it is important to bracket larger chunks of work. Got a three month long focus for the team, then you might need some addition ceremony / activity. Run a kick off meeting at the start to set the scene. Perhaps get developers involved in spike, prototypes, or proofs of concept for the work coming up. And have a celebration at the end, even if self-funded; this does use developers minds but does acknowledge they are people not machines.

I believe all this non-coding activity challenges Dan Creswell’s assertion.

References

Brian de Haaff. (2013, July 28). Kanban — The Secret Engineer Killer