wireless systems lab project meetings - synerzip.com · scrum tenet 1: empiricism empiricism –...

Michael Hall

Three Beacons

[email protected]

214.783.3936

ScrumBut

Fundamental Tenets

Of Scrum

© www.synerzip.com / Three Beacons LLC, 2011 2

http://www.synerzip.com/

Scrum Tenet 1: Empiricism

Empiricism – Make decisions based on observation and

experimentation not theory, that is replace detailed up front planning

and processes by just in time cycles by inspect and adapt.

• Inspect & adapt

• Iterative development

• Reflect for improvement

• Just-in-time planning

• Plan one sprint at a time



Scrum Principle 2: Self Organization

Self Organization – Allow the team to self manage and be

autonomous, allow them to organize themselves around clear goals,

objectives and constraints.

• Team members figure out how

• Start with what you know right now

• Team level commitment

• Team members choose their tasks

• Quality governed by definition of done

• Trust

• Transparency



Scrum Principle 3: Collaboration

Collaboration – Collaborate with the team, do not manage or direct

them.

• Engaged customer

• Highly collaborative teams that commit

• Team is left alone during the sprint

• Committed (pigs) and interested (chickens)

• Teams are cross-functional

• Daily team synchronization

• Sprint progress tracked on sprint backlog /

burndown chart



Scrum Principle 4: Prioritization

Prioritization – Work on the most important thing first, that is the things

that add the most value, don’t waste time working on things that do

not add immediate value.

• Work items prioritized on a product

backlog

• Business value

• Risk mitigation – technical challenges

• Spikes to reduce uncertainty



Scrum Principle 5: Time Boxing

Time Boxing – Set time boxes and stick to them - do not extend them.

This creates the rhythm that everyone can work to.

• Fixed iteration length

• Consistent heartbeat of delivery

• Potentially shippable product increment

• Time-boxed project

• Sustainable pace

• Planning for sprint: 1 day

(Fixed)

(Typically

Fixed) (Variable)



Scrum Principle 6: Sashimi

Sashimi – Develop software in vertical slices, end to end. Do not

develop horizontally as this creates large integration issues near the

end of the project.

• Sashimi – functional slices, end-to-

end

• Demo deliverables at end of sprint

• Emergent architecture

• Emergent design



ScrumBut



What is ScrumBut?

ScrumBut is anything that goes against a fundamental tenet of Scrum.

• Not a laundry list of personal desires or complaints

• Generally described as “We do Scrum, but …”

• Changing Scrum so that a problem is no longer visible

• Also called ScrumBut “smells”

10

ScrumBut

© www.synerzip.com / Three Beacons LLC, 2011


ScrumBut - transparency

11 © www.synerzip.com / Three Beacons LLC, 2011


ScrumBut - definition

ScrumBut [skruhmbut] noun.

1. A person engaged in only partially Agile project management or development

methodologies

2. One who adopts only SOME tenets of the SCRUM methodology.

3. In general, one who uses the word “but” when answering the question “Do you do

SCRUM?”



ScrumBut - syntax

(Practice not followed) (Reason) (Workaround)

13

“We don’t do daily standups,

because we can’t afford the 15 minutes,

so we meet whenever we need to, usually once a week or so.



ScrumBut - analogy



ScrumBut - pervasiveness

16

• Most Scrum teams have some level of ScrumBut

• Likely that only 20% or less teams are “pure Scrum”

T or F: it is fine to remain here.



ScrumBut – so what?

• Is ScrumBut bad?

• Is ScrumBut a normal result of evolving?

• Is ScrumBut an acceptable result of slowly

introducing agile methods?

• Is ScrumBut another theoretical concept

with no practical application by people who

don’t develop software every day?

17

Scrum exposes organizational and behavioral challenges within the

development team and the organization, and these will have to change

in order to become more successful.



Nokia

ScrumBut Test



Question 1: Iterations

No iterations - 0

Iterations > 6 weeks - 1

Variable length < 6 weeks - 2

Fixed iteration length 6 weeks - 3

Fixed iteration length 5 weeks - 4

Fixed iteration 4 weeks or less – 10

Question 2: Testing

No dedicated QA - 0

Unit tested - 1

Feature tested - 5

Features tested as soon as completed - 7

