Sumedha Ganjoo presented on common mistakes made when adopting Scrum. She discussed how having one person act as both the product owner and Scrum master leads to conflicts of interest and less accountability. Other mistakes include not properly estimating work, allowing technical debt to accumulate, focusing on documentation over working software, and customizing Scrum practices without understanding the reasons behind them. The presentation emphasized separating roles, setting clear expectations, prioritizing working software over documentation, and making incremental improvements based on team feedback and retrospectives.

1. AT11
Session
6/9/16 1:30 PM
Don't Make These Scrum Mistakes
Presented by:
Sumedha Ganjoo
National Instruments
Brought to you by:
350 Corporate Way, Suite 400, Orange Park, FL 32073
888---268---8770 ·· 904---278---0524 - info@techwell.com - http://www.techwell.com/

2. Sumedha Ganjoo
National Instruments
A certified ScrumMaster at National Instruments, Sumedha Ganjoo manages
multiple software projects in the Ops team that services a very large global
software development team. She was one of the people pioneering adoption of
Scrum in her current Ops team. Sumedha has worked as a software engineer and
project manager in various waterfall and agile projects including open-source and
university research projects, customer-facing, as well as internal industry
projects. In all her projects she has always been keen on driving and learning
more about process improvements. Sumedha is very passionate about promoting
better communication inside and outside of work, and she is an accomplished
Toastmaster.

3. Sumedha Ganjoo

4. Project manager in a chaotic project that goes agile

7. WHO AM I?
Product Owner?
Scrum Master?
Both?

8.  Waterfall
Team = x (Engineer) + Manager
 Agile
Team = y (Engineer) + Product Owner + Scrum Master
 Logical Conclusion
x = y + 1 Or
Manager = Product Owner + Scrum Master

9.  Conflict of interest
 Low accountability
 Less productive for the team

10.  Restructure team, if needed
 Separate PO and SM
 Clear responsibilities

13.  Understand the why
 Discuss and set right expectations
 Gross estimation techniques

14.  Inefficient
 Demotivating and stressful

17.  Inefficient
 Unexpected delays
 Potential impact on non-functional requirements
like quality and performance
 Unhappy team

18.  Measure,Track & Prioritize technical debt
 Agree on a way to do this

20.  Difficult to capture
 Difficult to measure
 Priority is delivery of a working software

21.  Inefficient
 Unhappy team and unhappy customers
 Unexpected delays

23.  Agreement on definition
 Use acceptance criteria
 Gather regular feedback
 Pay attention

26.  Miserable SM or/and PO
 Team unable to fully leverage Scrum
 Unhappy team

27.  Train the team
 Hire a consultant
 Scrum Master to drive internal Scrum adoption
and trainings
 Gather regular feedback

31.  One size does not fit all
 Different teams, projects have different situations
 Counter-productive

32.  Start with following the rules
 Slowly adapt
 Listen to your team
 Retrospectives

34. HACKING YOUR WORKFLOWS AROUND
AVAILABLE TOOLS?

35.  Company has a license for a tool
 Everyone else is using it
 Starting from the tool then defining the workflow

36.  Don’t be afraid to go low-tech
 Workflows over tools
 Look at alternatives
 Tools are information radiators and conversation
starters

38.  Agile bubbles up problems sooner and more
frequently
 More transparency

40.  Trust your team
 Get more information
 Good retrospectives
 Make small iterative improvements

42.  Opportunity to improve and adapt
 Unresolved issues cause unhappiness and distrust
 Unaddressed topics can reduce velocity

43.  Regular retrospectives
 Use tools and techniques
 Foster an environment of trust

44. LEARNING IS A PROCESS