Send the link below via email or IMCopy
Present to your audienceStart remote presentation
- Invited audience members will follow you as you navigate and present
- People invited to a presentation do not need a Prezi account
- This link expires 10 minutes after you close the presentation
- A maximum of 30 users can follow your presentation
- Learn more about this feature in our knowledge base article
Transcript of SCRUM but
SCRUM but ... ... can do 6-month sprints.
... doesn’t iterate. It’s right the first time, forever Sprint .... no burn-down chart. Around us everything is already burnt down Daily SCRUM Technical Debt Potentially shippable increment but... Sprint Planning Iteration Length but... The Team A ScrumBut has a particular syntax: We have Product Backlog, but... Few stakeholders dumping work to Product Backlog Product Owner ... not accountable for team results ... we communicate with her mostly via email ... she doesn't own Release Plan (when we're doing releases) ... velocity measured because we're told so ... programmers never do testing
... testers cannot ever code ... we mostly communicate with IM or email ... our manager tells us what to do and by when ... actually it even potentially not shippable ... our "done" some times not completely "done", because ... ... some technical guys / managers (outside the team) are judging our team, tell them what to do and when. Teams gives estimate to stories, but management demands commitment to date Hard precise deadlines defined by management up front w/o team involvement. Principles & Values:
Agile, Scrum, Team ... he does not prioritize the backlog. ... some people sits at the stand-up. (ScrumBut) (Reason) (Workaround) ... she does not have a vision, she assumes that it is clear what and why we doing what we doing. ... "Chuck" gives estimate first and always wins planning game Developers knows better what to do and why thus they follow priorities from PO time to time. ... we take to sprint more than we can deliver - to avoid our programmers running idle ... we are not sure about Sprint Plan after 2 days of planning... ... we cannot focus on our Sprint, because ... we have "talking chicken" ... we report to our managers to keep them up to date ... typically takes 30 minutes or more ... cannot split our stories because of their nature ...split stories by layers ... we adjusting sprint length to work in hands, every sprint. Sprint Review ... we are finishing what we promised but few people are working overtime and thus they have certain privileges in team ... story we are showing is not really "done", we will finish it just after the demo (or on weekend) ... we demo stories on our local environment, you cannot play with it because it is local. ... the only feedback we're getting is "Accepted" or "Not accepted" Retrospective "Elephant" problems Saying the same things, over and over on every retrospective
No actionable actions
"complaining" meeting / Blame Game Looking for Silver Bullet Only few people participating Everybody is always happy Answers come from leader business changing priorities daily in the Sprint References and Links Assessing Scrum http://www.soggyscrum.com/ ScrumBut: Nokia Test: http://antoine.vernois.net/scrumbut/ Comparative Agility http://comparativeagility.com/ http://slidesha.re/M0XyVd http://slidesha.re/Oi88Hf http://bit.ly/MX4Fxr http://bit.ly/Q9qQRQ Visualize + Manage Individuals and interactions
over processes and tools
Working software over
over contract negotiation
Responding to change
over following a plan Welcome changing requirements, even late in
development. Agile processes harness change for the customer's competitive advantage. Business people and developers must work
together daily throughout the project.
Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done. The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation. Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
Continuous attention to technical excellence
and good design enhances agility. The best architectures, requirements, and designs
emerge from self-organizing teams.
At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly. change Scrum not change ourselves but SCRUM Norris
does NOT replace thinking
does NOT limit your practices
Scrum is a tool Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale. Working software is the primary measure of progress. Simplicity--the art of maximizing the amount
of work not done--is essential. live Values & Principles = beware of Cargo Cult beware of false dichotomies and extreme relativism Scrum is making problems visible and requires you to change your behavior and way of thinking Scrum is NOT a Dogma Chuck Norris sits on the stand-up meeting.
Chuck Norris takes two baby-steps at once.
Chuck Norris ... Usually we want but but but but but but but