Startup of a Lean IT SCRUM team - part 2

As I wrote over half a year ago in part one of this history of the way I implemented SCRUM in a two-man IT team; it was working, but just not good enough. Here is part two to see what we found and improved upon.

We found the colors and even the magnets designating every story to one of us did not prevent too many items from being on one person at any one day so we borrowed a little from KAN-BAN and limited our workload visually.

We changed the whiteboard we already had for the SCRUM sprint. Dividing the board into 2 horizontal lanes (or 3 when an intern was part of the team) and on the vertical 6 columns. One for the backlog (unplanned items for future sprints) and one for each workday of the weekly "sprint" was enough to get going. A little area on the bottom right-hand side for unplanned stories finished the board.

This iteration worked much better. We had to choose what story went in what slot on each day and who had to do it. If we predicted a story would take 2 days we stick it on the divider between days. Stories that took longer were split up in true SCRUM fashion.

That concludes my short history of two years of starting with a new idea for streamlining our chaotic way of working ad-hoc to a whole new process which was more rewarding to us and our customers. The last year before the team was disbanded because of outside influences we had clear goals, a visual guide to obtain them and lot more relaxed way of handling things. Which helped us to get better results and sometimes even faster ready-to-go deliverables than in the olden days.

Having written all the good things about this, please heed my warning. Don't use the described processes as-is at home or at a workplace near you. If anything the main takeaway is: Take what you think might work from LEAN/SCRUM and KAN-BAN and experiment. Incorporate new ideas to test them and evaluate at regular intervals. Throw away what fails and keep what works.

Also I have found the commitment of the team will be directly related to the control they have over their own way of working while improving on quality. So let in the critique on the existing processes and let every team member have a say to strengthen the idea they are improving together.

As most SCRUM masters would agree with me this proves the feedback loop is the most important part of any time-boxed based process. Try this and be amazed.