Yet More Quotes from Twitter

A third installment of interesting things I've captured from Twitter that people have said (including some of my own) either individually or as part of a thread of discussion (again sorted by first name):

Alistair Cockburn (not from Twitter but mentioned on it) - Management tells the workers to mutiny. The workers refuse. (A koan for agile development)

Andrew Meyer - The People, Process and Technology triangle, to me, is about balancing a path to successful execution of a project. Value is about determining if a project should be done.

Andrew Morgan - Be fearless with your day. Show up bold. Show up on purpose. Love every minute of life today. (Repeat daily until death)

Ben Rady - The first rule of productivity is accepting the fact that there are valuable things that you will just not have time for.

Benjamin Mitchell - Challenge of #kanban in s/w dev is to manage overlapping activities (analysis, dev) that may start work with partial information. Vasco Duarte - That's the exact same challenge that all processes face. #kanban is no exception. In #waterfall that was just ignored. #agile Benjamin Mitchell - Good point. It's also a difference when applying 'Lean' approaches to Prod Dev and Manufacturing. Goal of Prod Dev is to generate info. (which requires variation) to assist in making best future economic decisions so 'rework' can be ok. Goal of manufacturing is to produce within acceptable variation. Rework is generally waste. So depending on your view of s/w dev (manufact or prod dev) you'll take a diff view of managing 'rework'. My #kanban board surfaces this.

Bob Marshall - Is there any chance we can forego the "waterfall" epithet in favour of the more descriptive, objective, term "batch and queue"?

Bob Martin - to be a professional, you must not rush. keep your code clean. So clean it barely needs comments.

Brian Button - Is the most important skill in facilitating retrospective the ability to hear what isn't being said?

Dan Whelan – The Fifth Discipline and #systemsthinking has me thinking that agile/lean focuses too much on short-term value. Need to build learning orgs.

David Anderson - I find risk management is poorly executed. This is why I am going after it next as a root cause of #agile adoption failure. J.B. Rainsberger - Do you find risk management a sizable bottleneck? From here, it looks like not focusing on value limits everything. David Anderson - value is a complex notion. Board room wants predictable ROI more than revenue or profit maximization. if you ask "would you like more value?" answer: "yes". if you ask "would you like more value at risk of less predictable outcome?" answer: "No!" #agile appears to give less predictable outcome as traditional gives (false) impression of predictability. Hence #agile == risky! to remove this impediment we must show that #agile manages risk better than traditional to deliver more predictable outcome. J.B. Rainsberger - For most teams, most of the time, volatility of the cost of features depends on the design. Improve the design, less volatile. David Anderson - if you are using design to include analysis classification and architecture then i agree with you. Lean product design uses analysis classification & product architecture to design for variability/volatility. J.B. Rainsberger - I consider "architecture" simply to be design-in-the-large, and I don't know the term "analysis classification". I more mean that the crappier the design, the more the marginal cost of a feature depends on the state of the design.... Dan Whelan - I think of architecture as design decisions that are expensive to change. David Anderson - agree architecture is design-in-the-large. good analysis can classify functionality into areas of the design.

Deborah Hartmann Preuss - Toyota competency levels:: Assisted, Independent, Can make changes, Coach. #AgileOpen Thx! I like those levels!

Declan Whelan – I've had negative comments from mgrs and teams be de-motivated by unrealistic diagonal lines on burn-down charts. I do see the value of line in highlighting continuous flow. I find the shape of real actual curve sufficient for this, i.e. focus team on making curve flatter rather than having curve track to some ideal line. Deborah Hartmann Preuss - I have teams reflect on their own sprint "signatures" over time - improving? repeating same mistakes? Aim is consistency. I find that sprint burndown w/o task board is much less useful (& less used). If had to choose: task board. Lisa Crispin - I'm not a fan of burndown charts. Prefer task or kanban type board, visually you can see what tasks/types remain to be done. Scott Duncan - "focus team on making curve flatter" Flatter relative to what? Wouldn't that be some baseline even if it isn't drawn on the graph? "unrealistic diagonal line" I spend time coaching/training on what lines means, use of burndown, etc. Haven't had the issue. Declan Whelan - Flatter in that tangent of curve remains constant - i.e. only relative to itself. Perhaps splitting hairs ;).

Elizabeth Hendrickson – (On exercises about learning to learn) Simple & meta: have groups work together to solve a puzzle of some kind & debrief how they learned?

