I'm fond of Lean Six Sigma and prefer Scrum as a software development methodology. However the two doesn't seem to be fit in most people's head. LSS is something for factories who perfect the same activity to the extreme while Scrum is for the creative folks developing new thing. Is it right?
A Scrum process looks roughly like this:
- Set up the high level backlog list of what to do
- Define a Sprint; a 30 days development stage
- Do the Sprint development
- Demonstrate results
- Do retrospective sprint analysis i.e. see what went well and what went wrong to improve
- Update backlog
- Go to point 2. till not finished
On the other hand Lean Six Sigma focuses on process optimization by removing all wastes and leaving only activities which delivery customer value. A key concept of Lean is the hidden factory; it contains all the work which have no added value (like rework, scrap, fixes...).
The Backlog can be easily aligned with Input, the Sprints with process steps (and the daily work with activities within the process step), the yield is the new functionality delivered. The number of Sprints is probably different in every project which is unusual from the Lean perspective but not impossible; here we deal with a flexible process. That is fully aligned; LSS concentrates on customer value and eliminates waste while Scrum prioritizes task and concentrates also on customer value.
The difficulty is that in Scrum the hidden factory is really hidden (at least for a LSS analysis); because the tasks vary by each Sprint no statistical analysis can be done. However it's possible that a module needs rework or has to be rewritten.
What if a company could easily build a integrated Scrum and Error database? There won't be much difference just the Error database would categorize errors by Backlog and Sprint task. (E.g. if a backlog contains a task called "Benefit calculation" and a corresponding spring task called "Upate Benefit the ticketing system could use these as category and sub category together with the software release number.) That is scrap detection, it depends on the test team and methodology how fast errors are discovered, however user errors should also be included. Scrum management software should also pay attention to tasks which are repeated Sprint after Sprint, and also see how well the team is able to estimate effort (and especially which tasks are problematic in this respect). Clever teams could also set up a list of basic functional categories (e.g. like report, parameter setting, update, printing, document sharing...; 10-20 categories covering the main features of their products) for each backlog task. Such a database would give an expert lot of valuable information (and good reports) how the development process can improve and what are the critical areas.
Naturally LSSS requires some discipline from the developers and their leaders, however that is true for all methodology. The added effort is minimal assuming there were a good tool available.
-
No comments:
Post a Comment