Jon Archer is a software professional with over 15 years experience who is lucky enough to work out of his mountain retreat high above Denver in the Colorado Rockies. He has worked as a software engineer with various technologies during the course of his career as well as a couple of diversions managing teams. These days he is the scrum master for a challengingly distributed team with members in Massachusetts, Colorado and Hyderabad India. He is a passionate believer in agile principles and is a key advocate thereof for his current employer Perceptive Informatics. He blogs at http://www.jonarcher.com/ and tweets as @9200feet Jon is a DZone MVB and is not an employee of DZone and has posted 19 posts at DZone. View Full User Profile
that anyone on a Scrum team might succumb to with the frustrations of
learning to work a new way. But this might be something the Scrum Master
could be especially tempted by. As guardian of Scrum principles it can
be frustrating sometimes to see people doing it "wrong." But it's
important to remember that people will often learn best by doing, by
earning the knowledge for themselves. Scrum is a huge cultural change
and requires patience as well as guidance. Besides, the basics of Scrum
are very simple and few things are truly wrong so long as you manage to
keep to them. Even then, sometimes letting people step outside the
framework for a bit so they can compare may help.
the stakeholders or the PO start to see
productive, reliable outputs from the team and take note of velocity it
may be tempting for them to ask the team to do more than
their historical accomplishments indicates is feasible. "Can't you just
squeeze in a few extra points?" This must be guarded against, because
allowing such a thing runs the risk of people cutting corners, or even
gaming things so it *appears* more points are being done per sprint by
falsely inflating estimates. Trust the team to work hard at a
professional standard and use velocity for what it was intended:
predictably planning what will be done by release time.
a large extent the whole-team emphasis on committing to a body of work
and getting it done by end of sprint coupled with daily stand-ups leaves
fewer places to hide for slackers than a waterfall team. Nonetheless,
calling out people not pulling their weight can be uncomfortable.
Traditionally a persons line manager would be responsible for this, but
in a self managing team there is the possibility of everyone holding
each other accountable for producing. Sloth harms the whole team and
cannot be ignored. Sometimes people need to be "voted off the island."
should always take pride in a job well done, but this should be a
shared thing. A scrum team thrives on respect for and collaboration with
each other. Ego-centric prima donnas have no place. It’s a team
thing. Similarly, whilst great talent is always appreciated, singling
out "rock stars" and putting them on a pedestal is counterproductive.
um. Usual dating people at the office advice stands methinks.
that other Scrum team may have their own team room/bigger
whiteboard/better computers/more interesting product... Whatever. Find
the interesting angle in what you’ve got, work to improve what needs
improving and stop coveting thy neighbor’s 27” dual monitor set up.
7. GluttonySprint planning can take a while. With inexperienced
teams I've seen it start with a late breakfast and run past lunch. Too
many bagels with lashings of cream cheese, Danish pastries and pizza
for lunch will catch up with you. Perhaps it's a good thing you will be
Published at DZone with permission of Jon Archer, author and DZone MVB. (source)
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)