The Agile Manifesto as "Immutable, Sacred Text"*

Periodically, over the past 6-7 years, the issue of whether the Agile Manifesto** requires changing comes up and a variety of points are made suggesting/justifying why it seems this is needed. Recently, some of the new and repeated points have been:

• Surely learning has taken place in the almost 10 years since the Manifesto was created which would influence a different set of ideas to be stated now than then.
• The work being done by people before the Manifesto existed wasn’t about “agility” but was about more effective, productive software development.
• By the very nature of Agile ideas, we should be prepared to change the Manifesto and not keep it the same since that was just a point in time perception and both perceptions and needs change.
• Most of the ideas in the Manifesto can be found elsewhere, especially in Lean ideas, so they should not be regarded so permanently.
• The Value statements are so easy to agree with that they are, essentially, “content-free.”
• The Principles are redundant in many aspects (indeed one basically repeats a Manifesto Value) and could be reduced to a much smaller set without losing any meaning/effect.
• Misunderstanding/misuse of the Manifesto (as stated) is now an impediment to new people learning about Agile ideas so we should move away from it as a focal point.

And the list can go on and has at various times.

There are, of course, lists of actual suggestions for changes/additions to the Manifesto which are even longer and, in themselves, certainly contain useful, important ideas. One just has to look at the early material on each method that was around at the turn of the century to see how many values, principles, ideas, etc. existed which are not explicitly mentioned in the Manifesto. So it was even obvious back in 2001 that the Manifesto did not say everything one could be expected (to need) to know on the subject.

Among others, Ron Jeffries has said that the Manifesto is a point in time statement of belief by a specific group of people. After years of experience and interaction with one another, they came to feel that they wanted to say something about ideas they shared which were, as suggested above, just a subset of the ideas they held.

I don’t believe the people at the Snowbird meeting where the Manifesto was created thought it was some document that should be amended, extended and always be the authority for thinking on the subject of better software development. I do believe they felt the ideas were a solid set of guidance, an effective starting point for changing how software development was being done, for the most part, up to that time. And, if groups/organizations pursue a new approach to development, the Manifesto’s elements can be looked upon as useful touchstones for comparing chosen techniques and practices to ideas those people in 2001 felt held important guidance for doing so.

So when calls to change (or even abandon) the Manifesto are made, while I am interested to hear what people would offer as changes, additions or replacements to/for the Manifesto, I have not seen anything that, to me, materially alters what is there.*** Much of the impetus to change the Manifesto sometimes sounds as if, to get other ideas accepted, the Manifesto must be reduced in importance in some way or shown to need “fixing.” Perhaps the strong attraction to the Manifesto just shows that the ideas can ring very true to many people.

If the fear is that latching onto the Manifesto (and misunderstanding it) holds people back and prevents new learning from taking place, perhaps that is our problem to solve, not by trying to change the Manifesto in some way, but in more effectively presenting and explaining it to those new to it while extending the knowledge that can be associated with it. I do not believe we can blame the Manifesto for people not “getting it” because it seems to me that this happens to every idea once it breaks out into the mainstream of awareness.

If something has any validity, it will attract people, but they will surely try to adapt it to what they feel is their need. Much of that adaptation is always a divergence from what the original ideas intended. I don’t think it is possible to expect this not to occur unless one produces a document as ponderous as much formal legislation, standards, etc. material. Of course, even when you try to do that, the interpretation is still going to be there, sometimes worse than before you started.

So, by all means don’t stop at the Manifesto, but don’t assume it is somehow the problem or the impediment to growth.

[* The title is derived from a Tweet by Jason Yip.]

[** When I say “Manifesto,” I include both its explicit Values and the associated 12 Principles that followed unless a distinction is otherwise made.]

[*** Efforts such as the Manifesto for Software Craftsmanship and the APLN’s Declaration of Interdependence seem to me to be good examples of making the point about other important ideas without suggestion the Agile Manifesto’s are now flawed or necessarily passé.]

Letting Them Figure It Out

