It's a Task-Board, not a Kanban-Board (and oftentimes that is fine)

In years gone by – in the high times of eXtreme Programming for example – people used to have task boards.

Along came Scrum and for a while we used to see Scrum boards all around.

Nowadays we see Kanban-Boards all around.

Or don't we?

Without the Kanban it's not a Kanban-Board

In virtual Kanban systems (and that is what we're talking about here) the “Kanban” is the difference between the capacity of a column (the WIP-Limit of the station) and the actual work in progress.
Even though the first step of the Kanban Method is simply to “visualize work” the very thing that gives the method it's name – the Kanban – can not be present in boards that don't have a WIP-Limit.

Kanban focuses on value to the user - not on tasks

It's fine if you conclude that you have to complete a couple of tasks to create a thing that is of value to the customer, but not necessarily the most “Kanban-like” way to approach the situation. If you take the approach to it's extremes you end up with all tasks being just columns on your board
And no I don't recommend building db-, ui-, and logic-silos. But if you have them, be honest and acknowledge the fact. Change it afterwards. Start with what you do now as they say in Kanban.

So while on a task-board cards typically contain things like "Implement the FizzBuz", "Install the FizzBuzz" or "Deploy the FizzBuzz to production" on a Kanban board you would just have a card (representing a system capability) "FizzBuzz functionality" that flows through the value stream.

Sometimes a Task-Board is enough

Implementing a Kanban system is a great thing (IMHO) - especially if you want to improve the way you work together (formerly called “the process”) in a scientific way, manage flow etc. But just omitting Sprint-Plannings reviews and retrospectives and putting cards in todo-doing-done columns doesn't mean your board has become a Kanban board. But it's still a good start.

Often Task-Boards evolve to Kanban-Boards

When you start with todo-doing-done you might find that your discussions around the ‘real’ status of the tasks help you finding out how you really work together. Don't be afraid to adjust your Board accordingly. And perhaps after a while you'll be able to switch from tasks that get pushed over the board to system capabilities that get pulled.

Be honest about where you are so that you can improve to where you want to be.

till next time
  Michael Mahlberg

Agile Documentation – a Reality Check

Working software over comprehensive documentation.

That's one of the value pairs a lot of people see (in the sense of really recognizing it) when they think about agile software development.

I don't want to re-iterate the simple fact that the manifesto just talks about valuing software over documentation and not instead. I also don't want to stress the old "While there is value in documentation we value working software more".
I don't even want to point out that the manifesto doesn't speak about all documentation, but only about comprehensive documentation.

Nowadays – where almost every software development effort is said to be "agile" – so many more questions arise.

"The code is the documentation" is sometimes true. Not so much if – for example – corporate standards enforce a development style that is far from SOLID. (You have heard about “corporate agile”, haven't you?)

"The tests are the documentation" is also sometimes true – but what part of the system do they describe?

Where is the business side?

To me, the currently worst idea in this context is the notion that user stories alone can describe the whole system. While there are many good approaches that contradict this notion (like user story mapping, impact mapping, product discovery etc.) there still is a lot of this mindset present in the wild. Especially when people use Jira and think that merely putting user stories in Jira tickets will leave the party who actually owns the product with a documentation that helps them in a year from now.

It does not. For one thing, often the level of abstraction is not suitable for everyone (how could it be – people work on different levels of abstraction). Another thing is that you can't describe a system by only listing the user stories without documenting the resulting decisions in some way. In this sense, having the user stories is necessary but not sufficient.

Think about creating a documentation around the other artifacts of your product as well. In an agile manner. When you create them. In a way that is lightweight, but strong.

And remember to refactor your documentation as well.

till next time
  Michael Mahlberg