Scrum addresses the software development where the requirements are frozen before the sprint starts, but what about the teams which work on dynamic requirements which can come at any time? For example in a team which works on technical tickets, these tickets may come at anytime and hence the sprint cannot be decided, estimation cannot be done and the velocity cannot be calculated. Kanban is the solution to all this. Started in Toyota, Japan this was introduced to increase the productivity of the factory. ‘KANBAN’ in Japenese, means a visual signal. Kanban was later used as an effective method in agile software development and it can be implemented in teams where requirements are not certain. The work items in this approach, are put on a board where each team members can access and update their work. The team can have a physical or virtual Kanban board. Colocated teams prefer to have a physical board. The basic function of the Kanban board is that the team can visualize thei
This article talks about the least important meeting in a Sprint, the retrospective meeting, at least as considered by the business and sometimes also by the developers. It is often considered to be a waste of time and given the least priority, and sometimes even omitted if there are time constraints. In fact it is the most important meeting but does not show any immediate business value. Talking about my own experience, we were newly into the project and the geek in the team was not getting enough technical tasks to devour, resulting in not so good documentations by him and his general disinterest in the team. This was discussed in the retrospective and his problem was faced, assessed and solved within a span of two weeks (a single Sprint), and he was given enough tasks to fulfill his coding appetite, resulting in better output by the entire team. Talking about retrospective techniques, the most effective way to conduct a retrospective is the Timeline Review. The team s