Showing posts with label SCRUM. Show all posts
Showing posts with label SCRUM. Show all posts

Monday, March 4, 2013

Science- Fiction & scrum

I was thinking , lets adapt a famous science-fiction trope (cliche?) and see how it would fit scrum.

tell the scrum master that scrum is an impediment...
and watch him explode.


Wednesday, January 16, 2013

Daily Scrum

good article

roi vs risk in scrum

foundations believe its either / or . She doesn't.

SCRUM and Self Organization


It is a primal behavior in nature
–Swarms
–Flocks
–Herds

Scrum foundations slide 109

I feel the comparison is idiotic. By some animals it may be even genetic. This is not the intelligent way humans  
self-organize

The Retrospective Prime Directive


Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.
-Norm Kerth, Project Retrospectives: A Handbook for Team Reviews

If you do not go with such a mindset - then the retrospective will be painful and a waste of time.
Again , unfortunately if you have sub-par members on the team - they will have done their best and that still is not good enough.

Should the Product Owner Attend Retrospectives?



scrum foundations say yes. He says "maybe not always".

Scrum and Scope

some good points.

The Development Team


•May have partially allocated members
–Often considered an impediment
–Ex: Database Administrators, User Interface Design experts, Technical Writers

from the scrum foundation (85)

if they are too busy then the planning should reflect that - then they wont be an impediment
or you need to hire another DBA. I don't get this one.

Can A Product Owner Write a User Story?

why not? I'll disregard the scrum foundations on this (slide 84)

Monday, January 14, 2013

Variation in Velocity

My opinion is that even a large variation is OK once in a while (due to outside forces, a few people sick etc.) but constant variation is not -

also- do not tamper

The Scary Future After Scrum...

I hope it never gets here...

Burn Down Chart - public domain?

Wikipedia , that peerless source says that this is public. Scrum foundations slides say otherwise
here is a decent general article.

DOD & Bugs

DOD (definition of done)  shouldn't include "no known bugs". Every piece of software has bugs. I believe that the main criteria is as long the bug doesn't break basic functionality , its done

Principles behind the Agile Manifesto & SCRUM

Business people and developers must work
together daily throughout the project.


Officially this will not happen daily unless there is grooming every day 

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.


as mentioned before, if your team is not motivated SCRUM wont help

  Continuous attention to technical excellence 
and good design enhances agility.

this was thrown in to retain some sanity with Agile. unfortunately , there is nothing is Agile and especially SCRUM that pushes this, and frankly controverts it.

Another example, when SCRUM needs standard management

one premise of SCRUM is a functional team. What happens if you have a team member who is not up to par. Bringing this up in the retrospective wont do anything. You need standard management to come in and either do training or to remove the member.

Friday, January 11, 2013

Are stories and PBI's synonymous?

Microsoft seems to think so.

Story Points vs Hours

Good Post

also this

A scrum master who thinks he is a manager

is an issue and negates self-organization

Scrum master role

the scrum master is responsible to have impediments removed.

is this inherently part of the job? theoretically someone else could do this. But then that would impact the performance of the team. I guess if the job is to make sure scrum can work smoothly then removing impediments is part of the job.

scrum vs waterfall

If SCRUM's narrative is right - that the alternative is waterfall where by the time you get the software no one wants or needs it - how did any software projects ever get done in the past?