Software passes acceptance testing - 8

Software is deployed – 10

Question 3: Specification

No requirements - 0

Big requirements documents - 1

Poor user stories - 4

Good requirements - 5

Good user stories - 7

Just enough, just in time specification - 8

Good user stories tied to specifications as

needed – 10

Question 4: Product Owner

No Product Owner - 0

Product Owner who doesn’t understand Scrum - 1

Product Owner who disrupts team - 2

Product Owner not involved with team - 2

Product owner with clear product backlog estimated by team

before Sprint Planning meeting - 5

Product owner with release road map with dates based on team

velocity - 8

Product owner who motivates team -10

Question 5: Product Backlog

No Product Backlog - 0

Multiple Product Backlogs - 1

Single Product Backlog - 3

Product Backlog clearly specified and prioritized by ROI before

Sprint Planning - 5

Product Owner has release plan based on Product Backlog - 7

Product Owner can measure ROI based on real revenue, cost

per story point, or other metrics – 10

Question 6: Estimates

Product Backlog not estimated - 0

Estimates not produced by team - 1

Estimates not produced by planning poker - 5

Estimates produced by planning poker by team - 8

Estimate error < 10% - 10

19

Nokia ScrumBut Test



Question 7: Burndown

No burndown chart - 0

Burndown chart not updated by team - 1

Burndown chart in hours/days not accounting for work in

progress - 2

Burndown chart only burns down when task in done - 4

Burndown only burns down when story is done - 5

Add 3 points if team knows velocity

Add 2 point if Product Owner release plan based on known

velocity

Question 8: Team Management/Disruption

External management disrupts team - 0

Product Owner disrupts team - 1

Product Owner or Scrum Master assigning tasks - 3

Scrum Team assigns tasks - 5

No outside disruptions, only Scrum roles – 10

Question 9: Build Automation

No build automation - 0

Continuous Integration build automated - 1

Nightly build automated - 3

Unit Tests run during nightly build - 5

Feature tests run during nightly build - 7

Deployment to other environments automated – 10

Question 10: Daily Scrum

No Daily Scrum meeting - 0

Daily Scrum meeting everyday - 1

Daily Scrum meeting same time, place - 3

Daily Scrum runs < 15 minutes - 5

Add 2 if reported Impediments are logged

Add 2 if tasks are directly updated during meeting

Add 1 if only Scrum Team are allowed to speak

20

Nokia ScrumBut Test


Add your scores up and divide by 10.

A score of 8.0 or higher indicates you are using an

“optimal level of Scrum”.


Gap analysis

- Identify the areas where your

score was less than the max

- Improve these areas by changing

culture, policies, organization, etc.

- Don’t change Scrum!

21

Nokia ScrumBut Test



ScrumBut

Examples



Is the following Scrum or ScrumBut?

• Sprints are planned for approximately 30 calendar days.

They can go 5 or 6 weeks depending on what happens.

Exercise: ScrumBut 1




• Iterations are always 3-weeks.





• A few scrum team members may get pulled out of a

sprint to do bug-fixing for another project.





• We like to let the managers and directors speak to the

team as part of the daily scrum.





• We just use Excel for our product backlog instead of a

tool.





• At company ABC, we feel that our sustainable pace is

50 hours/week.





• Standing is silly, so we do a sit-down daily scrum.





• Sometimes a developer in a sprint goes off on his/her

own and fixes some issues that have been long-

standing. We like to encourage this type of initiative.





• Our business analyst is our “product owner”. He/she

helps plan the upcoming sprint, but does not really help

the development team during the current sprint.





• Most if not all of our acceptance testing is done on the

last day or two of the sprint. This means we have no

time to react to feedback.





• We do release planning. Everyone knows that we would

never ship to a customer except as a planned release

several months down the road, so we don’t worry about

it until the time gets closer.





• We do release planning. This lets us fix the content of

each iteration leading up to the release.





• We track defects in a tool. They do not become part of

the product backlog. We work them in whenever we can.




ScrumBut

- Personal Experience



ScrumBut Smells

37

• Team members pulled at VP’s whim - Violates “team left alone during sprint”

• QA is separate organization and still requires a

handoff - Violates “teams are cross-functional”

• Team members cover for someone not performing - Violates “transparency / trust”

