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.

Gad...Yet More Quotes from Twitter

Been too long since I posted anything.  But, fortunately, I have been very busy with work and still digging out from under a move to a much smaller place.  I said it a few months ago, but I hope to turn posting to this blog into a more regular habit.
--------------------------------------------------------------------------------------

@funnyoneliners - When asked "What would you bring with you to a deserted island", how come no one ever replies, "A boat."?

Alan Cooper - Art always contains craft, but not vice versa.

Bob Martin - Any meaningful certification must be hard to acquire with a significant chance of failure. I wonder what the CSD failure rate will be...

Bob Martin - Once any word, like "agile" or "Object" or "Structured" becomes synonymous with "Good" it has lost all meaning.

Bob Martin - Second law of meetings: Meetings are for decisions. If you don't know what's to be decided, don't go. If no decision is proposed, leave.

Brad Burt - In the 'Art of the Effect' in magic, less is almost always MORE. It has to do with purity and thus the ease of a watchers acquisition of what has happened. Amazement is knowledge of a kind.

Brian Marick - The original sin of Agile is that small nimble companies don't pay consultants enough, so all the attention is to the lumbering dinosaurs. James Shore - Such truth in @marick's tweet. Explains "Agile" plan tools, watering down of Agile, desire to "scale" mediocrity. Not only reason, natch. [Brian noted “original sin” term not right one. Other noted consultant focus wasn’t real point, it was “dinosaur” focus.]

Brian Marick (at goosgaggle ) - design happens in writing the test - implementation is just stenography.

David Hussman - Many companies need to slow down to get more done.

Dawn Cannon - The purpose of planning is not to prevent uncertainty, but rather to plan how to deal with uncertainty.

Esther Derby - managers are designers of the experience of work.

Esther Derby - Resistance = "Other people are not doing things I want them to do w/ the speed or enthusiasm that I desire."

FunnyOneLiners - It's not easy taking my problems one at a time when they refuse to get in line.

Hannu Kokko - Partial conditions of satisfaction for a demo: understandable, valuable for customer, wow-factor, shows progress

