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.

Sunday, December 11, 2016

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.