A few days ago, there was a brief exchange on Twitter about the Scrum advice to let teams figure things out for themselves where there isn’t explicit Scrum guidance on a topic. Since there isn’t explicit Scrum guidance about a lot of things teams encounter that leaves a lot of “figuring out” for teams to do, including adopting practices from other Agile approaches like XP, Crystal, DSDM, etc.

There seemed to be an initial implication that leaving teams to do this could be wasteful, perhaps even detrimental, given the assumption that they really don’t have a good answer for their situation and might not, by consensus, come up with one. I suggested that “guiding" teams to figure things out seemed to me a useful way for a coach/ScrumMaster to fulfill that role than just "letting" the team figure it out. If the coach/SM sees a possibly useful direction for the team to go in, guiding the team that way through the “right” questions would be an appropriate approach.

Given that, I said I didn’t mind teams figuring things out for themselves, just not doing so by expecting them to reinvent all knowledge to accomplish that. Thus, if the coach/SM knows of techniques/practices that have worked for other teams, suggesting those ideas and asking the team what they think about them still seemed to be allowing teams to make their own decisions while still being helpful in a non-directive manner.

So that’s gotten me thinking about the subject of doing this sort of thing as a coach/SM as it has been my way of performing these roles. Indeed, it has been my way of teaching people about things for decades, even before I was involved in software development. I’ve always associated this with employing the Socratic Method, i.e.,

