As necessary as support at a given point in time might be – it should always be the goal of management as well as developers to eliminate the need for support. Zero support should be the goal.

While half the staff are coding the other half of the programmers are working on the support desk. After 3 months it changes round and those who were on support desk are now coding. 

I think it allow the programmers first hand find out what the customer wants and needs are. They get to understand what their customers were trying to do and how they want to do it. 

It also gives them a period of time to think about the software and how they can go about moving it forward from an outside perspective.

Again its alright if you can afford to pay developer prices for support teams. On the other hand can you afford not too?

Nice post

If there are several fails in a row, then the situation needs to be addressed in order to return things back to normal. Allowing the project to reach a point where developers are walking over egg shells is not acceptable.

I doubt you´ll be able to come up with such user stories. Keep the user stories as they are. Cut them up into features. A feature representing some value to some user – but being linked to a specific interaction with the system, e.g. a mouse click or menu item. (User stories are usually made up of many such interactions.)

Features are of very different size. Some take several days to implement, some several weeks, well, only a few will require just a day. So here comes the challenge: Cut a feature into even thinner slices; but those feature slices are of the same size. Each feature slice can be implemented in just 1 day of team work.

With a whole feature before you maybe you´re just able to cut off a couple of slices and leave the rest as a chunk to be cut up further at a later time – if the user requests more feature slices of it to be implemented. That´s ok. That´s agile, too

Each feature slice delivers value to the customer/user. Sometimes it´s hard to imagine how to be able to cut a feature into such thin day long slices. But in my experience it´s possible in 95% of all cases. And it´s worth the effort. The point is: Any way the customer can give feedback on a feature slice is ok. If a feature slice is burried somewhere deep in the heart of some server side code, you can nevertheless make it tangible for the user. Just build a test bench for it.

Think of a TicTacToe game. The first feature to implement could be “check for winning constellation”. There need not be any user interface where a player places tokens on a game board. Just device a test bend for the checking code, which can be encapsulated in some library. Make the test bench available for the user and ask for feedback on just this single feature. Although this might be strange at first for the user, he´ll understand what to do and see the benefit of it.

We do Kanban, so iterations are not for us.