Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Pearls For Improving Operational Efficiency

1,099 views

Published on

This was a presentation held at a Sprint Review after attending Clarus's Proffesional Scrum Master course hosted by Edwin Dando

Published in: Technology
  • 'A Struggling Team', 'A Thriving Team' are images Esther Derby created. Esther has many great resources around similar topics.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Be the first to like this

Pearls For Improving Operational Efficiency

  1. 1. Pearls For ImprovingOperational Efficiency
  2. 2. We are going to be introducing a socialcontract that deals with the relationshipsbetween each team member, andbetween the team and the organisation.
  3. 3. Scrum doesnt solve allyour problems.It just makes them visible.
  4. 4. Collocation• Research has shown that only 7% ofcommunication is the content of themessage• The rest is body language, voice tone,context
  5. 5. How often distributed teammembers communicate.
  6. 6. The effects of task switching
  7. 7. Most productive team size basedon extensive research and study.6+-3Paths of communication = n(n-1)/26 member team = 15 paths.7 member team = 21 paths.5 member team = 10 paths.
  8. 8. Technical debt• Comes from work that is not really "Done"• Has to be paid at some point, unless your plan includes bankruptcy• Hidden, undone work accumulates
  9. 9. Forms of Technical Debt• Defects• Lack of automated build• High code complexity• Lack of automated deployment• Lack of unit tests• Highly coupled code• Business Logic in the wrong places• Too few acceptance tests• High cyclomatic complexity• Duplicated code or modules• Unreadable / hard to read names or algorithms
  10. 10. Technical Debt is a Crisis in ourProfession• Customers or Stake holders believe they can demand something and it can be done• Developers willingly or unconscionably cut quality to support the belief• Results includeDevelopers and customers resent the profession,Failing products, failing companies, and hateful work.We are there now
  11. 11. How did we get here?• It takes 3-10 years for an organisation to back itself into this corner• Once in this corner, your competition can develop & deliver new functionality much faster than you• For every $ of competitive advantage gained by cutting quality, it costs $4 to restore it• Software is an organizational asset and decisions to cut quality must be made by executive management and reflected in the financial statements
  12. 12. Paying back technical debt 1.Stop creating debt 2.Make a small payment each and every Sprint
  13. 13. Team must solve their own problems• It’s the SM’s job to enable the team to do this.• Not to solve the problems for them.• (self managing)
  14. 14. What is the Sprint Review for?• This is the stake holders opportunity to provide input into what they see the most important work items are to be worked on next.• A collaborative working session, not just a demonstration.
  15. 15. Where we are
  16. 16. Where we are going
  17. 17. Scrum Roles Demo

×