43
W Pierre Neis let’s talk about Scrum 1

Let's talk about scrum

Embed Size (px)

DESCRIPTION

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

Citation preview

Page 1: Let's talk about scrum

W

Pierre Neis

let’s talk about Scrum

1

Page 2: Let's talk about scrum

W

questions from

management

2

Page 3: Let's talk about scrum

W

-Mireille

how to set up scrum methodology in a company?

3

Page 4: Let's talk about scrum

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

Page 5: Let's talk about scrum

W

-Mireille

which profiles are the more adapted to this methodology?

5

Page 6: Let's talk about scrum

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

Page 7: Let's talk about scrum

W

-Mireille

sharing of experiences which went well and wrong - root

causes?

7

Page 8: Let's talk about scrum

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

Page 9: Let's talk about scrum

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

Page 10: Let's talk about scrum

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

4

5

3

Potentially Shippable Increment

Product Backlog

Sprint Backlog Backlog Tasks

Sprint

Daily Scrum

W

Page 11: Let's talk about scrum

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

Page 12: Let's talk about scrum

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

Page 13: Let's talk about scrum

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

Page 14: Let's talk about scrum

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

Page 15: Let's talk about scrum

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

Page 16: Let's talk about scrum

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

Page 17: Let's talk about scrum

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

Page 18: Let's talk about scrum

W

-Allen

How is a sprint scope defined?

18

Page 19: Let's talk about scrum

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

Page 20: Let's talk about scrum

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

Page 21: Let's talk about scrum

W

-Allen

What happens to dropped scope items?

21

Page 22: Let's talk about scrum

: 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.

22W

next release next release

velocity

ideal burndown

Sprint Review

Sprint Review

Sprint Review

Sprint Review

Sprint Review

Sprint Review

Page 23: Let's talk about scrum

W

-Allen

How is the final product assembled from all the

pieces?

23

Page 24: Let's talk about scrum

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

Page 25: Let's talk about scrum

W

- Allen

Differences between a scrum master and a project

manager?

25

Page 26: Let's talk about scrum

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

Page 27: Let's talk about scrum

W

-Allen

Best ways to test in an agile environment?

27

Page 28: Let's talk about scrum

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

Page 29: Let's talk about scrum

W

-Allen

How to combine waterfall and scrum?

29

Page 30: Let's talk about scrum

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

Page 31: Let's talk about scrum

W

- Allen

Key controls of stages, given that stages are a little more

fuzzy now?

31

Page 32: Let's talk about scrum

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

Page 33: Let's talk about scrum

W

-Arnaud

With Scrum, do we reach our current objectives and how do

we measure them ?

33

Page 34: Let's talk about scrum

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

Page 35: Let's talk about scrum

W

- Arnaud

What could be a Continuous Improvement initiative with

Scrum ?

35

Page 36: Let's talk about scrum

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

Page 37: Let's talk about scrum

W

- Arnaud

How does work a Scrum development within an

Offshoring set-up with key stakeholders split on 2 sites?

37

Page 38: Let's talk about scrum

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

Page 39: Let's talk about scrum

W

- Meenakshi

« 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) »

39

Page 40: Let's talk about scrum

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

Page 41: Let's talk about scrum

W

- Meenakshi

« 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.  »

41

Page 42: Let's talk about scrum

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

Page 43: Let's talk about scrum

!

!

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.

!

!

[email protected]

43W