Wednesday, September 28, 2011

“People Don’t Shop for Organizational Change”

I was talking about coaching experiences yesterday with Skip Angel.  I said that I try to get management who feel they want to implement Agile practices to understand that, before too long, they will need to face organizational, not just team practice, changes.  At one point in our discussion, Skip said the phrase that is the title of this blog and he is quite right. When management starts to look for improvements in their product development efforts, they usually do not put out RFPs for organizational change.  Someone normally decides, based on peer discussion or reading, that some method, technique, practice, etc. seems to be working for some other folks and that it might be what they need, so they ask for something along those lines.  Something like Agile, for example.

In this regard, Agile “transformations” are no different than the organizational efforts in the 80s and 90s to implement ISO 9001, CMM, ITIL, COBIT, etc.  That is, small changes at individual or team levels are possible, but the real benefit of pursuing any of these is to look at their impact organizationally.  Even when companies do this, there seems to be the feeling that the desired improvement will occur with minimal impact, i.e., with little actual change required.

This usually results in attempts to immediately “tailor” the chosen approach and produce a “hybrid” version of what has been selected.  The reasons for this are varied, but seem to boil down to organizational (un)readiness for the change the approach asks be pursued when it expands beyond team/functional area impacts.  This, in turn, is often manifested by team level training that focuses on practices and techniques without conveying what I believe to be an understanding of the values and principles behind the practices.  The resulting tailoring and hybrid practices can then miss the point of the originally recommended practices, often losing the impact intended.  At some point, people begin to wonder why the desired improvements are not happening or happening fast enough or at the level of impact desired/expected.

I think one reason organizations ending up in this situation is that they, indeed, didn’t start out “shopping for organizational change.”

Saturday, November 27, 2010

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é.]

Friday, November 26, 2010

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]

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.

Thursday, November 4, 2010

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.

Monday, June 28, 2010

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.

Sunday, March 14, 2010

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.