Elizabeth Hendrickson - Many have said this before. I'll say it again anyway: Source code, like inventory, is a liability, not an asset. Dave Rooney - Not sure I agree. Source code that hasn't been shipped to production is indeed inventory. Afterwards, it's documentation. Brian Foote - Tell us more. It would follow then that you feel that reusing source is like reusing diapers, noble sounding, but impractical. Chet Hendrickson - Good code can be a capital resource. 1 that allows us to build things of value. But it must be treated as one otherwise... Elizabeth Hendrickson - Consider: mgr insists on keeping 1/2-done feats in code base despite drag on productivity b/c they're "too valuable" to toss. Chet Hendrickson - reminds me of my grandfather's box of broken electric drills. He didn't need a new one, he had 5 already. I don't think it's all that audacious. Consider inventory as liability from a manufacturing perspective: http://bit.ly/YvQ1d.

Hillel Glazer - Consultant <> Contractor. Ensure you're being hired as a consultant, not a contractor, are you there to create outcomes or outputs?

James Bach - They way to kill curiosity is to *force* other people to learn what you think they will someday need to know.

John C. Maxwell - People change when they: HURT enuf that they have to; LEARN enuf that they want to; & RECEIVE enuf that they're able to.

Joshua Kerievsky - Low-grade sausages contain stuff you don't want to know about just like low-quality software.

Kathy Sierra - "self-promotion" need not be literal. Want people to see you're good at X? Promote "learning X" or "others I helped do X" or simply BE... X

Kathy Sierra - Clarification on word "useful": it does NOT rule out entertainment or tweeting your lunch menu. Making my day even .0001% better? Useful.

Kathy Sierra - Good directions to your house include how to know I'm on the right road and how to know recognize when I'm not (& what to do about THAT).

Lao-tzu (via Bob McNeal) - Different perception?... What the caterpillar calls the end, the rest of the world calls a butterfly.

Larry Weidel -There are LAWS, PRINCIPLES, and PREFERENCES. LAWS are ALWAYS true. PRINCIPLES are USUALLY true. PREFERENCES are up 2 U.

Michael Bolton - @cory_foy "OH: 'We just need to go faster'" No, no! Work smarter! No, no! Work harder!

Michael Bolton - If the last question is "Am I okay with having no more questions?", then you're done. If you're not okay with that, you're not.

Michael Bolton - Testing is what you do when designing a check, interpreting the result of a check, and learning. Spell checkers *help you test* spelling. J.B. Rainsberger - Here's a clue: automated "tests" replaced the error-prone "guru checks output" anti-pattern. The clue is right there. Michael Bolton - Not always. You DO need a guru (programmer, tester, business person) to design and interpret the results of the check. James Marcus Bach - Non-sapient work can, but not necessarily should be performed by computer. Checking is a poor substitute for testing. In general, when checking substitutes for testing, bad outcomes happen. But it has its place. Regression CHECKING != regression TESTING. Latter /investigates risk/ of change-related failure, requires *new* tests. Michael Bolton - You can call unit tests and ATDD "tests" if you like; I don't mind. But if you only *check* your product, you may not be *testing* it well. Testing is explorative (probing) & learning oriented. Checking is confirmative (verification & validation of what we know.

Michael Bolton - The problem with maturity models: they assess "maturity" on based conformance, instead of independence and adaptability.

Michael Bolton "Don't mistake requirements document for the requirement. Don't mistake process manual for the process".

Michelle Sliger - The importance of facing the truth and saying Yes 2 reality, then no 2 denial.

Mitch Kapor - "Is the good enough the enemy of the barely ok?" Brian Foote - Nope. The barely ok is the enemy of everything.

Paul Dyson (via William W. (Woody) Williams) - "Scrum Masters remove impediments, Project Managers prevent them occurring."

Serge Beaumont - Agile is techniques at the Shu level, a framework at the Ha level, and a culture at the Ri level.

Skip Angel - Coaching = Not afraid 2 pull off band-aid of workarounds 2 expose infection of problems under surface. May hurt but needed 4 org's health!

Steve Keating - When we throw mud at others, not only do we lose a lot of ground, we also get our hands dirty.

Steven Keating - People don't buy your product for the value you put into it. They buy it for the value they get out of it. Sell that way!

Steven Keating - People quit leaders not companies. If you lose employees you don't have an employee problem, you have a leadership problem.

Tanmay Vora - One of the biggest challenges for "Human Resources" is to do justice to "Human" part of it and not get into routine policies/processes!

Tim Ottinger - An expert is a person who knows what all the mistakes look like, and that you don't have to make them.

Vadim Zaytsev - Optimist: the glass is half full. Pessimist: the glass is half empty. Engineer: the glass is twice the required size. Tim Ottinger - _COST_ACCOUNTANT_: glass is too large, Engineer: glass has 100% safety margin.