Changes to Agile Manifesto

[Scrummistress]

Can someone point me to a document that outlines the changes and
implications of such to the Agile Manifesto? What do the changes mean
to you? Did you change how you implemented scrum?

Besides these, what does the industry feel are the biggest changes to
scrum and Agile in the last 3 years?

Doing some reasearch and would love some input. Thanks, crew.

L

[RonJeffries]

Hi, L,

On Feb 15, 2012, at 12:27 PM, Scrummistress wrote:

Can someone point me to a document that outlines the changes and
implications of such to the Agile Manifesto?  What do the changes mean
to you?  Did you change how you implemented scrum?

A manifesto is not a living document. It is a statement of some groups' position at some point in time. So in an important sense, the Agile Manifesto "cannot" change. An interesting question is whether we authors think now, what we thought then. As it happens, we know the answer to that.

At Agile 2011, most of the authors of the Agile Manifesto did a panel discussing events of the last ten years and such. One of the questions was whether we had changed our minds about things.

We had not. We believe that the principles and values stand up pretty well. No one really desired to add or remove any. There were certainly no additions or subtractions that a majority of us would have agreed to.

We have learned a lot over that time, of course. What we have learned are new practices, approaches, to living by those values and principles.

There are some (few) people who think that the Manifesto needs updating. In my opinion, this mostly reflects misunderstanding as to what the Manifesto says.

Besides these, what does the industry feel are the biggest changes to
scrum and Agile in the last 3 years?

From my viewpoint there are not many truly big changes to Scrum or Agile practice at all. There are lots of smaller changes that change how we do things, but not what we are trying to do.  I'll come up with some examples at random:

• Scrum as practiced adopted some XP ideas, including user stories, tasks, estimation, and release planning. 
• The XP community, at least as represented by Ron and Chet, no longer favor tasks. Nor do we favor story estimation. We are opposed to release planning, though it cannot always be avoided. (The reason is that release planning militates against what works best in Agile, namely steering the project to success by judicious choice of features to build.)
• Technical practices, again borrowed from XP, are beginning to be understood to be essentially necessary for successful Scrum projects. The Scrum Alliance Certified Scrum Developer program reflects this understanding. 
• The Product Owner job is harder than anyone imagined.
• The backlog grooming process is more important than most people recognize at first.
• Lean techniques, especially kanban techniques, can be quite valuable in improving the process.
• There are situations where the project may be better served by continuous flow rather than using iterations.

I'm sure there are many more. Note that none of these have substantial impact at the "policy" level. They are just recognitions of better ways of doing things.

There are also some important understandings about what goes wrong.

• Lack of an empowered business-focused Product Owner is deadly to project success.
• Scrum Master is not a management  or project management position.
• Pressure to deliver "more" is almost instantly damaging to project quality, and inevitably means the project will deliver fewer features, and more defects.
• It is not very productive to divide work across technical boundaries, with Scrum teams working on bits of infrastructure or integration or some other technical breakdown.
• Failure to follow good technical practice results in slower delivery of inferior software.

Again, there are many more ways to go wrong. 

It turns out that, in my opinion, addressing these concerns do two things. First, you move more in the direction of the Agile Manifesto.Second, and far more important, you move your project toward more likely success.

So ... in the opinion of the Authors, the Manifesto stands up pretty well. There has been much learning about how to do things.

Ron Jeffries

www.XProgramming.com

I know we always like to say it'll be easier to do it now than it

will be to do it later. Not likely. I plan to be smarter later than

I am now, so I think it'll be just as easy later, maybe even easier.

Why pay now when we can pay later?