Meeting Minutes of Senior Management concerns about Scrum is a Global Distributed Organization

1. W
let’s talk about Scrum
Pierre Neis
1

2. W
questions
from
management
2

3. W
how to set up scrum
methodology in a company?
-Mireille
3

4. W
๏In an ideal world, we will start the implementation of Scrum on a project that could
answer all the usual questions a project asks to meet the business organization: to
deliver in a timely manner, delivering quality , have customers happy with the result, not
to generate unmanageable risks to the organization, to advance the maturity of
employees.
๏Once the first Scrum has fulfilled its purpose or that the delivered solution is complex or
that the product grows, the first Scrum team is split and several sub Scrum teams are
formed. Based on the experience gained from the first Scrum, the "developers" are
called upon to engage in one of the two roles of Scrum Master or Product Owner. The
Scrum Master and Product Owner of the first project can grow in maturity by
addressing a new approach to Scrum at the program management: coordination of
scrums, alingment, scrum-of-scrums, portfolio management.
๏One consequence of this is that the Scrum Master and Product Owner's of the
beginning will have all the necessary knowledge about the life cycle of the product.
4

5. W
which profiles are the more
adapted to this methodology?
-Mireille
5

6. W
๏Scrum requires 3 types of profiles: Scrum Master, Product Owner and Developers.
๏Developers are people having the necessary skills to enable the development of the
product.
๏Scrum Masters are facilitators. That means people having a sense of facilitation,
coordination, team building, coaching, keen to drive change. In a perfect « agile »
world, I would choose HR people.
๏Product Owners are « Product Managers » driving the product or the feature to
facilitate fast delivery of potentially shippable product increments. They are responsible
of the ROI and Time-to-market. If I were free to choose, nowadays I would choose
somebody with UX (user experience) knowledge.
๏Both Scrum Masters and Product Owners do not have technical skills. This is up to
Development Team with the support of external Technical Leads or Architect if needed.
6

7. W
sharing of experiences which
went well and wrong - root
causes?
-Mireille
7

8. W
: sharing of experiences which went well and wrong
๏ Changing paradigms!
๏ Misunderstanding of Scrum
basics!
๏ Scrum Master playing Project
Manager!
๏ Product Owner pushing the
Development team
8
๏ Management disrupting the
sprints!
๏ Lack of transparency!
๏ Wrong contracts!
๏ Follow the plan mindset!
๏ Expertise

9. W
: Changing paradigms
๏Rigid silo organization vs
Organization as a system.
๏Scrum as an agile model does
impact the traditional organization
structure.
๏Silo keepers (i.e. Managers) are
loosing power against a Product/
Project driven approach.
9
expected
paradigm
real
paradigm

10. W
: Misunderstanding of Scrum basics
๏ Like before, people want to test the
« cool » side of agility without taking
the « discipline » into account.
๏ Defining Scrum as a framework
gives people the feeling of doing it
with only small pieces of it: ex. calling
the Project Manager Scrum Master
doesn’t mean that you are doing
Scrum.
๏ Scrum is an empirical process.
10
1
2
3
4
5
Potentially
Shippable
Increment
Product Backlog
Sprint Backlog
Backlog Tasks
Sprint
Daily Scrum
W

11. W
: Scrum Master playing Project Manager
๏Keeping the old odd behavior and
rebranding it into Scrum doesn’t
mean you are doing it.
๏Having a Scrum Master pushing the
developers or dictating the
sequence of work is a huge
misunderstanding of the principles
of sel management and pull system.
11

12. W
: Product Owner pushing the Development team
๏ Same like before.
๏ The Product Owner pushing the
work to deliver in the order that
(s)he has defined in his/her plan.
๏ It’s almost a team decision.
12

13. W
: Management disrupting the sprints
๏ Some managers accepting
painfully the decision of adopting
Scrum dislike to share their
resources or at least losing them for
the project.
13

14. W
: Lack of transparency
๏ Transparency is scary. Show that all is well is
one thing, to show that everything is going wrong
is another. When your customer is internal pain
will be less strong if the customer is external.
๏ Transparency is at the heart of Scrum. If
something is hidden, it means it either does not
exist or that the information about it was handled
(non-compliance with rules and procedures,
breach of contract, etc ...), or that the
unconsciously we forgot to share this information.
๏ In the extreme, if you audit an agile project,
transparency is the first thing you are going to
measure.
๏ Identify areas disorders, opaque, priority risks
are there.
14

