1. Transforming the World of Work? Or Confusing It?
Angela Johnson, PMP, PMI-ACP, CST
Certified Scrum Trainer & Agile Transformation Coach
@AgileAngela
#REALCHANGE

2. Angela Johnson
PMP, PMI-ACP, CST
21+ years Information Technology with traditional SDLC and Scrum/Agile
Scrum Alliance:
Trainer Approval Committee (TAC)
Certified Agile Leadership (CAL) Team
Volunteer Facilitator PMI-MN Agile Practitioner Community
Based in Minneapolis, MN 2
Copyright 2016 Collaborative Leadership Team

3. Why Agile? 3
Copyright 2016 Collaborative Leadership Team

4. 2015 VersionOne State of Agile Survey
Why Agile?
2015 VersionOne State of Agile Survey 4
Copyright 2016 Collaborative Leadership Team

5. The Definition of Insanity5
Copyright 2016 Collaborative Leadership Team

6. The Definition of Insanity
Scrum has been in existence since the early 1990s
“Agile” came into being as a result of the Agile Manifesto created in August, 2001
These ideas are not new and yes can bring about faster delivery, increased quality, reduced costs, increased team morale…
If used as directed
When organizations simply use Agile or Scrum vocabulary but do not actually change how work is done – there is little chance in achieving any of these 6
Copyright 2016 Collaborative Leadership Team

7. Fundamental Differences7
Copyright 2016 Collaborative Leadership Team

8. Fundamental Differences
Agile processes commit here
Traditional processes commit here
McConnell 1997: Software Project Survival Guide 8
Copyright 2016 Collaborative Leadership Team

9. Fundamental Differences
Agile approaches such as Scrum do not seek to “assign” people to projects temporarily
People are identified that are needed to build the product and dedicated 100% to that effort
A Product Owner and ScrumMaster can be identified when an organization is still determining whether or not to pursue an idea or not – which leaves people free to keep focused on committed work
These higher levels of planning do occur in organizations – an empowered, proactive P.O. is involved in them 9
Copyright 2016 Collaborative Leadership Team

10. Fundamental Differences
Source: Dynamic System Development Method (DSDM or RAD) 10
Copyright 2016 Collaborative Leadership Team

11. Fundamental Differences
The product paradigm seeks to find out how much the organization is willing to invest
Unlike the project process, this is not finite
This can be an ongoing, iterative process – delivering highest valued items first and responding to customer feedback with subsequent releases
Organizations may call this build vs. buy, business case, cost benefit analysis, etc.
Most widely adopted Agile planning frameworks refers to these activities as Vision and Roadmap 11
Copyright 2016 Collaborative Leadership Team

12. Fundamental Differences
Planning is not a once and done activity in any Agile approach
It is a progressive elaboration
Development Teams are engaged once the Product Owner has been given the green light to begin work
In organizations where there is an understanding that work will be done differently via an iterative process, sprinting begins immediately
Organizations that do not understand that Agile means doing work differently continue to waste time and money with big, up front planning 12
Copyright 2016 Collaborative Leadership Team

13. “People make up Sprint Zero because they plan on delivering Zero value” Jeff Sutherland, co-creator of Scrum 13
Copyright 2016 Collaborative Leadership Team

14. “The new goal for the organization must be to delight the customer.”
The Customer is Key
“The new goal for the organization must be to delight the customer.”
“Making money” is not the goal
“Being agile” is not the goal.
“Working software” is not the goal
Agile, Scrum & working software are means to achieving the goal 14
Copyright 2016 Collaborative Leadership Team

15. Start with Vision Visions do not need to be lengthy
Visions also do not seek to solution prematurely, but rather to articulate the problem that is going to be solved
These are conversations led by the Product Owner in a Scrum adoption
Start with why
Who is the product for?
What are their needs? 15
Copyright 2016 Collaborative Leadership Team

16. How Much will we Spend?
Roadmap is the generic term used to refer to the Product Owner being provided with funds to spend towards realizing the Vision
Ideas may be drilled down upon a bit further in these conversations as well as looking at market data, customer feedback, competitive analysis, etc.
All still activities for a Product Owner – not a Development Team
A P.O. could use a good coach and active facilitator which is why ScrumMasters are also identified early on along with Product Owners in any successful Scrum adoption 16
Copyright 2016 Collaborative Leadership Team

17. Are we Ready to Start?
A P.O. should have enough of a Product Backlog pulled together and ordered by business value for a Development Team to get started
If they need assistance in pulling Product Backlog Items for the Product together, be cautious of trying to do that with the Development Team as a first step
Development Teams are problem solvers
They will “solution” too soon – negating the opportunity for users or customers to weigh in 17
Copyright 2016 Collaborative Leadership Team

18. Are we Ready to Start?
A better way to create an initial Product Backlog is for the Product Owner to invite users or customers to participate
The ScrumMaster can actively facilitate the creation and discussion of initial Product Backlog Items
The next step would be to take it to the Development Team that has been identified to do the work
Further refinement will take place with the Development Team prior to Sprint Planning 18
Copyright 2016 Collaborative Leadership Team

19. Refinement is an Ongoing Activity19
Copyright 2016 Collaborative Leadership Team

20. Refinement is an Ongoing Activity
Planning in Agile approaches is like peeling the layers of an onion back
It is not a once and done or big, up-front activity that is locked down
The lack of an empowered, proactive Product Owner is a common reason most Scrum adoptions fail
The Product Owner owns refinement at all stages and takes it to the Development Team for further refinement when ready 20
Copyright 2016 Collaborative Leadership Team

21. Case Studies 21
Copyright 2016 Collaborative Leadership Team

22. Case Study #1 Privately held insurance company
Organization asked people to adopt Scrum to do work but tried to forced traditional project management planning to initiate
At the instruction of a vendor who said they used “Agile” to do work but that requirements needed to be flushed out to begin
Once leadership admitted there was a limited amount for funding and understood this would be the constraint along with the timeline work began quickly – understanding the iterative nature of scope 22
Copyright 2016 Collaborative Leadership Team

23. Case Study #1
Identified, empowered Product Owner with a Vision and Roadmap
Minimum Viable Product idea funded for Q2
Product Backlog creation, refinement with stakeholders, users and SMEs accomplished in one day
Development Team identified, agreed upon sizing method and further refined enough P.B.I.s to get started in one day
Initial sprint began on 3rd day 23
Copyright 2016 Collaborative Leadership Team

24. Case Study #2
Organization paid a vendor $84,000 for a “Sprint Zero” – vendor claimed to “use Scrum”
As soon as work began, change inevitably occurred since more was learned about the work
The vendor considered these “changed requests” and insisted on more money
The company fired the vendor for manufacturing change requests and falsely advertising that they understood Scrum 24
Copyright 2016 Collaborative Leadership Team

25. Wrapping Up: Avoid the Confusion
Understand the goal for changing the way work is done
Understand the organization’s commitment (or not) to changing the way they do work
Invest in education – it’s hard to execute something that is not understood
Invest in good coaching – how many Olympic medalists had no coach
Beware of anti-patterns – ideas that seem like a good idea but in reality preserve traditional ways of work that prevent delivering value faster 25
Copyright 2016 Collaborative Leadership Team

26. Wrap-Up 26
Copyright 2016 Collaborative Leadership Team