Challenges in Lean model

Release date becomes around the corner, each stakeholders in our project sat together to discuss the challenges we encountered during the development and the factors which affect our efficiency, productivity and quality. Recalled back, we learned a lot from the experience.

 

First, from developer perspective the biggest challenges are

1. Requirement is not as clear as before, sometimes it is only a piece of sentence.
   • Different from waterfall model, it is costly if there are many documents to maintenance. So communication is the key to make this model work. But not everybody feel flexible with communication
2. Requirement is changing.
   • The most valuable feature of Lean model is to adapt with change. Apparently, that brings challenge to developer to change its code based on the previous design.
3. Dependency is locked.
   • Mostly, one project is developed with the different teams simultaneously. Because each features even each functions are related. So each scrum team has to work together with others. But it is very limited when feature design is changed, which will effect to others as well.
   • Some features on the top of others, if thoes are not in the same team. The priority might not help in this case. Because in each team tasks' priorities are defined based on the different perspectives.
4. Priority is set incorrectly.
   • Developer's task priority might depend on the main workflow or the key features on the overview of the product. But tester's bug's priority might relay to its story sign off crietiria. Especailly near the end of release, some regression based on sign off-ed story bugs might be high for tester, but developer might focus on its new story's development.

Second, from qa perspective:

1. Iteration testing is costly.
2. Testing schedule could not be determined at the start, resource estimation is hard to make.
3. Mantenance the changes on testing is hard, regression occurs frequently, quality could not be predicted because some bugs hide others.
   • Solution, Unit test could be better, which could prevent lots of simple bugs, saving both ST and dev time.
   • Requirement change management tool should be professional, requirement and process management tool is not good/professional enough will cause changing of design is not transparent to tester, it is impossible only to depend on communication (including email, talk, meeting, conference call etc).
4. Time is tight for testing at the sprint end.
   • Testing time should be postponed one week compared to the development, rushing test could not promise quality.
5. Cross scrum team ST communication is not enough
   • When sprint testing is started, everyone is busy on testing and communicating to developers within scrum team, often ignore to communicate with cross scrum team testers. That will miss some integrated areas and also waste some overlapped areas.

Last, it's totally wrong if developer and qa think problems from the different perspectives. I think,

•  
  • If members always focus on his tasks instead of product quality, lean model will fail.
  • If the team members performance still depends on D-Task hours, the number of fixing bugs, and the number of finding bugs, the lean model will fail.
  • If developer still think testing is responsed by testers, and tests still think dev is responsible for code quality, the lean will fail.
  • If communication's purpose is still to point problems instead of fixing problems, the lean model will fail.
  • If there are still some process/report which is not valuable for development at all, the lean will be hard to be successful.
  • IF THERE IS NOT ANY ABOVE IF, THE LEAN MODEL WILL SUCCEED.