15. W
: Wrong contracts
๏ Contracts in scrum are an endless talk. There are so many nuances that no one finds the
path.
๏ If you keep in mind that the contract should be used to deliver better, faster with
motivated people you already have the basics.
๏ Statement-of-work (SOW) with "change request" is anti-agile. The changes are part of the
scrum approach. The "change requests" allows sellers to recover some of the margin
they lost during the dumping of the SOW. Here, both sides lose. The customer will not be
satisfied as a person, to see much of the team, ensure "change requests" detection for
over-charging. And, ultimately, the provider will be out of his pocket because, as its
resources were not dedicated to the project but of tracking "change", the project is
behind schedule and penalties in order. This is a LOOSE / LOOSE position.
๏ The SOW contracts with Sprint bonus: eg. if you deliver 100pts you have 100% of the
premium. This works for the Sprint one, but once you start the Sprint 2, the integration of
1 in 2 reduces the expected results.
๏ The big trend now is to sell Scrum contracts that the client understands and valid as
such. However, these contracts are linked with a large chunk of offshoring (80%) where
the client does not control anything.
15

16. W
: Follow the plan mindset
๏ The plan is an indication of the road ahead. If the plan becomes an obligation,
we are on a chaotic project management. Cognitive science tell us that to
ensure a predictable proper delivery, the plan should be simple and free of
complexity.
!
๏ Taking the example of the holidays. Planning your route and you think that you
will arrive in 6 hours for example. This hypothesis is based on the fact that you
are alone on the road. You can add a variability of 20% which is acceptable to
you. You take the road and after a few kilometers, there is an accident that
slowed traffic. You begin your buffer. And so on until that arrive late, exhausted.
!
๏ An alternative is to use a navigation system. Indications recalculate your time
of arrival and offer options to optimize your time. This solution is similar to
Scrum. Indeed, we know the start time, we know the direction and the system
gives us the options to optimize our route.
!
๏ We call this planning and not blindly follow the plan.
16

17. W
: Expertise
๏ Expertise is it really a benefit to the project?
!
๏ Companies hire experts because they are afraid or lost.
!
๏ Experts can help to unblock the situation promptly.
!
๏ If, as I could see it a few time ago, the team consists of experts, they do not
communicate with each other but focus in their area of expertise. The principle of self-management
in scrum teams and group dynamics of the development team requires
breaking silos (expertise) to search for collective investment in the delivery of the project.
!
๏ Since 2012, the Scrum Guide states that members of the development team are called
developers as well as they are not developers. What for? For example, if a test is needed
to ensure the goal of sprint and our architect is available, it will help to advance the test
team and especially not stay in his area to consume valuable time dedicated to sprint.
!
๏ An expert is considered a "floater" it comes on time and never permanently.
!
๏ That is why the scrum teams are considered cross-functional.
17

18. W
How is a sprint scope
defined?
-Allen
18

19. W
: Sprint scope means Sprint Backlog
๏The Sprint Backlog is a chunk of the Product Backlog ready to
be developed by the Development team during the Sprint time
box.
๏The Process:
๏ at Sprint Planning, the Product Owner propose a subset of
the Product Backlog based on following criteria:
๏ Identifies a Sprint Goal
๏ Product Owner decompose high priority Product backlog
items to an appropriate level of granularity
๏ (s)he defines « Done » in collaboration with the Team
๏ Number & granularity depends on velocity and Sprint
length
๏ The smaller the requirements and the more similar their
size is, the higher the velocity tends to be
19

20. W
Sprint Planning - Summary
20
Objective:
Realistic Goals
Commitment
Self organization
䡦 Attendees:!
䡦 The Scrum Team
Input:!
High priority P/B inputs!
Add-ons!
Process:!
Goals and Tasks
Activities and Commitments

21. W
What happens to dropped
scope items?
-Allen
21