A pedagogical technique in which a teacher does not give information directly but instead asks a series of questions, with the result that the student comes either to the desired knowledge by answering the questions or to a deeper awareness of the limits of knowledge. [From http://www.answers.com/topic/socratic-method.]

I don’t go as far as “Socratic irony” with this. That is, I don’t feign/pose ignorance. Indeed, after using the Socratic approach a bit, I’m fairly certain the students/teams I’ve been engaged with don’t believe that’s the case.

But this raises the following questions:

1. How much information about techniques and practices might a team need before they start working together so that there are not too many open issues to “figure out”?
2. Indeed, how many open issues are “too many” for them?
3. How many times or how seriously should a coach/SM allow a team to “fail” in such decision-making (since allowing teams to fail, a bit, is typical advice given to coaches/SMs/managers in an Agile context)?

On the latter point, one thing I can say is that learning through even a little failure can be stressful when teams are up against deadlines. I also think, given such deadlines, both teams and people around them seem much less inclined to accept the “fail a little” approach.

Now the kind of “deadlines” I am thinking of are not the kind the team commits to themselves through reasonable estimation and planning. I’m thinking of the all too common situation where an Agile approach is taken in the context of already fixed schedules and, more or less, fixed functionality expectations.

Not only is this kind of situation inherently a major impediment to learning through some failure, even though a Socratic approach, it is an impediment to the whole idea of teams “figuring it out” for themselves whether serious failure would be involved or not.

With fixed schedule and functionality (as well as fixed staffing) usually comes 100% “resource utilization” assumptions as the way those outside the team(s) assume planning and estimation will be done.

I believe every team I have ever been involve with, Agile-based or not, has been somewhat astonished at my suggestions that

1. they only presume a 6, not 8, hour productive day in their estimation, so a 30, not 40, hour week;
2. within this 30 hour week they commit to less than 100% of that in functionality terms, especially when they are new to this approach;
3. they do not presume to commit overtime at the outset as a way to deal with the fixed schedule and functionality.

The first point is something I learned doing estimation over 30 years ago. The second has been influenced by my Agile training/experiences. The last is also a nearly 30 year old belief based on watching teams do this, implicitly, if not explicitly, and coming up with unreasonable commitments as a result.

So, it seems to me that trying to let teams figure things out for themselves isn’t something that will be successfully achieved outside the context of having some other things in place that give the teams the “space” in which to believe they can/should expect to do this. Otherwise, they are going to look for someone else to solve the problem (and hang the result on) given their very natural perception that they don’t have the time to take for much team reflection and a Socratic type of guidance.

Deadlines, But No Tempo

I have only recently started to present the idea I comment upon below when I teach classes and otherwise discuss development work with people. I’m not sure why it took me so long to recognize this comparison between the traditional phased-sequential (i.e., waterfall) and Agile approaches to development. But it seems an important point.

Traditional phased-sequential approaches to development have many deadlines/milestones as targets for work, but specify no expected tempo for getting work done between those milestones. Agile methods show considerable concern for establishing a work tempo which replaces most of the date-driven milestones in traditional approaches.

To me, the focus on milestones is less desirable than a predictable tempo because distance between milestones will vary from project to project based on the overall size of the work to be done by the final project delivery milestone. Agile’s main milestone is the iteration which is always (supposed to be) the same length. So teams get used to producing some defined result, regularly, at this tempo.

In traditional milestone-driven projects, the weekly/bi-weekly status meeting might be viewed as establishing some sort of tempo, but what is expected to be done between such events is not a delivery of value/product. So I do not view status meetings as having the same tempo impact as iterations.

A predictable tempo seems to me to encourage more of a team approach to work. Milestones allow more individual work expectations using milestones as coordination points. Of course, the time between such coordination points allows a lot of work to be done before coordination occurs and, as noted above, the time between such points will not necessarily be consistent within or between projects. I believe the inconsistency, extended time periods, and individual task focus work against effective coordination.

At least, it places greater burden on individuals to establish coordination behavior ad hoc. On the one hand, coordination is expected to occur. On the other, individuals view any work tempo to be personal. Coordination efforts in this context seem more difficult because they are not collaboration within an agreed upon tempo, but negotiation between individually accustomed to tempos. In such negotiation, some people are almost guaranteed to feel they have “lost”. (And, truthfully, this may be why some people find moving to an Agile approach problematic. The tempo of an iteration is not their natural one and, though it is not the other team members who have imposed the iteration concept on them, someone has.)

This leads me to believe that some talk about individual work styles and tempos is an important part of the “forming” stage for a team. Everyone much fit into the iteration length’s tempo. Discussing how to support and help one another do that, then, seems to me to be an important aspect of team-building in an Agile context.

I don’t hear people talk about this much, but I do believe I see consequences of it in daily work discussions, ability to deliver on commitments, etc. Because there are consequences for not overtly recognizing this, I think it should be discussed when teams are getting started. And certainly think the concept of milestones vs tempo is important for an organization to discuss when deciding to embark on an Agile approach to their development.

Last Quotes From Twitter

Not because folks aren't saying great things still, but I think I've run this idea into the ground and doing this last, very short, set will be a way to start my blog up again after several months of regrettable inactivity.

@FunnyOneLiners - A mighty oak is the result of a nut that held it's ground.

Abraham Williams - Sometimes I write a letter on paper with a pen then burn it laughing about how Google must be crying over information it will never index.

Albert Einstein (via Jason Yip) - The formulation of a problem is often more essential than its solution...

Albrecht & Zemke (via @ASQ) - People do not just buy things, they also buy expectations.

Bob Marshall - Agile successes - or not; echoes of Rashomon?

Dale Emery – The values (then the principles, then the practices) stand at the brink and wave goodbye as the name moves on. Michael Bolton - I said a couple years back that Agile hasn't crossed the chasm; it's mostly fallen in. But the name made it across.

David Joyce - Toyota manager induction doesn’t take place in a room but instead 12 weeks are spent in the work being coached on how to solve problems.

G. K. Chesterton (via Jason Yip) - There are two ways to get enough: One is to continue to accumulate more and more. The other is to desire less.

Glyn Lumley - The manner in which employees treat customers is determined, in part, by the norms for handling internal conflict and frustration.

James Bach - If you don't have a clear goal in life-- then watch out!-- you might wander and learn cool things that no one anticipated. Payson Hall (replied with this from Tolkien) - Not all those who wander are lost.

Jay Arthur - At one time, customers wanted you to be better, faster and cheaper. Now, they want everything free, perfect and now.

Michael James (actually from a mailing list talking about Scrum and Kanban) - I'm not sure it matters too much whether someone edits with vi or emacs, as the real challenge is what's in the file.