2018-06-22

2018-06-22 Friday - Advice to a Development Team Struggling with Delivery & Defects

Recently I had a discussion with the CEO of a  .NET focused software development company - who was concerned with recurring delays in his development organization's ability to consistently meet agile sprint delivery schedules - and an attendant problem of unexpected defect rates in the code that was delivered.  

After our brief discussion, I suggested that - based on the symptoms he  described - my initial suggestion would be to ensure that the following three areas were not contributors  - and were well understood by the development teams . 

Possible Root Causes To Investigate (in the near-term):

1) Developers may not be adequately trained in agile practices and the language/tools they are using
  • Defects will tend to cluster around either specific persons and/or  specific code modules.  Root-cause analysis is essential to properly determine the appropriate mitigation actions, such as...
  • Use the 5-Whys of Six Sigma to determine the root cause for defects - often it may come down to a lack of knowledge/training - being tasked to do something outside their area of expertise - lack of awareness of good code design principles, etc.
  • For example (from my 2015 Seattle Code Camp talk, Diagnosing The Patient):
    • 1st: Why is the system slow?
      • The DB is slow
    • 2nd: Why is the database slow?
      • The app executes a lot of queries to load a page
    • 3rd: Why is the app designed to be so chatty?
      • DB was designed in an inefficient manner by [X]
    • 4th: Why didn’t [X] use an efficient DB design?
      • [X] was never trained on database design
    • 5th: Why didn’t [X] get any DB design training?
      • There is no budget for training
2) Developers may not be following Test Driven Design/Development (TDD) practices
  • This can be due to a number of possible causative factors:
    • Developers may be overwhelmed with unrealistic workloads squeezed into sprints
    • Developers may not be adequately trained/experienced to properly estimate Epics/Stories/Tasks - and therefore are simply racing as fast as they can to crank out the code for a given sprint
    • Developers may be writing trivial tests - and not focusing on the 20% that represents the `critical section` - first. 
3) Continuous Integration may not be in place (or taking advantage of all of its capabilities)


Uncle Bob Martin's book, Clean Code - is the foundation knowledge that is necessary for every developer to be successful:
https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882



He also teaches a 3-day workshop


No comments:

Copyright

© 2001-2021 International Technology Ventures, Inc., All Rights Reserved.