22. : what happens to dropped scope items
๏ The principle we use in Scrum is the
burndown of the backlog which allows
discussion among project stakeholders
during the reviews. The « dropped scope »
items can take two directions:
๏ they are out of the sprint backlog and return to
the product backlog for future development in
the same or in a future Release
๏ they simply disappear because they do not
bring any value to product development.
!
๏ Management of these items is under
Product Owner’s responsibility.
22
W
next release next release
velocity
ideal burndown
Sprint
Review
Sprint
Review
Sprint
Review
Sprint
Review
Sprint
Review
Sprint
Review

23. W
How is the final product
assembled from all the
pieces?
-Allen
23

24. W
๏ The purpose of Scrum is to deliver potentially shippable product
increment. This means that all the pieces of the product should be
assembled at the end of the Sprint.
๏ Sometimes this is more complicated because of several features or
lines, but still keep in mind that everything should be assembled at
the end of the sprint. If not, you need to improve the product
development lifecycle and prioritize the product backlog according
emerging dependencies.
24

25. W
Differences between a scrum
master and a project
manager?
- Allen
25

26. W
๏ If you understand Scrum, you can discover that the central role of Project Manager doesn't exist anymore.
This role is fully distributed within the Scrum Team (Product Owner, Scrum Master and Development Team).
๏ Project Management Institute describes that a project is based on two parts: the product and the process.
๏ In Scrum, we have a role for both parts. The Product Owner is managing the Product Development and
track the time-to-market and ROI of the Development. The Scrum Master, who works in pair with the
Product Owner, is responsible for the Process (Scrum) and manages Capacity and Risk.
๏ The Development team is in charge with engineering and quality.
๏ We discover that Scrum enabled project management maturity because all skills are distributed within the
Scrum team.
๏ One point of attention: in Scrum, the team is fully dedicated to the project. This means if a team member
has to jump in another project during the sprint and jump back later this is counter productive. So here,
capacity management doesn't mean allocation of resource cross-over the project backlog, but measuring
member availability.
26

27. W
Best ways to test in an agile
environment?
-Allen
27

28. W
๏ Take a look of your development if you are testing after the development. What
happens? Tester are losing a lot of time and developers should stay available to fix
defects. In other words, the development hasn't really stopped at the due date.
๏ The challenge in agile development is to make development and testing in parallel.
๏ How to test in agile depends of your development strategy and of the size of your team.
๏ For a small team. testing will be integrated as a part of the development process from
Unit test to integration.
๏ For larger programs, perhaps you need to have an integration team working in parallel
with other developments teams. This team integrates the increments of each team and
test it. One strategy is that this team starts one sprint after development sprints so that,
in the case of refactoring, the development teams do not loose the knowledge of the
past sprint to fix the debt.
28

29. W
How to combine waterfall and
scrum?
-Allen
29

30. W
๏ Scrum and waterfall sounds a bit like mixing oil and water. It's almost a
point of strategy.
๏ If you have a large program where managers, steering committee,
sponsoring have no agile background, you can keep a sound of waterfall to
not over-stress them. At this level, you can fix a project charter, a
governance, a roadmap and quality gates.
๏ If you take a look at a sprint, you will find sequencing waterfall like
approaches. This not against scrum if it's team decision.
๏ The real problem is not waterfall but the "cost of delay" in waterfall i.e. if
waterfall supports the empirical approach and the agile culture, then you
can use it.
30

31. W
Key controls of stages, given
that stages are a little more
fuzzy now?
- Allen
31

32. W
๏Regarding key controls of stages we try to keep it simple and visible in Scrum.
๏At Sprint stage, I expect to see
๏ the Product Burndown, which visualize the amount of the work left until we reach our release
๏ the Velocity, which are the done items within the sprint. That helps the Product Owner to forecast
when we were done in the Release or what features will be done in the fixed Release
๏ the Impediment Backlog is a great tool highlighting impediments and emerging risks. This
backlog improves the capacity of the team and foster management to take actions if the
impediments are wider than the team.
๏Additional actionable controls are interesting for large program where we use Cost-
Performance-Index and Schedule-Performance-Index from early EVM.
๏Adding KPIs is adding discussions. We are looking for metrics helping to take decisions.
32

33. W
With Scrum, do we reach our
current objectives and how do
we measure them ?
-Arnaud
33