• QA sashimi tests run in subsequent sprint - Violates “potentially shippable product increment”

• QA not involved in user story development/review - Violates “teams are cross-functional”

• QA not involved in release/sprint planning - Violates “committed team”



• ScrumMaster assigns tasks - Violates “self-organization”

• No demos at end of sprint - Violates “inspect & adapt”

• Daily Scrums held only when necessary due to

overhead cost - Violates “daily team synchronization”

• Sprint cannot start until other groups do their job –

architecture, database, etc. - Violates “start with what you know”

• If the PO really wanted to ship early, we would need a

week or two to package the release for shipment - Violates “potentially shippable product increment”

ScrumBut Smells



• We do regression testing in subsequent sprints - Violates “potentially shippable product increment”

• We don’t use a definition of done - Violates “quality governed by definition of done”

• We don’t hold a Sprint Retrospective - Violates “inspect & adapt”

• Our sprints are miniature waterfalls - Violates “emergent design” and most Scrum tenets

• We don’t require developers to update the sprint backlog - Violates “sprint backlog updated”

• Our environment encourages individual performance over

team performance - Violates “team level commitment”

ScrumBut Smells



• Demos use stubs and placeholder software - Violates “potentially shippable product increment”

• Teams are pressured to over-commit - Violates “sustainable pace”

• We cherry-pick the parts of Scrum we like - Violates original intent of Scrum

• We have a planning week in between each sprint - Violates “sprint planning in 1 day”

• We hold retrospectives but we don’t emphasize their

findings - Violates “inspect & adapt”

ScrumBut Smells



Conclusion



ScrumBut - conclusion

42

• Most companies have some level of ScrumBut

• It’s not bad, but ……. it ……….

- is non-optimal

- can be inefficient

- can hurt your business

• Think of it this way ……. it is ……..

• An opportunity for improvement

• A way to get a leg up on your competition!

• Don’t just accept it – do something about it!



43

Think of ways in which your company uses Scrum. Ask yourself:

Q: is there any ScrumBut?

Q: what fundamental tenet does it violate?

Q: what can we do about it?


Exercise: Your Company


Good References



Questions?

www.synerzip.com

Hemant Elhence, [email protected]

469.322.0349

Agile Software Product Development Partner

45 © www.synerzip.com / www.threebeacons.com 2011

www.threebeacons.com

Short/Long term Agile coaching

Facilitated improvement

Agile Methods training: Scrum Team Training

Agile / Scrum

User Stories – Requirements w/ Agility

Product Owner Role

ScrumMaster Role

Etc.

All courses can be delivered onsite at your location

Michael Hall, [email protected]

214.783.3936

Synerzip in a Nut-shell

1. Software development partner for small/mid-sized technology companies

Exclusive focus on small/mid-sized technology companies

By definition, all Synerzip work is the IP of its respective clients

Deep experience in full SDLC – design, dev, QA/testing, deployment

Technology and industry domain agnostic

2. Dedicated team of high caliber software professionals Seamlessly extends client’s local team, offering full transparency

NOT just “staff augmentation”, but provide full mgmt support

3. Actually reduces risk of development/delivery Experienced team - uses appropriate level of engineering discipline

Practices Agile development – responsive, yet disciplined

4. Reduces cost – dual-shore team, 50% cost advantage

5. Offers long term flexibility – allows (facilitates) taking offshore team captive – aka “BOT” option


Synerzip Clients


http://www.itko.com/

http://www.yagnaiq.com/index.htm

http://www.clearorbit.com/index.php?sess_id=b0a39bdaf17f0f7c5cd34f8cc3d49d10

http://www.zafesoft.com/index.asp

http://www.hallsettlementsystems.com/Default.aspx

http://www.fd2s.com/home.php

http://www.repliqa.com/

http://www.broadlane.com/index.html

http://www.neofirma.com/Default.aspx

http://www.sevayatra.com/index.html

Thank You!

www.threebeacons.com

Michael Hall

[email protected]

214.783.3936

www.synerzip.com

Hemant Elhence

[email protected]

469.322.0349

Agile Software Product Development Partner

Call Us for a Free Consultation!


wireless systems lab project meetings - synerzip.com · scrum tenet 1: empiricism empiricism –...

Documents