Tuesday, November 4, 2008

Scrum | Detecting waste

Waste elimination is key to Lean. Nevertheless is the approach to detecting it completely different from traditional cost cutting techniques. The latter one detects waste by appointing certain persons or committees, who's job it is - yes you guessed it right - to detect waste.

An approach which will not uncover the true problems of an organization...

Lean is all about creating an environment that makes it easy to notice problems. If people are on the alert to detect problems, and the environment is created that makes it easy to notice problems, the supply of creative idea "seeds" will not run out.

Our job as Scrum Master or Lean Leaders is to help create that environment and inspire everyone to act, to take action, to make improvements.

Scrum already provides one key ingredient to continuous improvement by stating that at the end of every Sprint a retrospective should occur. Two things are important in the previous sentence. The first one is that there is a meeting, an environment, created where all team members can look back at what happened, what went well or would could have went better and last but not least that the intention of the meeting is to create action points to improve upon all things that could have went better, dividing them between things that can be solved by the team and those that fall under the jurisdiction of the company. Secondly you should notice that it clearly states that the meeting should be held after each Sprint, the fact that this is a rule, a standard will help in the process of detecting problems. The team will exactly know when to address their issues. Short iterations will only help in quickly exposing impediments.

One of the Lean principles I try to apply on projects is Kanban, the art of visualizing everything that is going one. A Scrum implementation of this is the Scrumboard and the burndown chart. But don't stop there:

  • get that full project burndown also up there

  • keep the result of each previous retrospective on the wall especially when it contains impediments that need to be solved by the team or organization

  • Don't waste too much time on making detailed UML driven technical design, grab a big paper, make some design sketches and put them up there

  • technical issues which don't belong on the product backlog can be kept as a separate Technical Backlog on the wall by adding each technical issue as a post-it on it

  • your application consists of a web front end than take a print of the screens hang them visible for everyone so that they can be discussed at any time, also having them around will make you get used to the screens and will help in detecting inconsistencies or improvements
I can go on for a while but you kinda get the picture. Get it up there, visualize it, so that everyone can start talking about it...

Labels: , ,

0 Comments:

Post a Comment

<< Home