34. W
๏With Scrum we reach mostly our current objectives when these objectives are clear
since the beginning. If the vision, scope and the Definition-of-Done of the project
haven't been clearly defined (at high level) and management is expecting that their
answers will emerging from team work, then we will make a lucky guess that we reach
something unknown.
๏In other hand, like I described before, you start a Scrum with an initial Backlog that
should burn down. That's a first indicator.
๏At the end of the Sprint, we have the Sprint Review which is not only a demo but more
the inspect-and-adapt of the stakeholders. Here during the meeting, the Product Owner
will accept done items and reject un-done.
๏To ensure that all objectives are met, we use "Definition-of-Done" and "Definition-of-
Ready" according the necessary different levels of Done needed. That's the job of the
Product Owner, on a daily basis.
34

35. W
What could be a Continuous
Improvement initiative with
Scrum ?
- Arnaud
35

36. W
๏ Continuous improvement is the core of Scrum that why we call Scrum an
empirical development process.
๏ At the end of each Sprint, the Scrum Team has a Retrospective where the
members are reflecting on the lessons learned and how they can improve their
work. The outcome of this meeting will be performed in the next sprint.
๏ The whole scrum is based on Continuous improvement:
๏ daily scrums are the inspect-and-adapt of Scrum Team
๏ Sprint Review are the inspect-and-adapt of the stakeholders
๏ the Retrospective
๏ Sprint Planning use the outcome of these improvements for the next iteration.
36

37. W
How does work a Scrum
development within an
Offshoring set-up with key
stakeholders split on 2 sites?
- Arnaud
37

38. W
๏ Scrum can very helpful in offshoring. Several points should always
be taken into account:
๏ collocated scrum team
๏ easy communication
๏ Collocated Scrum Team means that Product Owner and Scrum
Master should seat within the team. Synchronization meetings can
be easily followed helps communication devices.
๏ The big mistakes are having Scrum Masters and Product Owners
on-site with offshore development. Be sure that your team doesn't
follow the scrum.
38

39. W
« Close proximity to the business/project
stakeholders is one of the key success factors
in scrum approach. How does this practically
work out in a distributed scrum model (onsite
offshore -> global delivery model) »
- Meenakshi
39

40. W
๏In practice, in Scrum we have planned meetings where business is involved or
asked to join like Sprint Planning and Sprint Review. Sprint Review is mandatory,
because it's the only time where business can officially met the development team.
๏All along the sprint, the Product Owner still works with the business to prioritize
product backlog items or to discuss about expected outcomes or release strategy.
๏This is true for on-site but also for offshore or global delivery model. There should
be no difference.
๏For Global Delivery Model, you can find a group of Product Owners staying
connected with the business.
๏At last, the project or program governance has to fix dedicated meetings to get
early business commitment.
40

41. W
« Change management is key when introducing/running scrum
based projects while an organization is largely used to traditional
SDLC models. Moreover it's not only the IT team that participates
in the scrum based deliveries or sprints but key is the other
stakeholders from business, infra etc as well need to be
committed and involved. How do we enable this in an
organization that is widely used to the traditional SDLC models. »
- Meenakshi
41

42. W
๏The SDLC model provides a traditional waterfall approach. Agile and i.e. Scrum is challenging the old system because of
increasing delivery speed.
๏This question has a large scope and implications a new kind of organizational approach.
๏Nowadays, in the agile community we are testing new concept like LESS, DAD and SAFe were the development is pulled by
integration. The main ideas came from DevOps which take into consideration that "potentially shippable" means "deliverable". This
is for a the bird view.
๏In my experience, I worked for a Global 24/7 company using Scrum and we used this process:
๏ the Europe based Scrum Team worked during the european working time frame
๏ afternoon, the US "child" team under takes actual work and add new work from the common Sprint Backlog
๏ during the night, testers from Beijing are roll-out all tests
๏ next day the Europe team can either work on new items or refactor
๏Infrastructure people were part of the development teams, QA either.
๏Scrum meetings were planned to have all stakeholders attending online recorded sessions.
๏Regarding business, QA, UX, Infrastructure or Architecture discussion, several "streams" or "tribes" have been set up for guidance.
42

43. !
!
The evidence we have provided are mainly
standards that we experienced with one
hundred + Scrum teams in the past.
Although we believe that they can bring you
specific help on your adoption of Scrum, as
Agilists, our focus is to meet your expectations.
Feel free to submit your acceptance criteria.
!
!
pneis@wemanity.com
43
W