Hillel Glazer (heard at SE{G NA) - Proposal to add a new value to manifesto: "we value improvement over compliance"

Ian E. Savage - Certifications are only as good as the certifying agency. Got it. Let’s move on, shall we.

James Bach - A lot of my choices are about arranging life so instead of having to control my anger, I don't have anger that needs controlling.

James Bach (at #accu2010 via Tom Gilb) - 'it is Testers Job to not be fooled by What is fooling everyone else'. 'testing is about discovering the significance of the requirements'. ‘The spec is a rumor! Wouldn't you like to know what the code ACTUALLY does before you ship?’

James Bach (at StarEast via Matt Heusser) - "bad rigor is following instructions without understanding them", or "pathetic compliance"

Jared Richardson – Overheard: Jenga development. You're not sure which piece will bring it all down, so you resist any changes no matter what.

Jason Gorman (via Hannu Kokko & Kent Beck) - Knowledge of languages and APIs no more makes you a developer than knowledge of anatomy makes you a doctor.

Jerry Weinberg - When managers don't understand the work, they tend to reward the appearance of work. (long hours, piles of paper, ...)

Joseph Angel Alcala - Apologizing always doesn't mean you wrong and others right...means you respect relationship more than your ego.

Ken Schwaber (in a recent podcast, reported by Tobias Meyer) - Scrum is less a silver bullet and more an enema.

Kent Beck (via Jon Udell) - There's no difference I can see but there's obviously a difference the computer can see. I hate that.

Marcus Ahnve (via Lasse Koskela) - Feedback without conversation is criticism.

Mark Levison (re: Agile retrospectives) - I ask "what needs improvement" and focus is on discovering issues. Next I ask "What does team have energy to improve". Then they create action plan.

Michael Bolton - The *number* of test cases that are passing or failing has no more meaning than the *number* of ideas you had in the shower.

Michael Feathers (via Jurgen Appelo) - If you don't give your software a shape, it's going to get a shape anyway. The reason most of our code sucks is that we don't take ourselves seriously as users of our code. Constraints drive design. TDD is an example of a constraint (testable code), and design thrives in constraints.

Morrell (via Jesse Fewell at InfoTech2010) - your team doesn't care how much you know, until they know how much you care.

Naresh Jain - Little things make big things possible. Close attention to fine details brings out excellence in your craft.

Payson Hall - Pondering process improvement/decay cycle oscillation: +Pain > +motivation > +rigor > -pain > -motivation > -rigor > +pain... (repeat)

Peter Scholtes (via Glyn Lumley) - Explaining why change is important will not make the change happen.

Phillip G Armour - and testing is also about finding out how to find out something you don't know you don't know.

Stephen King (via Peter Murphy) - If you don't have the time to read, you don't have the time or the tools to write.

Stephen Mann (via Anna Nachesa) - Love the old management saying ... meetings - where minutes are saved and hours are lost.

Tom Kealey - Instead of asking the question "how agile are we?" try "how are we agile?" The difference is profound.

Woody Williams - The absence of failure is not an indication of success.

Newer Set of Quotes from Twitter

Many things happening over the past couple of months, including becoming a grandfather.  But also preparing for what looks to be a lengthy Agile/Scrum coaching assignment.  So here's yet another set of quotes from Twitter posts in, again, alphabetical order by first name.
-------------------------------------------------------------------------------

Alan Cooper - Lean is related to "efficiency" which seems to me an industrial age concept. Bob Marshall - Imo Lean is much more about *effectiveness* than efficiency, hence my #rightshifting campaign, not least.

Alan Shalloway - if your team is populated by heroes your process will require them.

Alan Shalloway - sometimes being heroic is just another way of avoiding prioritization. Scott Duncan - Or is a sign of not recognizing the need to prioritize?

Ash Maurya - Build [features] in response to a signal from the "customer", and otherwise rest or improve.

Bob Martin (on liking one-week iterations) - "not much can go wrong in a week"

Brian Foote (in response to Alan Shalloway - There is a big difference between eliminating waste & not creating it in the first place.) - Fasting vs. Sanitation

Brian Marick - If you have one really great idea and express it together with many dumb ideas, the dumb ideas get a free ride in ppl's minds. This is bad.

Brian Marick - It's swell to be compulsive about "delivering value" but let's realize that "value" isn't a real thing out there in the world. "Value" is not an objective fact. It is a prediction, made by some people, about reactions of other people, over some time. George Dinwiddie - I think "value" is a subjective fact. It, of course, begs the question of whose value takes precedence. Brian Marick in response to Mike Hill - different words have different favorite tricks. "Value"s favorite is making opinion look like measurement. Brian Foote - "value" shines at not sounding like a waste of money. "business" too. Whereas, anything with "re-" in front of it sounds like a wasteful do-over. Refactor, Revise, Repair, Reengineer. Mike Sutton - re-birth, re-new, re-'why can we compete with the latest blah?' revisiting the old is a fact of life, we should embrace it.

Carlton Matthews - when you are not living the life you dreamed you tend to envy the lives of others.

Daniel Elliott (via Bob Martin) - Cope suggests a surgeon who has washed his hands still needs to concentrate on the scalpel (or architecture in our case!)

Dave Nicolette - Velocity is a measure of a team's capacity to deliver, not a measure of activity. But velocity depends on having fixed-length time-boxed iterations. For a continuous flow process, I prefer cumulative flow.

David Hussman - I find it interesting that software people tend to talk about "training" where educators talk about "teaching". Your thoughts are welcome. Ron Jeffries - training is possible, teaching is not. neither word is good. one can, at best, provide an occasion where learning is possible.

Delavigne & Rob (via Glyn Lumley) - "We want to get Deming off the quality shelf and have him recognised for his contributions to a unique philosophy of life"

Derek Wood - Any accommodation we make to doing Scrum well is indicative of an impediment that will need to be resolved at some point.

J.B.Rainsberger - Irony alert: Most organizations learning Scrum are actually practising Waterfall in a manner quite similar to what Royce intended.

Jeff Patton - Is the "definition of done" actually a "definition of built"? "Built" is when I get software, "done" is when I get benefit.

Jonathan Bach - As a manager, my mantra always is: "You may report to me, but really, I work for you."

Jonathan Bach - Scrabble analogy #1: Rarely can your most valuable test ideas (letters Q&Z) be easily put into words. Scrabble analogy #2: Sometimes a test (a word) has more value when it's placed on the boundaries (triple word score). Scrabble analogy #3: You get a bonus if you use all 7 letters to form a word (diverse techniques in one test is powerful).

Jonathan Bach - There are no certified musicians, but we know skilled ones from unskilled ones. Still, execs just want sheet music, not the sound.

Joshua Kerievsky - Faster velocity != better software development. Velocity metrics are a powerfully distracting illusion. Story point estimation is a confusing waste of time. Discussion, feature fat removal, bargain hunting are way more useful.

Jurgen Appelo - Separating process (Scrum) from development (TDD etc) is a fine example of loose coupling. Developers should appreciate that.

Mark O Oakes - A company's ability to collectively learn faster than its competitors may be only sustainable competitive advantage

Mary & Tom Poppendieck (from Leading Lean Software Development) via Jason Yip – It is the overhead incurred to enable auditability that induces the waste, not the standards themselves.

Mary & Tom Poppendieck (from Leading Lean Software Development) via Jason Yip – Randomly giving patients medication until they get better would not even be considered. And yet, we randomly give our work processes medicine, adding on more and more 'best practices,' until the processes seem to get better.

Mary & Tom Poppendieck (from Leading Lean Software Development) via Jason Yip – The advantage which a commander thinks he can attain through continued personal intervention is largely illusory. By engaging in it he assumes a task that really belongs to others, whose effectiveness he thus destroys. He also multiplies his own tasks to a point where he can longer fulfill the whole of them. (actually a quote from Helmuth Von Moltke)

Matthew Heusser - my Fathinlaw, a quality engineer at Ford, once told me the quality engineering discipline existed to product cmpny from execs

Michael Bolton - Often enough, bugs aren't mistakes. Sometimes they're differences of opinion, discoveries, dilemmas, etc.

Mike Sutton - i just got reminded of something that i forgot - thank you @netparr - agility is *not* about getting everything right, but being able to respond to them quickly and correctly when they go wrong.

Nancy Duarte (via @johnnieb99, via Brian Stallings) - "If a slide contains more than 75 words, it has become a document."

Naresh Jain - Increasing velocity is one thing and making your team more productive is another. Don't confuse one for another.

Naresh Jain - Instead of asking how much its going to cost & how long its going to take, ask with 2 ppl for 2 months what can I get?

Rosabeth Kanter - Change is a threat when done TO people, an opportunity when done BY them.

Scott Adams (via David Hussman via maiasylba) - Creativity is allowing yourself to make mistakes. Design is knowing which ones to keep.

Steve Jobs (via Scott Williams) - Your time is limited, don’t waste it living someone else’s life.

Steven M. Smith - Effort chases measurement. Measurement chases the discussable. Core org diseases aren't discussable. Diseases elude cure (effort).

Tim Ottinger - Axis: simple<---->complex is a count of structural parts & linkages, unaffected by naming, syntax, obviousness of solution. Axis: clear<----->perplexing is a measure of how easily one may comprehend the solution, aside from structural parts/linkages. A very brief routine may be simple and clear, or may be simple and cryptic. A long routine may be complicated and clear, or may be complicated and impenetrable. We find a certain synergy working in our favor in short, clear, simple routines. I would go so far as to say that brevity with clarity = elegance.

Even Newer Set of Quotes from Twitter

Been far too long since I lasted posted anything, but there was a lot of moving going on in December and some other things so far in January.  More moving is left, but I am going to promise to post more often.  However, as I have another collection of quotes from folks on twitter, I thought I'd put them out before the list gets too long:

Alan Shalloway - a process tells you to fix your problems is different than a process that gives you information on how to fix it.

Alan Shalloway - There is a big difference between eliminating waste & not creating it in the first place.

Alistair Cockburn (reported by Biran Marick) - Remember talk from about "micro-techniques". If I recall right, he said his observation of ppl like @kentbeck and @wardcunningham was that they gained great speed by doing many small things extremely well and quickly. Alistair Cockburn - Right & I could never develop that idea because micro-techniques come in xtremely context senstitive bushel-basket-loads not onezies.

Bob Marshall - Imo Red Bead is profound because it has many layers; vain hope; delusions (all round); (false) pride; introspection; etc. Don Reinertsen - Profound and possibly dangerous. It intentionally creates a situation where the player's actions have no effect on outcome. Bob Marshall - Yes. But that's kinda the point, really? From Deming's perspective... Don Reinertsen - To some extent players are taught to accept variation rather than improving the process. (e.g. batch size reduction) Bob Marshall - Yes. But that's reality for most orgs and most workers. Variants on Red Bead can explore more "enlightened" scenarios. Don Reinertsen - The game certainly proves the methods Deming dislikes won't work. It also incorrectly shows SPC doesn't help outcomes. I think it would be more profound if outcomes had both controllable and variable components. Teach the middle way... Bob Marshall - For me, Red Bead is very Zen, in that it's point is left for the participants and audience to draw out themselves. I concur Red Bead fails to show benefits of SPC: In coaching, "ARC" reminds us Awareness -> Responsibility -> Commitment. I participated in an enlightening 15min workshop at Agile 2008 with teams and dice that could show SPC well (!RedBead). Karl Scotland - Red Beads useful to change thinking on purpose/demand/outcomes. Intentionally exaggerated scenario is powerful.

Bob Martin - humans test creatively. Machines test reliably. Both are vital. Confusing the two is disaster.

Carlton Matthews - overheard someone use this quote, "Don't ask me to cook dinner if I can't buy the groceries"
Daniel Lapin (via Carlton Matthews) - The complacent are always conquered by the committed and the diffident are always defeated by the determined.

Dave Rooney - Fair enough... knowledge is indeed power. Scott Duncan - And applied knowledge is powerful. I think more people know what to do than do it. How to transmit belief plus knowledge?

David Anderson - in next decade aim to change focus to "manage rules of game" not "manage work" or "manage people" - Deming system design.

Don Reinertsen (on “value”) - Economic view also allows Gilb's subjective dimension. A thirsty man will pay more for what is objectively the same water.

Gary Hamel (from a retweet by Bob Marshall) - "In the absence of purpose, only thing that will disrupt the status quo is pain." http://tinyurl.com/yjes5zn

Jeff Bezos (via Jason Yip) - There are two kinds of companies, those that work to charge more and those that work to charge less.

Jochen Schuchardt - We sometimes equate project mgmt with the visible planning artifacts. But the heart of it is people and relationships.

Johanna Rothman (from her blog, ptd to from Twitter) - good interviews should make a candidate (and an interviewer) think, not sweat [preceeded by “Good interviews do not surprise people. Good interviews build rapport with a candidate, learn about a candidate, preferably with behavior-description questions and auditions. Maybe with hypothetical questions. Maybe with a meta-question.”

Jon Bach - FB is an album for friends, Twitter is a coffee shop for colleagues.

Kent Beck - there's a world of difference between telling me what to do and helping me learn by telling me what to do.

Max Planck (via Michelle Sliger) - A new scientific truth does not triumph by convincing its opponents and making them see the light, but rather because its opponents eventually die, and a new generation grows up that is familiar with it.

Michael Feathers - I still think the best way to predict the future is to have friends in time zones ahead of you.

Michael Feathers - If you want to learn from experts listen to their questions more than their answers.

Ralph W Emerson (Via Alan Shalloway) - "As to methods there may be a million and then some, but principles are few. The man who grasps principles can successfully select his own methods. The man who tries methods, ignoring principles, is sure to have trouble."

Ramsey Show (via Carlton Matthews) - "Savings has to be done on purpose. Debt can just happen."

Rob Myers - so the msg could be "slow down for quality & use quality to speed up"

Ron Jeffries - If we write a great tester's tests before even writing the software, and ship when they run, have we found or prevented defects?

Ron Jeffries - It is becoming clear that w sufficient disrespect, sarcasm, recalcitrance, we can stop any/t good from ever happening again.

Roy Atkinson (via Noami Karten) - If each of us holds up a little bit of the world, it will weigh none of us down.

Scott Duncan - Change may be hard as 1 change often causes/requires another, then another. What looked like absorbable change cascades.

Scott Duncan - I think we can/should talk about both what is valuable to do & how best to do it. Being clear about what both mean. Don't see a need to create a dichotomy between the what & how as long as we realize the latter serves the former. Perhaps an uber-value [is] "We value being clear about what is important to accomplish over how we achieve that end"?

Seth Godin (not from, but pointed to from, Twitter) - Organizations thrive on their ability to allow individuals to remain faceless. It permits them to act badly, not in the interest of their customers.

Skip Angel - Decided that bug repositories are evil. Gives teams excuse 2 defer defects not show-stoppers. Don't all bugs cause workarounds 4 team/users?

Skip Angel - While #scrum is based on empirical sys 4 learning, u must have values & principles 2 guide ur learning. Agile Manifesto does that. Chris Sterling - agreed. I am more interested in teams learning & changing rather than being "right"; a team will get better when focused on both.

Stephen Parry (via Grant Rule) - "If you measure your business using averages, don't be surprised to find yourself running an average business.”

Tobias Mayer - IMO waste is defined as 'work that adds no value for any stakeholder' (others restrict to 'for customer'). Much refactoring is waste ie rework.. due to commiting too early. Lunch breaks are not work, hence not waste.

Tobias Meyer - Are agreements the same as rules, & if not, what's different? I've always found group rules to be unnecessary, in fact detrimental. Dale Emery - Agreements come from people who agree. Not all rules come from (explicit, negotiated) agreement.

W. Edwards Deming (Via Glyn Lumley) - 'Examples teach nothing unless they are studied with the aid of theory. Most people merely search for examples .. to copy them'

Ward Cunningham - Estimating is the non-problem that know-nothings spent decades trying to solve.