RE: [scrumdevelopment] Re: Following the rules
- Interesting. Help me understand how these phrases structure your approach.
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
I really need to see this as I am now walking away with is the notion your
presentation of Scrum is an
'us - them game' - not interactions between individuals
Our way or the highway. we don't collaborate with the customer and they are
not part of the team; we make the rules and they better follow it.
We have a plan and we will work it. throw away any life experience we or the
Product Owner have and dogmatically follow a set of rules.
Just to make it very clear Scrum and other Agile methods are vehicles that
carry the Agile Manifesto. As a 'formal' method, this approach had been in
the public for a very few years. You are all, in the long run, a member of
the pathfinder team in this effort. No two implementations of Scrum are the
same, there will never be as long as we transport the Agile Philosophy.
Yes Jeff is doing incredible things, but when you meet him next ask him who
changed Scrum the teams involved or he and Ken.
If what you are saying is you need a starting point, then yes you do. Scrum
methods may be the jumping off point but keep in mind the reason Scrum fails
or succeeds is not so much following the rules but understanding how to set
up the Agile and Scrum boundaries where you are doing it.
For example if you are an employee, then the key starting point is the agile
principles and the Nike slogan "Just Do It" Smile, agree, and deliver.
Keep in mind Scrum and Agile are only about Delivery of good stuff to the
product owner. Let them carry the word forward, help them to know where to
say it. Commit to their organization that you will work with them to get
this done. In effect let them fight the battle of Scrum acceptance, not
you. They got the clout, while you have the baggage of decades of their
disappointment in IT and software development.
First do NOT make Promises, they are weak ways of saying I'll try. Who
cares, no try - Only Do or Don't Do - there is no try.
Make commitments, follow through on them and do it transparently (in public
to a broad audience). If you commit not to work on stuff that has not gone
through the planning and the negotiations, then keep you commitment and
publically state you cannot break your commitment and do this one little
thing without the planning, negotiations and agreement. Use the Corporate
ethics stuff hanging around to tie what you are doing to what the company
has stated is its value statement. Use the traditionalists love of
bureaucracy to tie up implusive behavior, but in all cases deliver, deliver,
Commit to collaborating with the Product Owner, if you are defining, scoping
what have you at the high end, Keep in mind that the Product Owner is the
only person that can make those kind of decisions, all you can do is state
how much you can implement.
Work to priorities, Since the only way to measure priority is through
commitment, if the Product Owner doesn't show up to define what they want or
answer questions, stop, report it as an impediment and when it fails at the
end of a Sprint, take it into the retro and question if this effort is
really that important, since no shows to get the job done. make that
Keep in mind collaboration and teamwork do not require friendship only
respect and discipline. But first you have to have those things in your
If this sounds too hard, it is not, it is very difficult and does require
certain amounts of courage and stupidity that does not allow you to quit.
Michael F. Dwyer CSM, P
"Planning constantly peers into the future for indications as to where a
solution may emerge."
"A Plan is a complex situation, adapting to an emerging solution."
[mailto:firstname.lastname@example.org] On Behalf Of Victor Szalvay
Sent: Friday, September 30, 2005 4:20 PM
Subject: [scrumdevelopment] Re: Following the rules
Well put, you've captured the essence of my message better than I.
Keith's team is new to Scrum; I would not advocate deviations from
the original "rules" until the team, PO, and management understand the
principles well enough know how the rules can be bent and what needs
to remain constant so as not to break the underlining principles.
Advanced teams are a different story completely, as evidenced by the
incredible things Jeff Sutherland's company is doing (among others).
-- Victor Szalvay
> [DAB] I'll take the pot up to $0.04... Scrum is like any other skill or
> technique that you learn. At the beginning (by definition) you lack the
> experience to anticipate the impact of some of the things you do. To
> mitigate that, you rely on the written material and experience of
> guide you until you have a chance to observe the process in action for avalue
> while. This is what we are calling, "Following the rules", and its
> is that improves your chances of success while you build your skillswith
> the techniques. Scrum is deceptively simple, and this makes it lookeasier
> to tinker with than it really is. Every organization that adoptsScrum is
> going to have its own unique quirks and ways to make Scrum workbetter and
> it will probably take time to find out what those are. In the meantime,we're
> what's wrong with saying to everyone, "We're still learning this, so
> going to stick pretty close to the "rules" for first few months"?To Post a message, send it to: scrumdevelopment@...
> You listen and understand where all of your team is coming from and work
> with them to get to where you want to go.
> Mike Dwyer, CSM, P.
> -- Victor Szalvay
> Danube Technologies, Inc.
> Dave Barrett,
> Lawyers' Professional Indemnity Company
To Unsubscribe, send a blank message to:
Yahoo! Groups Links
- I don't think you are far off, and that we are about to become violent in our agreement, but are separated by a common misuse of the language.If the PO is the person accountable to the organization for the decisions about how the product works and they rely on SME's to act in their behest and as proxies, then IMO, the PO is a person who has delegated their authority to the SME. If this is the case then we are in agreement on all but the moot issue as to is the PO a person or a persona /role.IF however the degree to which the SME's decisions are independent of the PO is recognized and the SME is held accountable for the product's functionality, then I agree with your concept of the PO as a role.The only point I wonder about is if this situation wanders around between the two and your teams are, in fact, making the business decisions and then moving the person or the role to agree with them. I would be concerned if that were the case.You stated:To some degree, many of those SME's act as the PO's proxy from time to time, and we try to establish the understanding with those SME's that it is up to them to make sure that they keep their PO's up to date on decisions that they
have made, and to follow up with the PO if they need help making decisions
We remind them of this when we discuss something potentially contentious.
If an SME tells us that they are too busy to help us, we'll usually arrange
a meeting with the SME, his supervisor, some Team members and the Scrum
Master. In most cases the supervisor and the PO are the same person, which
simply makes it easier to make a case for the supervisor to clear the SME's
schedule for us.--
Perseverance is not a long race; it is many short races one after another. ~Walter Elliott, The Spiritual Life
The greatest oak was once a little nut who held its ground. ~Author Unknown
-------------- Original message --------------
> I think you are confusing the *role* of Product Owner and the person who
> plays that role.
> In Scrum the Product Owner has one task: To prioritize the Product Backlog.
> That's it, nothing else.
> Of course it is useful to have a product owner who at least has some
> influence over the schedules of people outside the Team that the Team needs
> to use as resources. The Product Owner is probably the same person who
> decides whether the product goes live, and is probably involved in core
> business decisions affecting the Product. Its probably a really good thing
> if the Product Owner is what would traditionally be know as the "Corporate
> Project Sponsor". None of those things is particularly Scrummy, however.
> It sounds to me like you're postulating a PO that rolls his sleeves up and
> gets involved with the Team on a day to day basis and acts as a Subject
> Matter Expert to assist the team with the analysis and design of the
> features. That's not a bad idea, but certainly not mandatory to implement
> Scrum. The most important thing, though, is that when the PO does that,
> he's not acting in the role of PO, but simply as a Team member who's skill
> set is that he's an SME.
> As to the other stuff about getting people outside the team to show up and
> participate; that sounds to me like the kind of issue that the Scrum Master
> is supposed to deal with under the heading of "Clearing Impediments".
> In our company, we're using Scrum to manage projects that build and enhance
> systems for internal consumption by a number of departments. We've built a
> database which organizes the PB by department, project and task and is
> maintained by those departments for the most part. At regular intervals,
> the Senior Management Team gets together and goes over the PB (at a high
> level) and hammer out who's projects have the highest priority and should
> get the Team's attention. Then the Team sits down with the various PO's
> for each department and sort out the priorities for the projects on the go.
> It varies from department to department, but we usually don't have a lot of
> interaction with the PO's during the Sprints because the SME's for the
> various SB items are usually other people in their department. To some
> degree, many of those SME's act as the PO's proxy from time to time, and we
> try to establish the understanding with those SME's that it is up to them
> to make sure that they keep their PO's up to date on decisions that they
> have made, and to follow up with the PO if they need help making decisions.
> We remind them of this when we discuss something potentially contentious.
> If an SME tells us that they are too busy to help us, we'll usually arrange
> a meeting with the SME, his supervisor, some Team members and the Scrum
> Master. In most cases the supervisor and the PO are the same person, which
> simply makes it easier to make a case for the supervisor to clear the SME's
> schedule for us.
> By and large, we find that this works very well. The Sr. Mgmt Team ensures
> that we're focused on corporate priorities at a big picture level and the
> PO's handle the details. Most of the PO's have built the confidence in the
> Team that they'll actually deliver what they've committed to by the end of
> each Sprint, which means that they're less likely to meddle with priorities
> during the Sprint. They also have come to realize that, "We'll put that
> suggestion in the PB" doesn't mean that we're saying "No", and that they'll
> have an opportunity to get it inserted into a Sprint in the near future.
> We've been running 30 day Sprints, which fits well with the pace of change
> in our business.
> Dave Barrett,
> Lawyers' Professional Indemnity Company
> ------------------------ Yahoo! Groups Sponsor --------------------~-->
> Get fast access to your favorite Yahoo! Groups. Make Yahoo! your home page
> To Post a message, send it to: scrumdevelopment@...
> To Unsubscribe, send a blank message to:
> Yahoo! Groups Links
> <*> To visit your group on the web, go to:
> <*> To unsubscribe from this group, send an email to:
> <*> Your use of Yahoo! Groups is subject to: