- So, just to clarify, you are discussing issues that arise inside a team, for example after a product owner has asked for something? So this would not issuesMessage 1 of 71 , Jul 1, 2008View SourceSo, just to clarify, you are discussing issues that arise inside a team,
for example after a product owner has asked for something?
So this would not issues that hold up the product owner from being
able to schedule items?
Ron Jeffries wrote:
> Hello, Robert. On Monday, June 30, 2008, at 5:08:58 PM, you wrote:
> > I was thinking of things that might be hard to resolve at the broader
> > business level, because decisions were being delayed, for example.
> > So if the software was for a timecard system for a company, and they
> > were delaying a decision about the way overtime was recorded while
> > they negotiated with the union.
> > Might that seem like an obstruction to developing the software?
> Only if the PO had scheduled the story and then the info wasn't
> available. The programmer should report the obstacle and the SM
> should resolve it, probably by having the story cancelled.
> Too often, however, teams just try to muddle through without knowing
> what to do, waiting long intervals between Q and A, and such. That's
> not so good.
> > But maybe you should suggest an example of an obstruction too.
> Handoffs, e.g. programmer to tester;
> Technical tasks;
> DBA not available;
> Waiting for UI design for a story already scheduled;
> Multi-Sprint work in progress, i.e. phased stories;
> Ron Jeffries
> I must create a system, or be enslaved by another man's;
> I will not reason and compare; my business is to create. --William Blake
- Hello, Robert. On Wednesday, July 2, 2008, at 11:19:55 AM, you ... OK. Why do /you/ think Scrum works. ... Interesting. What do you see in the definition ofMessage 71 of 71 , Jul 2, 2008View SourceHello, Robert. On Wednesday, July 2, 2008, at 11:19:55 AM, you
> Your earlier message said:OK. Why do /you/ think Scrum works.
>> Scrum works, in my opinion, because it requires two things:
>> 1. Produce Done-Done software on a regular basis;
>> 2. Remove every obstacle to doing item 1.
> I'm not sure I agree. In particular, it seems to suggest an absolute
> focus on
> software, and it seems to suggest seeing other things as obstacles to that.
> I think an important advantage of scrum, and other agileInteresting. What do you see in the definition of Scrum that leads
> processes, is that they involve software development in a wider
> context, and in that wider context the development of software is
> unlikely to be the priority.
you to believe it is not focused on software? A reference would be
> So the advantage for software development is that the process isSo that whole "Agile Software Development with Scrum" thing was just
> more likely to lead to software that helps in that larger context.
> This means it is important for everyone to realise that software
> development is not the ultimate goal, and that things that might
> seem like obstacles may in fact show aspects of the wider context
> that need to be better understood and may in fact change the
> nature of the software development.
what ... a typo?
I must create a system, or be enslaved by another man's;
I will not reason and compare; my business is to create. --William Blake