Kanban bubbles

Recently, a sunny day when my son and I went to the playground, there was a child blowing bubbles. The soap bubbles were flying higher and higher, sometimes they seemed to just hoover high up over the ground, suddenly take a dive and then back up in the air again. Both of us were fascinated.

"-Kanban bubbles."

I liked the sound of it. I guess there was some work issues processing in my head and the brain felt like combining work and play: Kanban bubbles.

At work, I am a part of a small team. We are about four team members working with software development, Kanban style. During the year we have changed stuff, improved things and experimented with tools like test driven development, pair and mob programming. We do, reflect and adjust.

We use a pretty standard way of visualizing our work, a Kanban board with swim lanes. In our agreed definition of done we have feedback (peer review) and exploratory testing as required activities after writing the code. One team member mostly gets to be the tester. The rest of us are mostly coders and peer reviewers. 

Our swim lane board doesn't really show that when all steps are passed, the release to production is done by the same team members that perform the first step. What goes around comes around. I tend to focus too much on the coding swim lane and too often miss what is happening at the right side of the board. Can our work be visualized in a different way?

Here is a suggestion, Kanban bubbles style.
The Whiteboard has two sections, the to-do area and the work in progress area. The to-do area is where we add stuff, prioritize and estimate. Important stuff at the top, not-so-important stuff at the bottom and we pick the most important stuff to work with.

Let's take a look at the work in progress area. In this drawing I have also added an imaginary circle.

Here I (sort of) have added our team definition of done steps and also tried to avoid those robotic terms that we usually see in Kanban and Scrum boards. After all, coders are humans, believe it or not.

In this picture one of the team members, let's call him Dave, has chosen something from the to-do area to work with. He moves the note to somewhere near Coding… word, draws a circle around it and a connector line to the word (make sure to only use those whiteboard pens, folks).

 

After some time the work in progress bubbles might look something like this.

What about limiting the work? By visualizing this way, there isn't very much space to add items, the actual (limited) space at the whiteboard is used for that. I think this way of visualizing probably is better suited for small teams.

The Kanban bubbles board is just an idea materialized from a moment of inspiration. Maybe our team will try this out in the real world, maybe not. The real world at the office is probably the only way to actually know if ideas are good or not. Or is it in the playground?

Hipster or neckbeard?

Man, that (asp.net) webforms thing really suck, doesn’t it? We should convert all our sites to mvc. For all the new stuff we’re about to develop, there is only one way: mvc. But wait a minute. I forgot to ask.

Why?

If you are developing stuff for the EPiServer CMS product, choosing between the two is a big thing these days. I think many EPiServer developers has felt left behind (myself included), being stuck with webforms when the rest of the world writes cool and awesome stuff with mvc and the frameworks that comes with it. I guess those poor SharePoint guys feel the same, don’t you think?

The times are different now. All of us can be cool these days (well, almost all of us. SharePoint will get there too some day).

Ok, so it’s about being cool?

Maybe. I would choose mvc because of one thing only: test driven development (tdd). Mvc is designed for that. Webforms isn’t. The rest is just style and preferences: design patterns, view engines, frameworks.

Is test driven development cool?

I think tdd is a great tool for helping you create both short term and long term value. The result will most likely be a product with nice and simple code. Nice & simple, as in easy to understand, maintain and refactor. Test driven development with webforms is mostly depressing. But hey, that is a different blog post.

Writing testable code, huh?

Well, I’m not really talking about just writing testable code. Don’t do that. Do test it & the code will follow. That's doing it the test driven way.

So who is the cool guy then, webforms or mvc?

I don’t know if anything used together with .NET and Visual Studio can be considered cool, really. We should probably check with @hipsterhacker or @neckbeardhacker about that. But don’t just settle with writing testable code with asp.net mvc. Without unit tests that proves it, the code base won’t probably be testable anyway.

So, without unit tests all that is left is choosing by style and preferences. Think about if that generates any value. Then make your decision on which way to go.

ps.

Check out my recent posts and videos on test driven development:

From the streets of test driven development: JavaScript

aspConf 2012 - Quick start: test driven development

ds.

From the streets of Test Driven Development: JavaScript

"... Let the unit testing drive your design. Write a unit test that specifies what should be done. Do a couple of variations if necessary, and then write the code that does the job. Switch back and forth between the unit tests and the code, refactor and clarify.

If you don't trust your code, write another unit test that provokes side effects. Do that until you feel confident. Then go home and have a good night sleep. ..."

Unknown
(Okay, it's me. I said that. I just thought it would be cool having a quote as an intro to this post)

Test driven JavaScript? 

Write a simple test, write a simple function. Done. 

That was the twitter version. What about the blog version? I think test driven development (TDD) is a good tool for helping you write code with high readability and a design with ease of use in mind (sometimes).

As a tool for testing (no matter what programming language you choose) TDD is overrated and quite often misunderstood. Probably because of the word Test in it, don't you think?

Before we start, I want you to don't care about stuff like code coverage, what frameworks to use and every line of code should have a corresponding unit test. That last thing is just nonsense. Think about the result, the code that actually will run in the production environment. The result is important. No matter how many nice unit tests there are, the result should be as simple as possible. Simple, as in easy to understand, maintain and refactor.

Simple is really difficult! I have failed with that many, many times (and still do, but never give up trying). What I have learned is that having a bunch of unit tests doesn't compensate for unnecessary complex production code. With or without unit tests, complicated code still sucks.

Also, don’t start the TDD journey by evaluating all those tools and worrying about continuous integration scenarios. Leave that for later. 

Do it the Agile way: experiment and learn.

"- Cool, I know unit testing already. I use that when writing C#. But TDD with JavaScript, how?"

If you come from a C# or Java background and already write unit tests (but have little experience of JavaScript) I think test driven development will help you understand and explore the language.

TDD has helped me to break free from the mindset chains of C# and Java style programming. JavaScript is not object oriented like in those languages. There are no classes, it is a language of functions and objects (and functions are objects). Objects can inherit from other objects and every object has a force field surrounding it (aka Closures) that is really powerful. Maybe we could call JavaScript the class less society? ...Because everyone has a function there.

Enough. (Want the basics? Check out my talk "Rediscover JavaScript" from dotNetConf.)

I have made a 15 minute video on how test driven development can be done with JavaScript and tried to write the code with simplicity in mind. I have avoided the common JavaScript language gotchas, like prototype inheritance and pseudo classes with the new or this keywords. In this video I use only one tool for unit testing (QUnit).

Take a look at the video and please share your thoughts about it!

direct link to the video on Youtube