Largest impediments you have encountered
andrej...@gmail.com
Scrum in your experience?
Mine:
- Story points and relative estimation
- automated testing
- developers do no testing
Gustavo Cebrian Garcia
Those have been my biggest problems with any project.
Could you explain better what you mean with "Relative estimation"?
--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To post to this group, send email to scruma...@googlegroups.com.
To unsubscribe from this group, send email to scrumallianc...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scrumalliance?hl=en.
andrej...@gmail.com
hours and minutes :)
Andrej
www.agilemindstorm.com
On Jul 20, 12:17 pm, Gustavo Cebrian Garcia
> Goog thread,
>
> Those have been my biggest problems with any project.
>
> Could you explain better what you mean with "Relative estimation"?
>
>
>
>
> > I am curious what are the largest impediments you encountered using
> > Scrum in your experience?
>
> > Mine:
> > - Story points and relative estimation
> > - automated testing
> > - developers do no testing
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Scrum Alliance - transforming the world of work." group.
> > To post to this group, send email to scruma...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > .
Jeff Lindsey
themselves to be smart people first, developers second, and
(department or role) third. In general, feeling confident enough to
reach beyond their role and contribute to any discussions around their
team's stories rather than sit in their comfort zone.
Largest process obstacle would be writing good user stories - clearly
delivering a slice of value to the customer rather than viewing/
writing them as bigger groups of developer-oriented tasks.
Gustavo Cebrian Garcia
"This will take you 2 weeks", and after three months of work, and with help, we did not finish it.
It was horrible.
We did not have any requirements.
LET the programmers do the estimates!!!!!!!!
--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To post to this group, send email to scruma...@googlegroups.com.
To unsubscribe from this group, send email to scrumallianc...@googlegroups.com.
Jason
impediments. I define impediments as outside forces that are
preventing the team from getting work done.
The largest impediments I've seen are mostly organizational related.
Things like having functional managers try to control their
'resources' on the team(s) into working a certain way or department
managers trying to force the team to abide by the 'old world' rules.
These 2 factors seem to stifle creativity and eventually kill off the
agile initiative.
Other things I've found really common are not having proper
infrastructure (dev machines, build servers, integration env's etc).
I think story points, estimating and testing issues are largely skill/
knowledge issues that the team can do something about.
On Jul 20, 5:04 am, "andrej.ruc...@gmail.com"
Kurt Häusler
> - Story points and relative estimation
> - automated testing
> - developers do no testing
Interesting. It might also be interesting to discuss who was impeded
in doing what, how the impediment was discovered or reported, and most
importantly how it was resolved.
The third one is interesting, did a developer say in the standup or
retrospective that he was impeded in his work because he didn't do any
testing, or did someone else, say the SM, decide the team should do
testing, and declare it an impediment?
SCiPS
interference (intrusion) ex.: You are in the middle of the task 23 of
the user story 4 and your boss (or even the top management) pass by
and ask you to do something else which is not plan, not in the sprint,
not even in the project, you tell him you are in the middle of
something and you need to finish that task first, you tell him the
task he asked you may interfere with the sprint delivery, but he
insist and he is you boss... so you do it...
When the boss does that 3-4 times a day, with the whole team... your
velocity is drastically reduced... that's the worst impediment for me.
What is smart is that when pointing out this impediment at the next
morning scrum meeting, everyone agreed it was the worst impediment. So
I took my post-it with my top 3 impediment of the day and challenged
the management.
The Manager Answer was: "I understand but we have a problem and you
are all focused on something what should I do..."
My answer was: "As a manager, I suggest you start managing: queueing
requests, prioritizing, come to the scrum master if you have issue
with the current Sprint, but don't interfere with every developer in
my team or we will never deliver our product"
Since then the interference decreased, but sometimes they re-appear so
I have to give them all the figures and warn them that every
interference reduce the velocity of the project and jeopardize the
delivery itself. "Do you as a manager want to take the responsibility
of that?" Most of the time the Management agree and plan a meeting to
prioritize problems.
But still sometimes it just does not work and I have to cancel the
Sprint and re-plan the whole stuff, let everyone play and do what the
management ask for 2-3 days and restart the next Monday the whole
stuff.
On Jul 20, 11:04 am, "andrej.ruc...@gmail.com"
Albert Arul Prakash Rajendran
1) Team contribution during sprint planning
2) Some members tries to force only their way.
3) one way communications
4) commitments
5) don't care attitude
6) estimating tasks with huge buffers
Thanks,
Albert Arul Prakash
--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To post to this group, send email to scruma...@googlegroups.com.
To unsubscribe from this group, send email to scrumallianc...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scrumalliance?hl=en.
--
with luv,
Albert Arul Prakash
http://www.bepenfriends.com/ a free online dating web site
There are only 3 colors, 10 digits, 26 letters, 7 notes and 118 elements; its what we do with them that's important.
andrej...@gmail.com
it was very difficult to make commitments, since we couldn't be sure
about quality. And developers were complaining that while they are
doing one thing, another stopped working and etc.
"Developers do no testing"
it is more related to way of working. the problem was that developers
didn't assure the quality of their work results. and we got into a
situation that f.ex. a task is marked as done and developer moves to
another task. meanwhile tester verifies task he finds obvious bugs and
ping pong between tester and developer starts. And next day developer
complains that he had to fix bugs and couldn't finish current task.
So, the thing that developers do not spend enough time on quality
became an impediment for all team. Team even wanted to make a "small"
waterfall: first develop and then test.
Probably i tend to agree with Jason, that these are more learning
issues ... but it depends :)
Regards,
Andrej
www.agilemindstorm.com
On 20 Lie, 12:17, Kurt Häusler <kurt.haeus...@gmail.com> wrote:
> On Tue, Jul 20, 2010 at 11:04 AM, andrej.ruc...@gmail.com
Gustavo Cebrian Garcia
If the manager REALLY NEED YOU, just reduce the focus factor and reduce velocity.
You tell your manager, and that is it. I am not saying he is doing things right, but
Agile is about understanding the managers needs as well, and the manager has to understand
he can reduce the velocity. A balance is necessary, but I agree with you he has to understand
the velocity can be reduced. Mark it properly as a risk. If possible, escalate it.
Ron Jeffries
> "Developers do no testing"
> it is more related to way of working. the problem was that developers
> didn't assure the quality of their work results. and we got into a
> situation that f.ex. a task is marked as done and developer moves to
> another task. meanwhile tester verifies task he finds obvious bugs and
> ping pong between tester and developer starts. And next day developer
> complains that he had to fix bugs and couldn't finish current task.
This sounds ever so fascinating. In that situation, as a manager, I
would sit down with the team or individuals and explain to them that
their software needs to work, generally the first time: it's a job
requirement. By "job requirement" I mean "you can't work here if you
can't do that."
I'd mention some techniques that can be used to accomplish that and
offer them support in getting trained to be competent. I'd make it
clear that at the moment, they are not developing at a level I'd
call competent.
I'd create some kind of graph that would let the team, and me, see
how many stories were meeting the "works first time" goal, how many
"second time" and so on.
If I were subtle, which arguably I am not, I would just tell them
that the "works first time" statistic is important to me, have them
create the graph and I'd walk by and look at it a lot.
Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
Just because XP doesn't talk about how to make fire, should we assume it
requires us to use sticks? -- Richard MacDonald
Steven Mak
pressure as the reason
- "Command-and-control" being the #1 "core value" of the organisation
- Information security policies that prevent team members of different
functional skills from helping each other. And information security
being their #2 "core value" of the organisation
On Jul 20, 5:04 pm, "andrej.ruc...@gmail.com"
Gustavo Cebrian Garcia
I'd mention some techniques that can be used to accomplish that and
offer them support in getting trained to be competent. I'd make it
clear that at the moment, they are not developing at a level I'd
call competent.
Thjanks.
Ron Jeffries
wrote:
> I'd mention some techniques that can be used to accomplish that and
> offer them support in getting trained to be competent. I'd make it
> clear that at the moment, they are not developing at a level I'd
> call competent.
> What techniques could you apply?
Automated programmer tests, automated customer tests, test-driven
development, pair programming, code inspection ...
Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
Speak the affirmative; emphasize your choice
by utterly ignoring all that you reject. -- Ralph Waldo Emerson
Gustavo Cebrian Garcia
I thought they should know already. Thanks.
BDD as well !!! What is your experience with BDD?
--
Josue Nogueira
They sell their products saying "In 12 months this system will be ready to use". After that, their go to the team members and say: "Ok guys, let´s work on Saturdays and Sunday´s to finish the product on time".
I love to live.
Ani
1) Getting "Team" commitment on Relative Estimates (teams were not
clear how to estimate a story w.r.t others)
2) Getting to a "self-organized" team....they tend to work in a
"command and control" mode...and it needs a very mature SM and his
contant guidance to enable the team to become self organized.
Ani
On Jul 20, 2:04 pm, "andrej.ruc...@gmail.com"
Nigel Baker
Nigel
George Dinwiddie
> Fear.
and Habit.
--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------
Bachan Anand
improve efficiency and this too shall pass after few months of trying
it .
In short ,
Belief and Hope
Nirmaljeet M
1. Making sure that the Product Owners are available to the team. In
most cases the PO/SME is working on a existing project and has also
been assigned to this new project and are expected to be available to
both.
2. Documentation as a result of project compliance and audit
requirements. Most clients that I have worked with have internal audit
and process requirements and teams are expected to meet them by
creating multiple detailed documents as part of the process.
Michael James
No one openly advocates waterfall anymore. Instead they advocate "Sprint 0", something less than potentially-shippable product increments every Sprint, managers with authority as pseudo-ScrumMasters, team members split between three teams, no commitment to co-location (even temporarily), and all other manner of dysfunction.
Stealth waterfall advocacy usually starts with "In reality..." as if that person's reality at the moment is the only one possible in the future. Stealth waterfall advocacy comes from CSMs, CSPs, and CSTs.
So I think now that the word "Scrum" is popular, it's our job to show people what it really means.
--mj
Bob Sarni
No one openly advocates waterfall anymore. Instead they advocate "Sprint 0", something less than potentially-shippable product increments every Sprint, managers with authority as pseudo-ScrumMasters, team members split between three teams, no commitment to co-location (even temporarily), and all other manner of dysfunction.
Okay, rip me to shreds group :)
Bob Sarni, CSC, CST
Ron Jeffries
> Are you saying that �Sprint 0� is never a good idea? ...: funding,
> training, product visioning and decomposition, initial team
> building activities, initial product backlog creation � just
> enough to get started, some estimating, initial release planning �
> .... I have done both approaches and prefer doing it before the
> first sprint.
These things need to be done. It's not a Sprint. A Sprint ships
software.
Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
The work teaches us. -- Richard Gabriel
Bob Sarni
-----
Bob Sarni
Certified Scrum Coach (CSC) and Trainer (CST)
________________________
manoj...@gmail.com
Sent via BlackBerry from T-Mobile
Ron Jeffries
> Agree, that is why I do not like the term Sprint 0. The stuff still needs to be done.
Yes. Must do. Not Sprint. We have spoken. :)
Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
Talent determines how fast you get good, not how good you get.
-- Richard Gabriel
Bob Sarni
------
Best Regards,
Bob Sarni, CSC, CST
agi...@msn.com
309-531-1035
Dan Rawsthorne
Dan Rawsthorne, PhD, CST
Senior Trainer/Coach, CollabNet
draws...@collab.net, 425-269-8628
Kurt Häusler
impediments, just day to day work, things to do, and nothing seems to
prevent me from doing that.
However if I step out of that role, and pretend I am the scrum master,
or a coach, or the business owner, or a customer or some other stake
holder, or an external observer, I would list the following:
A team of good developers that accept Scrum passively, but aren't
interested in spending development time on thinking about the process
itself.
Not having a scrum master.
The same things getting discussed at the retros every time, and
written down, and nothing changes because changes might effect someone
outside the team, or require management to implement.
The PO whinging because we have the same problems every sprint, but no
attempt is made to solve them.
The scrum guide, being too vague and minimalistic, I see it as a
strength, but the bad side effect is that teams can feel good about
doing everything according to the scrum guide, and wonder why things
doesn't work, and blame scrum. New ideas get shot down because they
aren't in the scrum guide.
A posse of senior developers with the authority to enforce an old
fashioned data centric culture, with excess complexity, and watching
the newer developers with their fresh, valuable ideas slowly reverting
to typists, implementing the 80s designs that the senior devs have
grown comfortable with.
There, now I have gotten this rant out of the way, I can go the the
retrospective this afternoon and report the usual team mantra: "super
sprint, great teamwork, learned lots, and had fun". Negativity kills
you know...
Michael James
> Are you saying that “Sprint 0” is never a good idea? Personally I do not like the term Sprint 0 but I certainly see benefit is doing some preparation before the first sprint such as: funding, training, product visioning and decomposition, initial team building activities, initial product backlog creation – just enough to get started, some estimating, initial release planning – very very high level, initial risk/issue and dependency review, high level architecture discussions, team room setup, environment setup, test strategy discussion, engineering approach discussions, tool identification and procurement, develop a story to test the system and processes, etc. I am not saying you have to do all of these things before you can get started but
Most of the time I've seen "Sprint 0," it seemed to be an excuse to procrastinate. If we're going to redefine Scrum we should be aware of why we're doing it. For example, modern teams shorten the Sprint from 30 days to 2 weeks because tools and skills are better. Some teams eliminate Sprint Tasks because they have sufficient skills to break PBIs into smaller stories. Some teams find hourly burndown charts lead back to old habits with capacity planning. The dollar in the cup rule is less effective than other techniques, and doesn't work in countries that don't use dollars.
The reasons most people raise for wanting to delay real Sprinting seem to boil down to comfort. By the time I arrive, the first Sprint is typically way overdue. Not every Sprint has to produce huge amounts of business value. Most of the stuff we'd want to get out of a "Sprint 0" is better sorted out after we've garnered some real experience and real feedback. Most of it should be reconsidered once we've primed the pump with some real product development. In trying, and possibly failing, to do a first Sprint, I think we'll learn more than we would doing "Sprint 0" in a vacuum.
But then "never" is a strong word.
--mj
George Dinwiddie
> Most of the time I've seen "Sprint 0," it seemed to be an excuse to
> a "Sprint 0" is better sorted out after we've garnered some real
> experience and real feedback. Most of it should be reconsidered once
> we've primed the pump with some real product development. In trying,
> and possibly failing, to do a first Sprint, I think we'll learn more
> than we would doing "Sprint 0" in a vacuum.
+1, and having a "Sprint 0" only encourages a "Sprint -1." Yes, I've
seen this. It was an attempt to plan all the other sprints, including
the sprint 0 team selection and tool setup, for a fixed-scope
fixed-schedule release. <sigh/> And the management of this effort
thought the successful sprint teams in the same organization were "doing
the easy stuff" because they were reliably delivering business value.
<sigh/>
- George
andrej...@gmail.com
on testing automation.
Actually i was so angry at that moment that i even wanted them to be
fired (very good that i don't have such rights :))
Andrej
www.agilemindstorm.com
andrej...@gmail.com
occurs during retrospectives.
Team says that when they ask for a help (not development, but a kind
of consulting) from other team they get following answer - such task
is not included in current sprint come here in a week.
Well it is ok from process perspective - noone should bother a team
during sprint.
But how should it be handled in a more effective way? It is not always
possible to plan ahead ...
Andrej
www.agilemindstorm.com
Aquarius
My 5 cents:
1. Pushy PO;
2. Some guys considering SCRUM as framework to support anarchy (self-
organised evil-contract);
3. Inter-team frictions/storming/politics.
Rgrds,
Aquarius
Jeff Lindsey
> These things need to be done. It's not a Sprint. A Sprint ships
> software.
>
In video games, we're often after internal value initially: creating
knowledge (what is fun) that will eventually lead to customer (player)
value, especially when the game concepts or feature ideas are loose
and need to be explored. In some cases, the best bang for the buck to
get that knowledge is very lightweight throwaway prototypes and
mockups, whether it be code held together by paper clips and bubble
gum, true paper prototypes, a bunch of action figures on a meeting
room table, or an animated Flash movie simulating some visual aspect.
And in my experience, doing very short sprints at the start (call them
sprint 0 or whatever you want, it's all semantics) is a great way to
get a team out of that all-day-meetings/pure conjecture phase, and
focused on creating that knowledge in tangible ways.
I'm not saying that we don't desire working software over other
results in our sprints, but it's simply not always practical when you
are trying to innovate in areas such as gameplay, player agency, new
peripherals, new tech, etc.
Ron Jeffries
> I'm not saying that we don't desire working software over other
> results in our sprints, but it's simply not always practical when you
> are trying to innovate in areas such as gameplay, player agency, new
> peripherals, new tech, etc.
Yes. Lots of teams do this. If they are successful at doing
software-scrum and then begin to use Scrum style in other ways,
that's just fine.
For a team to /start out/ that way is very dangerous because they
are quite likely, based on my experience, never to focus in on the
software, instead accepting all kinds of "progress".
We said in the Manifesto:
Our highest priority is to satisfy the customer through early and
continuous delivery of valuable software.
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.
We really meant that. I'm not interested in whether that's "Agile"
or "Scrum". I observe that teams that do not focus on delivering
software never get very good at delivering software. If you need
software, it's important to get good at it. Allowing focus on
something else seems to get in the way.
Again ... if the team rocks at the software bit, and wants to use
Scrum style for other things, I've seen that work. I have not seen
starting with other things turn into a rocking software team.
Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
The greatest mistake we make is living in constant fear that we will make one.
-- John Maxwell
