Monday, February 15, 2016

Back to Basics

While I have been working exclusively for one company since my last posting, I have been watching the industry, attending Scrum Gatherings, following people I've known over the years, listened to a lot of webinars, and generally tried to keep track of what's been happening.  I am more and more convinced because of this, and the independent consulting I did for years before my current job, that too many people who have become engaged in some form of Agile transition, were either not shown the meaning of the Agile Manifesto's Values and Principles or quickly bypassed them in favor of practices ("doing Agile")..

It's not that I'm claiming to be some magnificent authority on the Values and Principles, but you need not be a genius to recognize behaviors that are clearly antithetical to those ideas.  Without understanding those Values and Principles, it's just too easy to "tailor" recommended practices in such ways that either clearly miss the point  or so rigidly "interpret" them as to exclude useful implementation.  So I'm going to even more firmly structure my future coaching and training very strongly toward why before any what and how.

I know people want the latter things a lot and I am not averse to telling them about good examples of practice that I have observed.  However, I'm going to resist working with those who want to skip the why.

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.