Agile Feeds

Courses

Fri, 24 May 2013 09:07:55 +0000

Courses available by request only

Advanced Agile class
Writing Effective Use Cases course (discussion: Re: Writing Effective Use Cases course), in 2-, 3-, or 4-day versions.
Steps to an Agile Frame of Mind course, in 1- and 2-day versions.

OO Analysis and Design course
Crystal Clear full-day tutorial
Software engineering in the 21st century

Re: DAKA: The Design-as-Knowledge-Acquisition Movement

Fri, 24 May 2013 09:02:08 +0000

I miss Jeff in this list and Alan Cooper who are both very important from the UX design part. And I think they both said similar things for a few years.

-by YvesHanoulle on 10/18/2011 at 3:53 PM

Hi, Yves! If you can find me some references of either of those two saying anything specific about developing knowledge in or during design, I’d love to quote/include them here. if I ever see Jeff Patton again at a coffee shop in SLC, I’ll ask him for the long version.

Excellent references, thanks!

The concept of design as knowledge acquisition has been explored quite often in the past 5-6 years in Carlo Pescio’s blog, especially with reference to the concept of Form from Christopher Alexander.

I see I can’t add hyperlinks, so here is the title of a few relevant posts:
http://carlopescio.com/2007/12/on-concept-of-form-2.html
http://carlopescio.com/2008/09/and-found.html
http://carlopescio.com/2010/03/where-is-your-knowledge.html

just to add a bit, Carlo is building a larger theory of software as a material to be shaped, the most relevant posts are under the NOSD label:
http://carlopescio.com/search/label/NOSD

-by Vic on 10/18/2011 at 5:50 PM

Hi, Vic, ... for URLs what people do is write the whole URL minus the http part… can you do that so we can get to those pages? thx, Alistair

eg www.carlopescio.com/2007/12/on-concept-of-form-2.html

Missing knowledge turns a task into a problem. Solving a problem is a highly iterative process with frequent target/actual comparisons. Each solution candidate which is tried facilitates learning and helps to gain more knowledge about both the problem and a possible solution.

A typical software project has lots of unknowns – understanding the stakeholders’ needs, finding useful features, finding a good technical implementation and even moving targets in terms of changing or lately discovered requirements.
So if one understands software development as problem solving, then it is quite clear why projects are about acquiring knowledge.

More on software projects from the perspective of knowledge work is here:
http://thinkproductivity.net/?p=156

-by Steffen Lentz on 10/19/2011 at 4:34 PM

The Design as Knowledge Acquisition Movement

Fri, 24 May 2013 08:59:08 +0000

This is a jump page for themes around “design as knowledge acquisition”
try also “DAKA” for short

There is a movement afoot, and it’s really exciting: the move to viewing design and development as “knowledge acquisition”. Most of this movement is taking place within software development, but some in business development, web development, marketing and others. I am very interested in how this will (or won’t) change how organizations behave.

see long form earlier description: Design as Knowledge Acquisition (discussion: Re: Trim the Tail)
and long form later elaboration: Disciplined Knowledge Acquisition in Product Development

but

knowledge acquisition curve.png (discussion: Re: Knowledge acquisition curve.png)

Here’s a brief chronology of the people and what they’re saying. I’m sure there will be some jockeying for position of “I said it first”, but this is what I’m aware of at this time, and somewhat in the order I encountered it:

1986 : Peter Naur wrote a little paper called “Programming as Theory Building”. I love that article, included it in my Agile Sw Development book in the appendix so more people will read it. I teach it in all my classes and many of my lectures.
1997 : Don Reinertsen’s book “Managing the Design Factory” talks explicitly about development as gaining knoweldge.
2000, 2003 : Phil Armour wrote a paper for CACM in 2000 called “The Five Orders of Ignorance”, and more in his 2003 book “The Laws of Software Process” about how software is a new medium for capturing and recording knowledge, and talks about how our knowledge and ignorance go back and forth during the software development process.
2006-2008 : In Agile Sw Dev 2nd ed, I wrote about unvalidated decisions as internal inventory, but didn’t know what to do with it – it wasn’t until 2008 when I put Jeff Patton’s trim-the-tail pattern into a knowledge perspective that I was able to make sense of what Don Reinertsen and Phil Armour were talking about. Now Design as Knowledge Acquisition (discussion: Re: Trim the Tail) is one of the five core elements of my advanced agile crib sheet, and included in nearly all my lectures and classes – I love this concept, because it gives really interesting risk reduction advice way out of the software field – it gives advice to companies, marketers, designers, everyone doing design and development of just about anything.
2010 : Dan North wrote a blog post called http://dannorth.net/2010/08/30/introducing-deliberate-discovery/ where he uses the phrase “deliberate discovery” to mean pay-to-learn as a deliberate software development strategy.
2010 : Michael Kennedy wrote about knowledge acquisition in his book “Product Development for the Lean Enterprise”. I haven’t read this book yet, but David Anderson credits listening to Michael for his epiphany…
2011 : David Anderson wrote a blog post called http://agilemanagement.net/index.php/site/comments/understanding_the_process_of_knowledge_discovery/ saying that he has settled on the term “knowledge discovery process” as “the thing around which we hang a kanban (WIP limited pull) system”, citing Michael Kennedy’s talk at the Lean Kanban Benelux 2011 conference.

Design as knowledge acquisition also scales to building businesses and business initiatives.

2005 : Gary Steven Blank published “The Four Steps to the Epiphany” about developing the customer before developing the product.
2011 : Eric Ries wrote “The Lean Startup” using deliver-and-learn ideas at the corporate level for startups. The deliver-and-learn cycle looks like it comes from agile, but it fits much better with design as knowledge acquisition, in terms of having explicit learning goals.

I’m not so fussed about the time sequence, I am absolutely excited about the number of people now making deliberate study of what we can learn by studying design as a knowledge acquisition exercise. That makes now at least 8 notable speakers going around and stressing this concept to their audiences and clients.

Design as knowledge acquisition is, for me, finally, the wave that follows agile development. Agile development highlighted two things: develop incrementally and get feedback from it; and work collaboratively. Design as knowledge acquisition does not address the people part – we still should reread the agile manifesto for that, and don’t lose it – but it provides many more interesting strategies than mere incremental development does. It calls out strategies that violate the simple (eg) Scrum and XP rules of “prioritize, develop, deliver”, and name much more subtle moves that a company or team can use to improve their results.

This is now a movement, with so many different voices discovering and saying so much the same thing. Let’s keep an eye on it and see where it goes. ....

Alistair

postscript: I want to re-emphasize the absence of people in the DAKA perspective. DAKA is all about strategies.

I went back and counted in the talk A short theory of designing in teams.pps (discussion: Re: A short theory of designing in teams.pps) – half (2.5 of the 5 sections) are about strategies and half (2.5 – I split cooperative game into half/half) are about people. I think that’s the right balance to pursue. DAKA is one of the 5 chapters, and a great one, yielding great strategies. I would like to make sure we don’t forget the people side of the story as we dig into strategies.

(actually: even DAKA has “social risk” as one of the four risk/knowledge areas, so even DAKA calls for attention to people)

Re: A user story is to a use case as a gazelle is to a gazebo

Thu, 23 May 2013 20:49:37 +0000

My one liner is that a story is a promise to have a conversation and a use case is the record of the conversation. If you think you need one. —JimStandley

Very nice. —Alistair

I hate to admit to being a star struck rube, but I got the chance to say that to Grady Booch and he smiled. Made my day. —JimStandley

“Because both begins with b.”

-by Seannemo on 08/04/2008 at 1:20 PM

Nice answer, SeanNemo! Except that “both begins with a b” misses the point – what you more likely mean in “Because each begins with e.” :). Thanks, Alistair

One of my collegues just said:

A Use Case is a way of describing requirements. A User Story is a way of prioritizing work.

Tim

-by Tim Wright on 2/2/2009 at 6:53 PM

User Story is simply, a user’s story. It is business ppl’s version of describing the world, their way of “starting an idea”

basically starting a conversation (requirements elicitation) of whether their idea (to get some business benefit) is

feasible?

Stories should be simple and business-focussed, because when faced with complex things which make profit & loos look like a

gamble, human mind always wants to cut through all crap and see things in simple and convincing way.

“Divide & Conquer” the most intuitive of human manipulation skills can be applied with Stories so you can break or merge

stories as well.

Let the “user” (the business man) freely express his idea, uninfluenced and undeterred by “system-hardened” developers.

Once he has spoken completely, which means the Story has been written (in say half an hour), then is the time to “start the

conversation” which means start scrutinising the idea, check its feasibility, uncover missing links/detail, design, plan and

when sufficient confidence and consensus exists, make it a decision. The Story can undergo some changes, but still is in a

format that is simple. It is better if it restricts to WHAT and not tries to do HOW.

System ppl or Techies model a complex “real world” into a virtual software world for manupulation, so they will have to

analyse the Story to death. Basically as the software does not have a mind of its own, it needs to be told everything

preciserly and hence what is very simply said in a Story then has to become elaborate and formal so that it can be

implemented.

Welcome to the realm of Use-Cases. Systems folks will have to analyse and carry out “thought-experiment” and conceive how

their system (black-box) should precisely work in order to realise the agreed Story. And Use-Cases are a very effective tool

to do that.

1 User Story can relate to 1 or multiple Use-Cases. And they may realte only to some parts of these use-cases,

simultaneously (they are being written by someone who doesnt know what use-cases are)

If there is a science of Modelling a real-world in abstract way e.g. Software then -
it will perhaps say Use-Cases is what will happen to the system in consideration.
Thus Use-Cases are the “Stories” of that System, when viewed with the business benefit.

So fundamentally given a concrete system definition, finite actors and Business Logic Rules that dont contradict Computation

Theory, there is a finite (but large) set of possibilities that can occur and they group together as Scenarios and

Use-Cases. Use-Cases are something really fundamental, but only when considered from a Modelling perspective.

But surely when Stories are written all these complex thoughts cannot be factored in, and not required as well, lest

Business ppl will lose the focus. Also Business ppl dont have that expertise or outlook and why should they? 1 Human Brain

cannot do all these varied things in reasonable time. Thinking about everything at once is only a fantasy.

If Business ppl were “system-intelligent” then they would write User-Stories that perfectly mapped with Use-Cases or could

write use-cases themselves. Then systems ppl are not reqd to be “domain-intelligent” they need to be just dumb coders. May

be robots could do the coding job!!!

Thankfully or otherwise that is not tru. In reality, its actually a team-effort: Business ppl with business intelligence,

Technical ppl with system intelligence.

Yes maybe with training and experience, Business ppl can write good stories that are more prone to be easily mapped to the

systems, but that is really a bonus.

THUS USER STORIES AND USE CASES IS A QUESTION ONLY FROM SYSTEMS’ PERSPECTIVE, THE “USER” ONLY KNOWS “USER STORIES”. IT IS

NOT THE SAME AS USE-CASES AND ARE NOT THE MEANS TO DO SYSTEMS ANALYSIS, THEY ARE JUST AN SIMPLE ABSTRACTION OF USE-CASES FOR

BUSINESS USERS.

YOU NEED BOTH!!!
-by Nikhil Shah on 3/5/2009 at 12:58 PM

I was involved with a project recently where User Stories where adopted but this approach was failing because user stories were written as a high level requirement but the idea that no lower level requirements were required as a ‘user story is just a reminder to have a conversation’ was adopted.

Therefore just before a sprint the lower level requirements had not been gathered leading to vague acceptance criteria at wrong level.

I became involved and could not put user stories into any context and was aware something had to change as peoples perception of user stories was that that they only needed to do so much….so I split the entire development into a use case survey and we delievered fully dressed use cases using rational template for the next sprint.

The development team were really happy with use cases as gives context and info but also wanted user stories just as a mechanism for story point planning and to give them something more meaning than ‘Use case XXXX Alternative Flow 1’ to write on cards to blue tack to the scrum board thing.

The development team simply took each main flow and alternative flow of each use case for the next sprint and created a seperate user story for each and deemed that the acceptance criteria are the requirments within the use case narrative.

The backlog therefore consisted of use cases flows, each flow given a user story description ‘As a xxx I want to xxx so that xxx’.
And use case functional requirements listed as acceptance criteria, that must be considered [tested and fixed or put into backlog for future sprint] in order for the sprint to be accepted.

This rule seemed to work for functional requirements in majority of use cases – there was the odd use where the basic flow was broken into more than one use story [debatable whether the use cases should have been split really!]

Non functional requiements were added as seperate user stories as no use case conversion was required.

This approach seemed to work and now I am wondering whether use cases are better [add more context] or user stories…..... or use both [as we did]....but the big lesson learned was that the detail you need [in my opinion] before you start a sprint, is the same whether you use ‘use cases’ or ‘user stories’....you need to think of the user story acceptance sriteria as the lower level requirements that you would describe in a use case narative.

Do people agree – some people still argued that we went too low in detail and that the lower level stuff can be sorted out during the sprint but I strongly disagreed [based on failing sprints].

I am now on a new project and people are asking what level of requirement detail do you need before a sprint and should use cases or user stories ior something else be used – I keep saying you really need to nail the lower level requiremnents [what must be delivered and tested – acceptacnce criteria] before the sprint starts but live up to the spirit of agile….. if requirements change or have been missed during the sprint then behave in a flexible manner. However people have argued that this is not agile? Any thoughts?

My thoughts are that you need to be looking at lower level requirements for the next development sprint while the developers are developing the current sprint but also make yourself available for questions about requirements in current sprint [although product owner may be doing some of this?]

What are peoples thoughts? I am no expert just speaking from some experiences.

thanks

-by MBlack on 4/23/2009 at 3:35 PM

I think of a user story as an applied form of a use case.

-by Rick H on 5/31/2009 at 11:58 PM

In context of BDD I see a use case and a story similar in the sence that they both define the behavour of a system. And in defining a system I always keep that 1 to 1 relationship (attach the story to the use case).

-by http://twitter.com/derekgardiner on 8/24/2009 at 1:50 AM

I think it’s always kind of amusing watching people who don’t like formalized processes (I am not saying anyone here is guilty of that). When presented with a very simple thing, like “you should write a sentence on a card with a very specific phrasing”, they go nuts and say “this is much better than all previous ways, we’ll do this”. And before you know it, they’ve invented additions to the mandatory phrasing. Just wait a year or two, and you’ll have a huge and cumbersome process. Then wait another month and someone will surely have a brilliant idea about doing things in a much more simple way instead.

-by enolf on 11/26/2009 at 7:03 AM

I think user story is one of many scenarios of use case

-by Vitaly on 12/15/2009 at 11:44 AM

MBlack worries about “is this not agile?”. I would answer, it is agile for as long as the sprint has a sensible length, and the decisions about what goes into the sprint are made as it starts, not according to the master plan written by God. The only thing I would disagree with (pedantically) is the separation of the sprint, and the action to “nail the lower level requirements”. From an agile perspective, surely the people who carry out the sprint are involved in nailing the lower level requirements? If this is true, this is simply the first phase of the sprint. It doesn’t want to happen in a different time and place.

-by Alvery on 2/9/2010 at 12:35 PM

User Story is to Use Case as a sales order is to a blueprint.

-by John on 2/10/2010 at 9:53 AM

User Story is to Use Case as a sales order is to a blueprint.

-by John on 2/10/2010 at 9:54 AM

Nice, Sean, but “Each begins with e” is better.

-by Alistair on 5/1/2010 at 3:01 AM

Another answer is that you can fit a gazelle inside a gazebo …

(Try searcing Google Images)

just as you can fit a user story inside of a use case.

And in both cases, the inverse would be cruel.

-Ted.

-by Ted Husted on 5/6/2010 at 9:57 AM

:-)

-by Alistair on 5/6/2010 at 2:38 PM

Greetings from little old New Zealand…Wow! This is a very amusing blog Alistair! I am a new BSA fresh out of Uni. Never done agile, but very keen to soak up what I can. Thanks Ted, your explaination really has helped :)

-by BabyBSA on 6/7/2010 at 9:36 PM

Context is everything in communications, isn’t it?

Ted’s comments above are right. But so is the opposite (not the gazelle scenario, the case/story one.)

Case in point:
User Story
“As an engaged reader I want to be able to leave comments on Alistair’s blog so he gets quality feedback from intelligent and erudite readers.”

Use cases
User will
1. Leave a name (Mandatory) because we like to know who is saying what
2. Leave an email address so Alistair can contact the poster
3. Leave text comments
4. Human verification to eliminate spam

-by Craig Brown on 7/12/2010 at 8:56 PM

Re: Craig Brown’s example.

I would express it as “many stories about a use case” (many gazelles in a gazebo), like this:

Use case: Allow comments on Alistair’s blog

User story 1: as a commenter I want to submit a comment and check my posting so that…(why do people leave comments?)
User story 2: as a poster I want to check comments as they arrive so that I can improve my understanding
User story 3: as a spammer I want to advertise my shoddy goods automatically so that I can….

-by Bob Corrick on 7/13/2010 at 8:31 AM

I’m loving the way this “many gazelles in a gazebo” image is rolling forward !!! :)

-by Alistair on 7/13/2010 at 11:08 AM

I think most of the gazelle/gazebo confusion stems from the missing distinction between requirements and solution designs.

User Stories are a tool to manage (discuss/sort/estimate/validate) emerging requirements. Their main value is enabling a conversation.

Use cases are detailed design documents for designing interactions between actors and a system. Their main value is enabling development.

-by François Bachmann on 9/28/2010 at 4:50 AM

I can’t buy that distinction between requirements and solution-designs for the following reason: The moment you conceptualize the domain in a particular way (choose your actor types and entities, and decide to leave some out), you have started to design your model of the domain, which, in an O-O paradigm, is part of your solution. This is not an objective picture of the domain. (Read “Zen & The Art of Motorcycle Maintenance” for more detail on this.) So almost all of your high-level requirements will be hung on the framework of your designed model of the domain. And any detailed-level requirements will be stated as requirements of components of your system i.e. requirements of components of a solution under design. That’s design work.

Whether some specified attribute of a system is a “requirement” or a “design point” is a matter of agreed attitude toward the attribute. And that is a matter of negotiation and taste. There is a cycle of refinement of design, and at each level of problem/solution decomposition there are “required” attributes/behaviours” and “incidental” attributes/behaviours.

-by Eric Hawthorne on 9/29/2010 at 7:17 PM

I’ve found the distinction between user stories and use cases to be largely a matter of the level of formalism in the expression.

For user stories, not surprisingly, the emphasis is on the narrative description.

Use cases also have a narrative part, but also tend to encourage formal noting of preconditions, steps, and postconditions in separate sections.

Goal-Detail Hierarchy

In the story world, you can/should have a hierarchy of epic, feature, user story, where the stories will often correspond to a screen or two of ui and a single very specific user goal or sub-goal.

epic, feature, story arguably has a rough correspondence to
the SUMMARY (epic), USER-GOAL, SUB-GOAL, TOO-LOW use case goal-detail hierarchy attributable to A. Cockburn. (I’m guessing that’s you.)

—-

Where a user story describes something that is accomplished as a small sequence of storyboard screens, the user story tends to leave more room for UI design creativity, in that it doesn’t necessarily specify the exact sequence order of everything. So perhaps user stories are more appropriate than use cases when we are down at the specific-user-goal and sub-goal levels, particularly if we are talking human users.

If we are describing system-actors interacting, perhaps the increased formalism of the use case preconditions, steps, postconditions is more helpful than informal user stories.

-by Eric Hawthorne on 9/29/2010 at 7:36 PM

Many good ideas begin as stream of consciousness (read spontaneous) and are later refined into a coherent concept. A user story is a bootstrap for streaming consciousness and is used to elicit abstract details of a solution. The use case is a filter that often sits between the story and the design of a concept which is actually the technical translation of the non-filtered products from a use case. The permeability of the use case is often determined by the complexity of client’s needs as well as requirements throttling imposed by the client but governed by the development team. This is how I think of these terms; they are all connected, but some can be utilized independently or not at all.

-by Athelred Davis on 10/7/2010 at 3:46 PM

A user story is the “What” and “Why” and a use case is the “How.”

-by Diana Ost on 10/15/2010 at 2:24 PM

I’d say a user story is to a use case as a “quick start” guide is to a reference manual.

You just can’t tell from reading the “quick start” if there’s any more insight FOR YOU to be gained from reading the manual, but it can save you a lifetime doing so (plus save you from any “RTFM” comments). It’s left to the audience and their experience to feel where there’s more detail lurking behind worth investigation.

-by Dirk Schwammkrug on 12/28/2010 at 6:05 PM

how is a raven like a writing desk?
“poe wrote on both”

-by Edgar Allen Poe on 1/14/2011 at 12:11 AM

Oh, yes, I had forgotten that. Thank you for the reminder, Mr. Poe :).

-by Alistair on 1/14/2011 at 11:49 AM

I have just read this entire thread and think it is a good example of how, sometimes, the more you think about something the less clear it becomes.

I always thought that user stories were stories about the current system and you analysed them to find common problems/deficiencies that required work. If user stories are about the envisaged system as well then I’m a little confused. To add to my confusion I’m wondering where abstract and concrete scenarios fit in.

-by James MacManus on 1/24/2011 at 6:43 AM

We incrementally, iteratively detail use cases for the immediate purposes necessary. Overall scope relies on a primitive form, work planning/estimating on an outlined form, and —only if necessary— a detailed form may be written for development or test development.

What I wonder is whether stories may have two forms useful for us to capture what have been termed non-functional or quality attribute requirements: an early (Who What Why) form for scope and planning, then maybe, as needed a more developed for with acceptance criteria?

-by Skip Pletcher on 4/15/2011 at 11:42 AM

Good reading!
For me they serve different purposes. Use-cases describe the expected behavior of the system.
User stories are planning items. User stories are derived from user scenarios, where many user scenarios describe one use-case. Personally, I need the use-cases to get the big picture and to figure out how two user stories relate to each other.

-by milowe on 6/21/2011 at 4:46 AM

The key “crazy” agile notion is that we commit to a course of action for a few weeks based on business value before we know anything about what’s involved beyond a broad notion of abstract “bigness”. We trust that our feel for bigness will improve with feedback.

User story: Make it stop raining on my bed!

Backlog ordering: That’s really gross! We gotta do something about it sooner rather than later.

Sprint meeting: We’re gonna tackle it this round

Discussion with user: “There’s a hole in my roof” or “I wish I had one of those…”

Use case: Rain falls on roof and rolls down to gutter. Gutter carries water harmlessly to ground. Gravel provided to drain away from house…

Sprint backlog: Patch hole, add gutters, dig drainage ditch.

If we do more up front, it will only carry into our notion of the bigness of the bite we’re taking and a few notes on the back of the story. On the first implementation, we may tie a tarp to some trees until we can come up with a series of things we can provide, probably built around other stories, like keeping leaves out of the bed (walls), etc.

-by lupestro on 8/5/2011 at 12:35 PM

A User Story is an atomic User requirement, preferably a ‘business’ rather than ‘system’ requirement written by a user.

A Use Case is a prototype – albeit low in functionality and fidelity – written by an analyst.

There will typically be a one-to-many relationship (esp where stories relate to scenarios).

Back in the ‘70s Gane and Sarson observed “We have no way of showing a vivid tangible model of the system to the users. It’s hard for users to imagine what the new system is going to do for them until it is actually in operation, by which time it’s usually too late”.

A use case can be used by the analyst to demonstrate to the user that their requirements have been understood and provides a (logical, abstract) model of what the solution might be, running through scenarios that correlate to their stories. This can then be confirmed and validated by the user before handing over to the techies to realise.

I don’t see a problem in using both, User stories are as good a requirements elicitation and documentation technique as any.

-by Julian Cox on 8/18/2011 at 12:34 PM

They DO have a lot in common. Both can be:
– used to improve the quality of solution development.
– used in a requirements sense.
– written in a manner understandable to the users and from their perspective.
– used for estimation ( I sense use case points can be more robust than a game of poker).
– a unit of development. However IMHO use cases (as with RUP etc.) are likely to be a more cohesively considered chunk of functionality than a handful of user stories.
– used in both agile and fragile ways, despite whatever labels are applied to the process you may be using (suggest you re-read Agile manifesto every quarter).
– done poorly, where the benefits of their intent are then missed.

Use cases can also be:
– bound together into a cohesive model with the benefits of that holistic view
– used as strawmen to be critiqued (inc. model of the as-is)

-by Julian Cox on 8/18/2011 at 12:50 PM

Use cases can also be:
– bound together into a cohesive model with the benefits of that holistic view
– used as strawmen to be critiqued (inc. model of the as-is)

-by Julian Cox on 8/19/2011 at 3:38 AM

For me Diana nailed it last year.

A User Story summarises the user goal, what they want and why they want it. A Use Case elaborates how that goal may, or may not, be achieved.

To be mischevious surely any explanation taking more than two or three sentences isn’t “Agile”? :-)

-by Chris White on 10/28/2011 at 5:21 AM

Use Cases are told. But User stories happen.

That’s just like hollywood works: A great movie consists of the stage director’s instructions as well as the actors performing the story on stage.

As an actor, I need the stage director’s instructions so that I know how to perform my role. As audience, I pay for watching the actors performing the story.

... continous flow of value with focus on the customer …

-by nicole on 1/29/2012 at 10:08 AM

Definitely agree with Diana and Chris in that a User Story answers “Who”, “What”, and “Why” and a Use Case answers “How” with more detailed steps, pre-conditions, etc.

Some of the earlier posters seemed to suggest that a Use Case is “higher level” and is used earlier in the design cycle, and I find this a bit scary given that a Use Case is generally quite detailed and specific. Perhaps some people are getting Use Case confused with Business Case?

Ultimately, a team should use whatever tools make sense in whichever order works best. Terminology is only important insofar as it helps people work together without confusion, right? :)

-by Jeff Geurts on 9/11/2012 at 2:25 PM

I am coming across this same issue even today 9/28/2012. You think by now there may have been some “sane” thinking by the industry on this….Many clients are writing stories that look like use cases. I ask “how is that working out”? and get the answer a lot of what we write is duplicted from story to story.

Really? here is a thought (and my tag line) Use Cases are for documentation and Stories are for conversation…you want a document write a use case you want conversation start a telling a story.

-by Tony Ludwig on 9/28/2012 at 4:07 PM

Close: a use case is documentation, but the use case requires conversation, so: A user story calls for a conversation; the use case documents the conversation. Does that work for yoiu? Alistair

nice, Tony (Alistair)

-by Alistair on 9/29/2012 at 10:33 AM

A user story is to a use case as jello (OK gelatin) is to wet cement.

User story – it has a bouncy smushy,unpermanent-permanent shape (all technical terms). If it melts you can still drink it. You’re not afraid to have a collision with it.

Use Case – it can change, but you have to do it fast before it dries and it takes a lot of effort to overcome its inertia and friction. If you step in it you might be in it for a very long time.

-by dtekben on 10/1/2012 at 8:47 AM

:-)

A user story never includes what is going on behind the black curtain. A use case must include everything that happens on both sides of the curtain or the model will be incomplete and requirements will be missed.

-by Russ on 10/12/2012 at 5:41 PM

A user story is a shoddy shelter for a lazy person to reside. A fit use case elegantly and swiftly makes a point or two.

-by Robert P Ryan on 11/20/2012 at 2:23 PM

nice, thx :-)

A user story informs the builders of the system.
Use cases are tools to test all permutations of the user story modeled by the system – during and after building.

-by HellOnWheelz on 11/28/2012 at 11:19 AM

Four interesting posts in a row, Mr/Ms HellOnWheelz. Thx for watering here for a bit. :). Alistair

A User Story is their “Story”
A Use Case is the “Journey”

-by Neil Stansbury on 2/4/2013 at 8:44 AM

A user story demands questions.
A use case demands answers.

-by Salvatore on 3/5/2013 at 5:24 PM

I too am trying to understand the differences between use cases and user stories and so I’m glad I stumbled across this long-lived and informative thread.

As someone who is inexperienced in this field, I just wanted to make the observation that, while the analogies above are all very clever, real world examples (e.g. Craig Brown’s and Bob Corrick’s) seem to me a more effective way of demonstrating the differences.

I remain confused though. I’d love to read some more examples (“scenarios”?) from future posters…

-by Dave O on 5/23/2013 at 8:49 PM

Dealing with Windows Azure Storage transient faults

Wed, 22 May 2013 23:22:37 +0000

Preamble

When an application uses a service, errors can occur because of temporary conditions such as intermittent service, infrastructure-level faults, network issues, or explicit throttling by the service. These types of error occur more frequently with cloud-based services, but can also occur in on-premises solutions. Very often, if you retry the operation a short time later (maybe only a few milliseconds later) the operation may succeed. These types of error conditions are referred to as transient faults. Transient faults typically occur very infrequently, and in most cases, only a few retries are necessary for the operation to succeed.

The Transient Fault Handling Application Block (Topaz) lets developers make their applications more resilient by adding robust transient fault handling logic. It encapsulates information about the transient faults that can occur when you use the following services in your application:

SQL Database
Windows Azure Service Bus
Windows Azure Storage
Windows Azure Caching Service

This blog post focuses on Windows Azure Storage.

Retries in Windows Azure Storage Client

The Windows Azure Storage Client Library has supported retries for a while as an integral part of the API. Instead of wrapping each API call with a call to one of Topaz's RetryPolicy methods, you would set the storage client’s RetryPolicy property and execute the action directly. In fact, you would get retries by default, so in order to use Topaz's retries you had to explicitly override the default retry policy in the storage client.

Using built-in support for retries, if such support is available, is usually more appealing than using external support like Topaz's: code is terser, and the API has more information about the actual operations it retries so it can be more effective. With external retry support an entire operation needs to be retried, while retries managed by the API can retry specific requests within a single operation. Also, when the API might perform additional work after it has returned a result (for example, if it returns an IEnumerable that might result in new requests to a service to pull new results while enumerating) an external retry would need to include not only the API call but the processing of the results.

Why would you want to use Topaz's retries instead of the built-in retry support from the Windows Azure Storage Client Library?

The built-in retry support prior to Windows Azure Storage Client v2 had two shortcomings:

It was relatively hard to extend, since it was based on delegates rather than classes.
It only allowed you to specify how long to wait but not which exceptions should be retried; t that decision was still made by the API. You could refuse a retry for exceptions that the client library considered should be retried, but you couldn't force a retry for exceptions that the client library had already vetoed.

With v2 the support for retries was overhauled to address these two shortcomings: it is class based now, and the new IRetryPolicy implementations are responsible for determining what exceptions should be retried. Because of this change, our recommendation now is that you use the built-in support for retries if you're using v2 of the Windows Azure Storage Client Library.

Does this mean that Topaz does not support Windows Azure Storage Client Library v2?

Absolutely not. Topaz supports retries for the new versions of the client library, as well as previous versions. You can use it if you wish, particularly if you want to benefit from Topaz's configuration support. It's just that as the Windows Azure Storage Client library evolved Topaz's support became less necessary so the recommendation changed.

Can you show me the difference in usage?

Here are examples of what using Topaz and the built-in retries look like. In both cases the initialization of retry policies can be separated from performing the requests, and many requests might share the same retry configuration.

Using Topaz

// setup retries
var retryPolicy =
    new RetryPolicy<StorageTransientErrorDetectionStrategy>(
        new ExponentialBackoff(3, TimeSpan.FromMilliseconds(10),
            TimeSpan.FromMilliseconds(10000), TimeSpan.FromMilliseconds(200)));

client.RetryPolicy = new NoRetry();

// execute operation with retries
try
{
foreach (var container in retryPolicy.ExecuteAction(() =>
client.ListContainers().ToArray()))
{
Console.WriteLine(container.Name);
}
}
catch (Exception e)
{
Console.WriteLine("Exception occurred: " + e.Message);
}

Note how the IEnumerable of containers is converted to an array as part of the operation to retry (which might result in some overhead) to ensure that all requests to the Windows Azure Storage services are retried.

Using built-in retry policies:

// setup retries
client.RetryPolicy = new ExponentialRetry(TimeSpan.FromMilliseconds(200), 3);

// execute operation with retries
try
{
foreach (var container in client.ListContainers())
{
Console.WriteLine(container.Name);
}
}
catch (Exception e) {
Console.WriteLine("Exception occurred: " + e.Message);
}

Many thanks to Fernando Simonazzi for contributing to this post.

Re: Oath of Non-Allegiance

Tue, 21 May 2013 04:58:25 +0000

HEAR HEAR!
Printed and posted :)
Thanks for this

-by Matt Barcomb on 5/20/2010 at 2:12 PM

I’m in. Niklas B. Do I pledge allegiance?

-by smalltalk80 on 5/20/2010 at 2:53 PM

(heh heh. Alistair)

Is the log intentionally an inversion of the Microsoft color pattern? They also had a butterfly logo for MSN; Google: Microsoft Butterfly logo.

-M2k

Great idea, Alistair.

-by Gastón Nusimovich on 5/20/2010 at 3:10 PM

yes.

-by YvesHanoulle on 5/20/2010 at 3:18 PM

I agree, to the point I’m commenting from my iPhone.

-by Mark Levison on 5/20/2010 at 3:24 PM

Signed !

-by Géry Derbier on 5/20/2010 at 3:28 PM

whatever it means… I’m against it (remembering the Groucho’s song)

Signed

-by davengeo on 5/20/2010 at 3:42 PM

I’m in!

-by Paul Ingalls on 5/20/2010 at 3:58 PM

I’m all in!

-by Magnus Ljadas on 5/20/2010 at 4:05 PM

Eschew preconceptions.

-by Michael “Doc” Norton on 5/20/2010 at 4:15 PM

Hi Alistair.

Sounds a lot like some key “oaths” in the Core Commitments, which, as you know, we have been promulgating for 13 years or so, and which you experienced in bootcamp about, what, 7 years ago?

“I will personally support the best idea

i. regardless of its source,”

While it is ideal to use the best ideas regardless of their source, it is not good practice to use ideas without disclosing their source.

But, hey, you got the right idea!

All the best, and I hope we can comnect sometime soon.

Your friend,

Jim McCarthy
-by Jim McCarthy on 5/20/2010 at 4:25 PM

(Hi, Jim! Actually it’s pretty amazing that our words came out so close, given how different our purposes are. Your purpose in those words is to get people in a single team to listen to each other, mine is to get people on projects around the world to open their ears to people from differing professional cultures; your statement is about ‘supporting’ ideas, I only care if they even /consider/ an idea that comes from a different school of thought. I actually almost wrote “school of thought” instead of “source”, but my fingers generalized the former to the latter at the last second. I think “source” is broader, though somehow I still have “school of thought” in my head. I wonder if I chose the right words…

In the end, the wording is remarkably close, though the context and purposes are different. I certainly haven’t had the Core Protocols in my head as I’ve been formulating this “oath” over the last year, so you needn’t worry that I was lifting one of the Core Commitments. Just a happy coincidence that they sound so similar. My apologies if it alarmed you.

I’m interested in spreading this single idea around the world to allow discussion of different methodologies and the like; you have it embedded in the Core Protocols for team development. I think the addition of the two purposes will be quite useful.

Thanks for writing here! Alistair)

I’m in!

-by Michael Mahlberg on 5/20/2010 at 4:25 PM

Check!

-by Tobias Fors on 5/20/2010 at 4:42 PM

Have to agree on this one. So i’m all in.

-by Verneri Åberg on 5/20/2010 at 4:43 PM

Signed.

Thanks, it’s high time. Posted the words on my site :)

Anu

-by Anu Ramaswamy on 5/20/2010 at 4:45 PM

Is this opposite day? Or do I have to say “Isn’t that not same night”? :)

-by Bil Kleb on 5/20/2010 at 5:14 PM

Kevin Steffenson wrote me this in an email:

“I think a team (or an individual for that matter) needs to be open to any idea regardless of where it comes from, and make judgments about what to do about that idea based on what they perceive the merit of that idea to be. ”

Thanks for the nice elaboration, Kevin. :)

-by Alistair on 5/20/2010 at 5:50 PM

Well if I pretty much said the same thing then it must be true. :)

Signed!

-by Kevin (K-Steff) Steffensen on 5/20/2010 at 7:12 PM

Outstanding plan. I would sign… if only you weren’t an agile guy… WTF… I’ll sign anyway!

-by Payson Hall on 5/20/2010 at 7:49 PM

I like it!!

-by Kay Johansen on 5/20/2010 at 8:43 PM

Well said.
Signed

-by joel tosi on 5/21/2010 at 12:55 PM

Sounds great, where do I sign?

-by Skip Angel on 5/21/2010 at 4:16 PM

I wholeheartedly agree! I’ve added the statement to my business analyst manifesto.

Laura, Bridging the Gap

-by Laura Brandenburg on 5/23/2010 at 8:36 PM

Complete agreement! This is a guiding principle which is applicable in all parts if life.

-by Nils Weinander on 5/24/2010 at 1:21 AM

recently thought about a company motto: “buzzword free consulting”, but that would have been a buzzword itself. so I let it be….

-by modelpractice on 5/24/2010 at 5:19 AM

awesome ##### committed ##### signed #####

-by ka-ching~ on 5/25/2010 at 1:08 PM

This is what I have being saying for years… nicely put Alistair.

I’m all in :)

-by Ahmed Sidky on 5/27/2010 at 2:09 PM

Works for me.

Signed.

-by Curzon Wragg on 5/28/2010 at 4:44 AM

An idea becomes solid when enough people give it life.
I am new to this business and have found that old ideas
are hard to overcome.
Thanks for your leadership!
retired SFC
U.S. Army

-by Cy Seibel on 6/8/2010 at 10:11 AM

As a PMI member and Agile advocate, I want to sign the Oath of Non Allegience, so that I can engage in the respectful knowledge sharing required to improve the work lives of people everywhere.

Thank you Alistair for exhibiting leadership on yet another important front.

-by Jesse Fewell on 6/13/2010 at 10:29 AM

An idea that’s long overdue. Thanks, Alistair.

-by Sanjiv Augustine on 6/13/2010 at 1:00 PM

As a PMP and CSP, I completely agree with and endorse this wholeheartedly. There has been entirely too much bashing going back and forth. As folks in the industry who are trying to get work done the best way they can by being practical, we ought to be more supportive of one another.

Cheers!!

-by Daniel Gullo, PMP, CSP, CSM on 6/13/2010 at 2:37 PM

Signed. I totally agree!!! So glad that you started this, Alistar. Every opinion deserves to be heard at least.

-by Renato Garcia Ferracini on 6/13/2010 at 3:48 PM

A drop of common sense in an ocean of misdirection! Part of the enjoyment of working in a team is to improve, this often means going beyond what the manual says and I’m all for it.

Great stuff

-by Tom McDermott on 6/15/2010 at 12:38 AM

I love it! A lot of energy is wasted convincing people to be pragmatic and objective vs. dogmatic and close-minded.

Signed.

-by Joshua Chappell on 6/15/2010 at 10:07 AM

I sign it.

I’m working in small sized companies and there we have to choose our project management solution problem centric.

-by Sven Schoradt on 6/16/2010 at 11:54 AM

Thanks to Jesse Fewell for taking the butterfly logo and turning it into the I Signed It! badge. (Alistair)

-by Alistair on 6/16/2010 at 1:43 PM

Yay – I totally in!

-signed by Mikkel Haugsted Brahm

-by Mikkel Brahm on 6/18/2010 at 2:23 AM

Signed. Thanks.

-by Bernd Oestereich on 6/19/2010 at 7:55 AM

Great initiative Alistair. Count me in. I am a CSC and CST but have always lived outside of the box ;)

-by Bob Sarni on 6/19/2010 at 10:55 AM

Agreed and signed.

-by Michele Sliger on 6/21/2010 at 11:29 AM

Dogmatic discussions about whether you really qualify to earn the badge “practitioner of method X” is waste of time. It’s all about finding the methods that work in your specific context no matter where it comes from. And then keep on improving…

I so mush agree to the Oath. Signed.

-by Thomas Bøgh Fangel on 6/22/2010 at 3:00 PM

Signed and thanks for the iniative. As a practical IT-Consultant I totally agree and understand that even in IT-business there is not only black or white. So: try to know as much as possible but think critical of everything and take the best breath for your current problem.

-by Dieter Baier on 6/23/2010 at 2:34 AM

Agreed and signed.

-by Dave Howell on 6/23/2010 at 10:34 PM

Well said. It is a huge positive step in every dimension of life. Being open is the best way to learn and apply.

-by Vijay Venkataraman on 6/27/2010 at 2:34 AM

YES YES YES>
I Sign

-by Joseph Flahiff on 6/28/2010 at 9:41 PM

This just shows how deep the problem is if things that should be obvious have to be upheld with special oaths. But it is indeed needed, and I very much agree with the oath (as, BTW, a Scrum practitioner for 4 years and a project manager – and a PMP – for much longer).

-by Andy Brandt on 6/29/2010 at 10:35 AM

Signed!

-by Jens Himmelreich on 7/1/2010 at 7:04 AM

I’ve signed! Been trying to tell a prospective client exactly this for a couple of months now. Turned out to be not the thing they wanted to hear…

-by Mike Morris on 7/2/2010 at 5:13 AM

Agreed and signed!

-by Martin Sans on 7/2/2010 at 6:02 AM

Agreed and signed!

-by Hannes Romare on 7/2/2010 at 6:13 AM

I’m on board.

-by Dennis Stevens on 7/3/2010 at 1:24 PM

I’am in…

-by Ajay Jadhav on 7/7/2010 at 3:33 AM

This is my position on practically everything, so of course I agree. You have to do what makes sense for the circumstances, and you can’t know what that is if you dogmatically follow a particular path because it is the path you’ve always followed. (Ok, so maybe my metaphors are a bit mixed, but you get the idea.)

-by Gary Duzan on 7/8/2010 at 4:10 PM

Agreed and signed!

-by Zsolt Fabok on 7/8/2010 at 4:38 PM

Agreed and signed!

-by Uli Deiters on 7/8/2010 at 6:31 PM

I’m really looking forward to this becoming a consensus, so that when I read great content there is a growing chance is is not mixed up with “flame wars”.

As for the first part, this is how I live, this is a good chance to train on the second part.

Therefore: Agreed and signed!

-by Karfau on 7/8/2010 at 8:42 PM (and edited by Karfau some minutes after)

Adaptive vs. Prescriptive or “Don’t be a slave to formal methods” – Andrew Hunt, David Thomas

-by Dariusz Klupi on 7/9/2010 at 4:28 AM

Zealots despair

-by Tom Czarniecki on 7/9/2010 at 8:36 AM

Signed!

>>I’m tired of people from one school of thought dissing ideas from some other school of thought.

I am tired of people from no school that apply

a)methods
b) without consideration any idea based on its source

Mike

-by Michael Thuma on 7/9/2010 at 11:09 AM

Critical thought FTW.

-by Joe Wirtley on 7/9/2010 at 12:16 PM

Hooray – advocate less cookbook thinking and more idea fusion. The situation and the context is important in all decision making. It is the applicability to the current issues that is paramount not the methodology from which the approach originates.

-by Phil Williams on 7/9/2010 at 1:03 PM

Signed.

-by Franck Depierre on 7/10/2010 at 5:01 PM

Certainly!
/Henrik

-by Henrik Kniberg on 7/10/2010 at 5:13 PM

Signed!

-by Hans Brattberg on 7/10/2010 at 6:04 PM

Yes, I agree!

-by Edoardo Schepis on 7/10/2010 at 6:12 PM

Good ideas can come from any source, be open to them.

-by Ray Foss on 7/10/2010 at 7:01 PM

Signed!

-by Marc Bless on 7/10/2010 at 7:21 PM

Yes !
Context, diversity, not beeing toolhead, and “think for yourself”.

I just translated this site into Japanese to join Japanese signatories in.

-by Kenji Hiranabe on 7/10/2010 at 7:28 PM

Agreed and signed.

-by Fujio Kojima on 7/10/2010 at 7:40 PM

Excellent, i totally agree.

-by Reza Farhang on 7/10/2010 at 8:23 PM

Sounds good! I sign a document.

-by ebacky on 7/10/2010 at 8:51 PM

Sounds good! I sign a document.

-by ebacky on 7/10/2010 at 9:04 PM

Sounds good! I sign a document.

-by ebacky on 7/10/2010 at 9:42 PM

Sounds good! I sign a document.

-by ebacky on 7/10/2010 at 9:43 PM

Yes.
Agreed and signed.

-by Eiji Ienaga on 7/10/2010 at 10:12 PM

Strongly agreed and signed.

-by eiichi hayashi (essence_s) on 7/10/2010 at 10:35 PM

Strongly agreed and signed.

-by eiichi hayashi (essence_s) on 7/10/2010 at 10:57 PM

Agreed and signed!

-by Fumihiko Kinoshita on 7/10/2010 at 11:04 PM

Agreed, endorsed and signed!

-by Shane Hastie on 7/11/2010 at 1:19 AM

+1!

-by Olle Hallin on 7/11/2010 at 3:26 AM

Signed.

-by Kei Ogasawara on 7/11/2010 at 3:55 AM

Signed.

-by Kei Ogasawara on 7/11/2010 at 4:28 AM

Agree, well put and an important statement as it unfortunately is not the default case.

-by Michael Franken on 7/11/2010 at 4:56 AM

Signed!

-by Per Lundholm on 7/11/2010 at 6:14 AM

Signed.

-by Bernd Schiffer on 7/11/2010 at 8:03 AM

Awesome! Signed!

-by Marie Drahroad on 7/11/2010 at 11:43 AM

Signed

-by Mary on 7/11/2010 at 3:10 PM

Signed.

-by Takashi Takebayashi on 7/11/2010 at 7:30 PM

Signed!

-by Aaron on 7/11/2010 at 10:38 PM

Signed!

-by Jonas Montonen on 7/12/2010 at 3:57 AM

Signed!

-by Micke Värn on 7/12/2010 at 3:57 AM

It’s sad this much common sense is so uncommon. I’ve been voicing this very opinion for years and will continue to do so. Let’s stop the “my method is bigger than yours” schoolyard fights and really get to work.

-by Laurens Bonnema on 7/12/2010 at 4:36 AM

I totally agree!

-by Oscar Lantz on 7/12/2010 at 5:26 AM

Signed

-by Mikael Brodd on 7/12/2010 at 8:47 AM

Signed!
Descisions should be taken regarding to context, not by methodical “religion”.

-by Michael Ginart on 7/12/2010 at 10:00 AM

Different countries, different cultures and different companies have ways that work for them, the trick is to work with the parts that are productive :)

-by Brian Silberbauer on 7/12/2010 at 10:22 AM

Signed!

-by Junilu Lacar on 7/12/2010 at 7:16 PM

Signed.
People create the future, not concepts.

-by Keven on 7/12/2010 at 10:55 PM

Signed.

-by 沉心 on 7/13/2010 at 12:17 AM

Signed!

-by James T on 7/13/2010 at 5:48 AM

Signed!
I agree it!

-by Ialy Wolf on 7/13/2010 at 8:43 AM

Signed!

-by SunLiang on 7/13/2010 at 9:49 AM

Signed!

-by QUALIDATA on 7/13/2010 at 3:32 PM

Signed!

-by takehara(take3000) on 7/14/2010 at 7:40 AM

It certainly gets my vote. I’ve seen projects and people get really torn up by the kinds of comments and diatribes that Alistair illustrates all to negative affect.

-by thecronester on 7/14/2010 at 9:19 AM

Signed!

-by Stefan Roock on 7/14/2010 at 10:23 AM

Signed!

-by Paul Momola on 7/14/2010 at 10:40 AM

Signed!

-by Anders Ekdahl on 7/14/2010 at 4:41 PM

Count me in!

But here’s a limited defence of reasonable partisanship. The provenance of an idea does matter, if you want to maintain some degree of consistency.

I see myself as mainly a Coffee sort of a guy; but on a project that’s sinking, someone comes up with an idea that frankly reeks of Tea. Yet on its own it makes a lot of sense, so I hold my nose and go with it.

All works out well – so now, I should ask myself: what does this mean for Coffee? Were our ideas not quite as complete as we hoped? Were there special features of this situation that indicated a more Tea-centric approach? Or was it just a freak? And perhaps I adjust my view a little, so next time around I’m wise to the limitations of straight Coffee-thinking.

If I ignored the tensions between Tea’s assumptions and my own, I might not have learned as much from the success of the Tea-inspired idea as I did.

Get hung up on ideology, and you may miss the best ideas; but ignore the ideological background altogether, and you may not learn as much from them as you could.

-by tomf on 7/14/2010 at 7:40 PM

_Good thoughts Tomf, thanks. What I do is to keep including the ideas looking for the larger unifying principle, e.g. Warm Beverages. When it works, it allows me to function in wider territories, say, when Hot Apple Cider is called for. It’s likely I’ll also learn more about Coffee as a result. ... and then there are the times when an Iced Bubbly Soda (shudder!) is just the ticket. I oblige myself to recognize those times for what they are, but I don’t try to turn an Iced Bubbly Soda into a Warm Beverage anyway. Nice metaphor :). Alistair

Julierme Carvalho de Oliveira

-by Julierme on 7/14/2010 at 9:57 PM

Signed.

-by Don Murray, P.Eng. (donaldm314) on 7/15/2010 at 8:26 AM

Great idea, regardless of the source.

-by Laurent on 7/15/2010 at 3:34 PM

heh :). Nice riposte, Laurent :))

-by Alistair on 7/15/2010 at 4:50 PM

I’m all in.

-by Glenn Waters on 7/18/2010 at 5:59 PM

Strongly agreed and signed.

-by Stuart Guest-Smith on 7/18/2010 at 8:10 PM

I’m in!

-by Nightshade427 on 7/18/2010 at 10:28 PM

Signed.

-by Stavros Pitoglou on 7/19/2010 at 12:28 AM

I fully appreciate this.

-by Markus Gaertner on 7/19/2010 at 1:45 AM

Hebrew Translation:

אני מבטיח לא לדחות אף רעיון על פי מקורו, אלא לבחון רעיונות לרוחב סקלות ומורשות שונות על מנת למצוא את אלו המתאימים ביותר למצב הנוכחי.

If you post it, please right-justify it. (also, the period should appear on the left side… software is not made for rtl languages…)

-by David Elrom on 7/19/2010 at 2:26 AM

I appreciate the sentiment, here. But not the oath itself. You guys are a little nuts. And a little dishonest. Because the source of ideas absolutely DOES matter to you.

Schools of thought, and communities of practice, are a vital part of human intellectual practice. Personal and professional reputation DOES matter. Different and incompatible paradigms DO exist. Does no one here read anything in the history or sociology of ideas? Or do you dismiss it as just the childish rantings of partisan philosophers?

Because schools really exist, the urge to transcend schools of thought is nothing less and nothing different than the urge to silence necessary debate and pretend that the world of ideas is simple. That actually reinforces the barriers between schools.

We don’t need to pretend that there is a universal objective reasonable way to think. There is no such thing. What we need is a tolerant pluralism. In other words, I have my patterns of thinking and people I trust to think with me, AND YET, I also understand that there are other ways of thinking and other communities. I recognize that I am biased in my appraisals of ideas. I must be so, or else I could not get much done.

Each idea is embedded in a thick context of assumptions and connections. Although it is possible to get great ideas from untrustworthy sources, it may not be economical. That’s why all of you are running SPAM filters for your email. All of you routinely delete mail unread that has certain characteristics.

— James Bach

I forthrightly acknowledge the following affiliations:
- Context-Driven School of Testing
- Skeptical Empiricist School of Philosophy
- Radical Unschooling School of Homeschooling Parents
- Humanist, Apatheist, Pluralist, Epicurean, Buccaneer-Scholar, American Pragmatist

-by James Bach on 7/19/2010 at 4:01 AM

It’s a great idea!
I’m in!

-by Paulo Roberto Donatilio Rego – Btolinux on 7/20/2010 at 1:42 PM

How refreshing! Thanks!

Signed

Markus

-by Markus Andrezak on 7/20/2010 at 4:01 PM

Seems obvious, doesn’t it?

-by Adolfo Neto on 7/21/2010 at 9:35 AM

Strongly agreed and signed

-by José Orete do Nascimento, M.Sc., PMP, CSM on 7/22/2010 at 10:02 AM

It’s great to see some common sense left in this IT world! Signed!!!

-by Alexandre Valente on 7/22/2010 at 10:14 AM

I´m in too

-by Caiuby Freitas on 7/22/2010 at 12:26 PM

I agree!
Signed!

-by Satoshi Tashima on 7/23/2010 at 1:01 AM

yes, indeed!

-by Ellen Gottesdiener on 7/24/2010 at 6:41 PM

I completely agree. Thanks Alistair.

Signed!!!

-by Alexandre Magno on 7/25/2010 at 10:32 AM

I agree!
There is no silver bullet. We find the best solution, no matter where it originated.

-by Ricardo Fernandes Luiz on 7/25/2010 at 2:30 PM

I agree!
There is no silver bullet. We find the best solution, no matter where it originated.

-by Ricardo Fernandes Luiz on 7/25/2010 at 10:12 PM

I agree!
There is no silver bullet. We find the best solution, no matter where it originated.

-by Ricardo Fernandes Luiz on 7/25/2010 at 10:25 PM

Signed. We should never lose our critical perspective.

-by Julio Oliviera on 7/26/2010 at 11:08 AM

I agree!

All of good ideias must be considered

-by Rogério Carrasqueira on 7/26/2010 at 9:59 PM

agreed

-by Carlos on 7/26/2010 at 10:25 PM

It could also be called, “I pledge to be pragmatic, not dogmatic”.

I’m in total agreement.

-by Yvonne on 7/26/2010 at 10:43 PM

Agree, signed and saddened that it is needed.

-by Hans Samios on 7/28/2010 at 4:21 PM

I agree.

-by Anders Jonsson on 7/29/2010 at 3:49 AM

Awesome!

-by Tom Perry on 7/29/2010 at 6:53 PM

Signed

-by NickyMouse on 7/29/2010 at 10:49 PM

Signed!

-by NickyMouse on 7/29/2010 at 10:49 PM

Signed. Individuals over (agile) processes… and ideas, thank you Alistair.

-by Thierry Cros on 7/30/2010 at 2:55 AM

Although there are times for being single-school-of-thought dogmatic, that too should be a choice. So, Signed.

-by Machiel Groeneveld on 7/30/2010 at 5:48 AM

Signed

-by Jarell Mallari on 8/1/2010 at 11:42 AM

Signed

-by Colin Scott on 8/1/2010 at 9:40 PM

Any good idea is valid, and people must learn to be open-minded to them. Everyone with good sense must be signing this =)

-by Pablo Lima Dias on 8/1/2010 at 9:49 PM

Signed

-by Kaiserguilherme on 8/1/2010 at 9:50 PM

Signed and proudly displayed

-by Cathy Carleton on 8/1/2010 at 10:21 PM

Like the idea in principle, but the practice is hard. Sometimes a source of ideas is so consistently bad that it just saves time.

That said, I’d love to see this, particularly in politics. So sick of one side dismissing an idea just because the other side thought of it

-by Doug Paice on 8/1/2010 at 10:38 PM

I’m in !!

-by Ben Hughe on 8/2/2010 at 2:42 AM

Signed.

-by Torbjörn Gyllebring on 8/2/2010 at 3:26 AM

You are so right, Doug – it’s easy to say “I sign” to this, but just wait till the next argument shows up :). I hope even 1/3 of the people who say they sign this can carry it out at work (let alone politics). thanks. Alistair.

-by Alistair on 8/4/2010 at 11:17 AM

I promise!

Arabic Translation:

اتعهد بعدم استبعاد أي فكرة من النظر على أساس مصدرها ، و النظر في الأفكار من المدارس الأخرى و الخبرات السابقة من أجل العثور على تلك التي تناسب الوضع الراهن.

-by Shady M. Najib on 8/7/2010 at 12:10 PM

Signed

-by André Faria Gomes on 8/8/2010 at 10:31 PM

Signed!!

-by Kondala Rao Maddala on 8/10/2010 at 11:46 AM

Here here!

-by Peter Green on 8/10/2010 at 3:31 PM

Signed.

-by Chris Tohline on 8/10/2010 at 5:30 PM

Signed.

-by shevek on 8/12/2010 at 5:40 AM

I hereby swear my allegiance to this… wait a minute.

I hereby refuse to swear my allegiance to this… no, that’s not it either.

Screw it – count me in.

-by Jonathan House on 8/13/2010 at 7:24 PM

Eu juro! Ops… Signed!

-by Gustavo Maia (GutoMaia) on 8/15/2010 at 11:26 AM

Signed It. Nice initiative.
French translation:
“Je promet de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.”

-by Mathieu Poitras on 8/16/2010 at 4:17 PM

PERKELE! Never heard anything so good! It’s like… like we’re all brothers (or sisters in half the cases). Sign me in!

-by Pekka Marjamäki on 8/17/2010 at 12:49 PM

What does the Finnish version look like? (now adding Perkele to my 3-word Finnish vocabulary)

-by Alistair on 8/20/2010 at 12:33 PM

I think its a great concept, Alistair. Count me In.

Signed.

-by Iain Davis on 8/20/2010 at 1:18 PM

yep

-by Vincent van der Lubbe on 8/21/2010 at 1:09 PM

Signed!

-by Ilker Cetinkaya on 8/24/2010 at 6:40 PM

Timeless. Open-minded thinking. Signed!

-by Scooter Schneider on 8/25/2010 at 10:57 AM

I completely agree. Over the last 20 years we’ve had debates over mainframe vs. client-server, waterfall vs. RAD vs. iterative, OMT vs. Booch, RUP vs. Agile, Agile vs. the world.

I believe we need to focus first and foremost on being pragmatists!

Signed!!!

-by William F. Nazzaro on 8/25/2010 at 12:16 PM

I sign hoping to be congruent with this statement. Not an easy task if you recognize that there are some ideas that doesn’t sound to you at all.
Also, here is a Spanish translation:

“Prometo no excluir de consideración ninguna idea en base a su origen, sino considerarlas todas sin importar la escuela o la línea de pensamiento de donde provengan, para encontrar aquellas que mejor se ajusten una situación específica.”

-by Witt Igahluk on 8/25/2010 at 9:33 PM

I’m on board!

-by Pattern-chaser on 8/26/2010 at 6:00 AM

I concur wholeheartedly. I have always considered myself a “shopping cart methodologist”, synthesizing approaches from different sources and experiences to meet a client’s particular needs. Of course, I got dissed a lot for doing it, since it wasn’t “pure” nor “by the book”. It is nice to see that others may agree with me.

-by Mark Layman on 8/29/2010 at 10:16 AM

I sign.

-by Olaf Lewitz on 9/1/2010 at 5:54 PM

Swedish translation:

Jag lovar att inte låta bli att beakta någon idé på grund av dess källa, utan att beakta idéer från alla skolor och ursprung för att finna dem som passar bäst i den nuvarande situationen.

-by Nils Weinander on 9/2/2010 at 3:11 AM

I concur.

-by Hans Höök on 9/2/2010 at 6:01 AM

This is just great! Signed!

-by André Pinto de Souza on 9/7/2010 at 5:23 PM

I agree to uphold the oath of non-allegiance. The key SCRUM gurus in my community are arrogant, dogmatic people who are very quick to attack and disrespect anyone who does not strictly implement their approach. It’s about time the scrum gurus got a bick kick to teach them some humility and flexibility.

-by Murray Robinson on 9/14/2010 at 9:52 PM

!...fully aware before fully engaging…! Thanks for reminding us of the need to be open and not just for open source. ;-)

-by Melodye Creason on 9/19/2010 at 11:29 PM

signed.

-by Geoff Rayback on 9/21/2010 at 7:33 PM

Signed.

-by Matthew Helmke on 9/22/2010 at 1:38 PM

Russian translation:

Я обещаю не исключать из рассмотрения никакой идеи, основываясь на её источнике, а рассматривать идеи любых школ и традиций, чтобы найти те, которые лучше соответствуют текущей ситуации.

-by Ivan Sagalaev on 9/22/2010 at 2:28 PM

Croatian translation:

Zakljinjem se da niti jednu ideju necu iskljuciti iz razmatranja na osnovu njezinog izvora, vec da cu razmatrati ideje iz svih skola misli i nasljedstava kako bi pronasao one koje najbolje odgovaraju trenutnoj situaciji.

-by quant on 9/22/2010 at 5:11 PM

Hi quant! I put your text through the online Croatian-English translator, and it produced this: “Zakljinjem does yes we do ravel jednu the idea of necu peck out through meditation at an warp his authentic vec yes we do cu contemplate the idea of through svih scholastic thinker plus hereditament in order to to find they which najbolje draw upon currently situation.” Powered by WordTran/NeuroTran®. ... When you get done laughing, it’s probably not what you meant :). Is there another online Croatian-English translator you know of I could use? Thanks, Alistair.

Signed.

Asturian translation:
Prometo nun dexar de considerar idea denguna basandome nel so orixe, sinón considerar idees de toles escueles y tradiciones, col envís d’alcontrar les que meyor s’axusten a cada situación

-by Xuacu Saturio on 9/22/2010 at 6:27 PM

Signed!

-by Seung Soo, Ha on 9/22/2010 at 8:16 PM

Affirmed.

-by Wood [AU] on 9/28/2010 at 9:28 PM

Signed.

-by Kent J. McDonald on 9/29/2010 at 1:05 AM

Polish translation of
“I promise not to exclude from consideration any idea based on its source, but to consider ideas across schools and heritages in order to find the ones that best suit the current situation.”
is
“Przyrzekam, że nigdy nie pominę w rozważaniach pomysłów bazując na ich źródle, lecz uwzględnię pomysły z różnych szkół i dziedzictw w celu znalezienia tego, które najlepiej pasuje do zaistniałej sytuacji.”

-by Piotr Podsiadły on 9/29/2010 at 3:52 AM

Turkish translation –

“Kaynağına bakarak bir fikri değerlendirmeden dışlamayacağıma, farklı düşünce gruplarına ait fikirleri mevcut duruma en uygun olanını bulmak için değerlendireceğime söz veriyorum.”

-by Berke Sökhan on 9/29/2010 at 11:18 AM

I swear to combat conformity and mechanism and powerpoint for the sake of learning, using wit, imagination, mystical powers, coffee, blues guitar, flower petals, legos, my children’s art, pig Latin, and bad puns. —Patrick Wilson-Welsh

-by Patrick Wilson-Welsh on 10/5/2010 at 11:42 AM

Awesome, Patrick! I’m signing up for your program! Alistair

-by Alistair on 10/6/2010 at 9:34 PM

“I promise not to exclude from consideration any idea based on its source, but to consider ideas across schools and heritages in order to find the ones that best suit the current situation.”

in Dutch:

“Ik beloof dat ik ideeën niet zal afwijzen op basis van herkomst, maar dat ik ideeën van verschillende scholen en afkomsten zal beproeven om de oplossingen te vinden die het beste aansluiten bij de huidige situatie.”

-by Jeroen on 10/7/2010 at 5:29 AM

Signed.

-by Rune Bjerregaard on 10/7/2010 at 9:44 AM

Sold. And Signed.

-by Murali on 10/11/2010 at 9:55 AM

Signed.

-by Dennis Mancl on 10/11/2010 at 3:10 PM

Completely and utterly agree. Anyone who has a passion for what they do will have opinions & affiliations, nothing wrong with that. The ability to adopt the appropriate technique for the challenge at hand, while respecting the nuances of culture is true professionalism. Agile/Iterative/Use Cases/RAD/Cient-server/OO/COBOL…, gems everywhere.

Nice one, Alistair.

-by Fergal McGovern on 10/12/2010 at 6:41 PM

Long live command and control & waterfall!

I’m out

-by Christian Blunden on 10/13/2010 at 4:30 AM

Long live command and control & waterfall!

I’m out

-by Christian Blunden on 10/13/2010 at 4:31 AM

I completely agree. signed!

-by Frank Arndt on 10/13/2010 at 9:35 AM

It is so good to hear that others feel the same way. Too often we in the community bash each other for not being “pure” enough in a particular school of thought. Too often we stick to the same techniques instead of choosing the appropriate technique for the situation.

-by Brian Levy on 10/14/2010 at 3:08 PM

This is going to be hard to abide by but worthwhile I believe.

-by Gavin Hogan on 10/22/2010 at 11:43 AM

Agreed, signed.

-by Matt Doar on 10/25/2010 at 4:10 PM

Free range ideas are often the best :-)

-by Joel Sanda on 10/27/2010 at 11:40 AM

If you need to agree with a group to be right, you’re wrong.

-by Evan Cofsky on 10/27/2010 at 5:32 PM

Signed

-by Gerald stober on 10/29/2010 at 9:05 AM

Signed

-by Gerald stober on 10/29/2010 at 9:10 AM

Signed

-by Gerald stober on 10/29/2010 at 9:10 AM

beautiful assertion in a software world that get’s unnecessarily divisive by excluding ideas because they’re not cool or familiar.

-by Timothy J. Morris on 10/31/2010 at 8:47 AM

I agree! Count me in and signed! Thanks Alistair.

-by Joe Astolfi on 11/1/2010 at 2:49 PM

Signed.

-by Jacques-Antoine Massé on 11/3/2010 at 6:32 AM

We’re in! Check out our latest blog post on the topic.
http://www.quickstonesoftware.com/blog/2010/11/02/virtues-of-the-oath-of-non-allegiance

Thanks! and good luck with it. Alistair

-by Quickstone Software on 11/3/2010 at 6:34 PM

Signed!! Thanks Alistair

-by Damon Gaylor on 11/10/2010 at 2:11 AM

Thank you Alistair! Find what fits!

-by Raffi Simonian on 11/12/2010 at 1:14 PM

I signed it !

-by Pablo Pernot on 11/16/2010 at 8:04 AM

Agree 100%

-by Andy Newcomb on 11/16/2010 at 12:15 PM

I am in and just signed it. Thank you Alistair!

-by Prem on 11/21/2010 at 7:50 PM

Great Job! Alistair! Thanks!

Agree!!!!!

-by Tsuyoshi Ushio on 11/22/2010 at 3:59 AM

I agree!

-by Ken Tamagawa on 11/22/2010 at 11:16 AM

Signed and included the logo in my blog!

-by Walter Ariel Risi on 11/22/2010 at 1:25 PM

Some companies or project leaders think a single school of thought is based not on principles but rather composed of strict rules and all encompassing.

I conform not to conform. I therefore sign the Oath of Non-allegiance.

-by Reuel Cruz on 11/22/2010 at 5:18 PM

Signed!

-by Anders Jönsson on 11/29/2010 at 4:57 PM

Jepp! Signed! Great Idea!

-by Thomas Mosel on 12/3/2010 at 10:30 AM

I absolutely agree with this wonderful, inclusive statement.

I would love to see this type of oath taken by those involved in national politics and international diplomacy.

-by Ben Przystanski on 12/8/2010 at 2:18 PM

Don’t we all wish it, Ben! sigh. hard enough to get programmers and methodologists to give it 5 minutes. Thanks! Alistair

-by Alistair on 12/8/2010 at 3:49 PM

History shows me that blind faith leads to dogmatism. Dogmatism manifested in software engineering is ridiculous (and in general as a matter of fact). There are at least two arguments to be open-minded: give evidence of maturity and professionalism, and enable you to see beyond the cave you sit in.

I sign in, although it is a beautiful =><=. I will do everything possible to keep my oath.

Thanks Alistair.

Below is my translation (interpretation) into Romanian.

Promit, să nu desconsider nici o idee doar pe considerentul sursei și să accord atenție ideilor altor școli, în scopul de a le găsi pe cele care se potrivesc cel mai bine cu situația actuală.

N.B. Maybe you still need to reconsider your involvement in SEMAT :-)

-by Ioan VINTOIU on 12/10/2010 at 3:52 AM

I’m all in!

Signed!

Thanks Alistair

-by Takehiko Akimoto on 12/13/2010 at 10:00 AM

It’s a great idea, I think so too, but I wish you to do not dis the people who cannot wake up to this idea. :)

-by Tetsuya Satoh on 12/15/2010 at 1:46 AM

Here’s a perfect Value!

-by Catia Oliveira on 12/21/2010 at 10:49 AM

I’m In.
Signed.

Michael Larsen (aka the TESTHEAD)

-by TESTHEAD on 12/22/2010 at 4:18 PM

Assinado!

-by Rafael Justino Costa on 12/30/2010 at 5:55 AM

Count me in.

-by JTJ on 1/18/2011 at 11:24 PM

Me, too…..

-by Molly Lovelace on 1/18/2011 at 11:33 PM

Nodding in violent agreement…

-by Ellen Grove on 1/20/2011 at 12:28 PM

thank you

-by Dan Lewis on 1/20/2011 at 1:04 PM

Nice one.

Slovak translation:

Sľubujem, že nikdy neodmietnem zvažovať myšlienku len na základe jej pôvodu, ale dôkladne zvážim myšlienky z rôznych myšlienkových smerov a učení, aby som našiel práve tie, ktoré sa najlepšie hodia pre danú situáciu.

—-
Peter Perháč
perhac(dot)com

-by Peter Perhác on 2/7/2011 at 7:45 AM

Agree 100%. Might want to add “All egos are to be checked at the door.”

Dutch translation:

Ik beloof om niet buiten te beschouwen enig idee op basis van de bron, maar om ideeën te overwegen over scholen en erfgoeden om degenen te vinden die het beste bij de huidige situatie passen.

-by Robert Koehl on 2/9/2011 at 10:27 AM

Excellent, I agree to refuse to limit my thinking and creative ideas by the confines of one framework, philosophy or dogma. I promise to judge ideas based upon the impact and merit they bring to the situation.

-by Paul Roest on 2/9/2011 at 10:28 AM

Count me in as well

-by Tony Ponton on 2/23/2011 at 6:18 AM

Agreed and signed.

-by Chris Chan on 2/24/2011 at 5:10 AM

Signed. Thanks for the opportunity to declare myself in.

-by Fred Ballard on 2/24/2011 at 11:06 AM

This is exactly what I believe in for a long time now!

-by Marcin NIebudek on 2/25/2011 at 5:38 AM

Count me in!

-by Andy Roth on 3/3/2011 at 2:54 PM

Signed – of course.

-by Rick Butler on 3/13/2011 at 10:22 PM

Signed, hand on my heart, and too much experience to think otherwise. Good work.

-by Andrew Webster on 3/16/2011 at 10:46 AM

Signed! Thanks for creating this!

-by Alan on 3/17/2011 at 4:28 PM

Signed. Great idea Alistair.

-by Fred Joliot on 3/19/2011 at 2:17 PM

Je signe ! Excellente initialive !

-by Frederic Vandaele on 4/6/2011 at 9:42 AM

Signed and sworn

-by Anthony S. Kilhoffer on 4/16/2011 at 12:31 PM

Signed! I agree with you.

-by Zhou Jiancheng on 4/17/2011 at 10:44 PM

Signed!

-by Mike, HibbardConsulting on 4/18/2011 at 6:33 AM

Signed!

-by Mike, HibbardConsulting on 4/18/2011 at 6:34 AM

Now if only some of the other patriarchs would see it that way…

-by Raul Vejar on 4/18/2011 at 9:55 AM

Totally agree. Signed :)

-by Monika Konieczny on 5/7/2011 at 4:56 PM

Signed.

-by Matthias Assmann on 5/9/2011 at 1:31 PM

Signed :)

-by Jussi Mononen on 5/17/2011 at 3:55 AM

Accepted and Signed!

-by Srinivas Mandalemula on 5/24/2011 at 2:08 PM

Of course!
Now if Imay hint at one step further.
In order to evaluate new ideas properly (as opposed to dogmatically, emotionally) we need to

1. Learn to quantify our requirements and constraints, so we have a clear agreed idea of what we really want to have and to avoid

2. Learn to measure or estimate the corresponding performance/quality cost attributes , so we can fairly decide if they are relevant for our defined purposes.

3. learn to compare multidimensional objects, to find the alternatives that fit our requirements best.

Those who want detailed advice on such ‘engineering’ methods will find ample free data at gilb dot com

a beginners kit is in
How Good is a Process
Paper

-by Tom Gilb on 5/25/2011 at 3:15 PM

Of course!
Now if Imay hint at one step further.
In order to evaluate new ideas properly (as opposed to dogmatically, emotionally) we need to

1. Learn to quantify our requirements and constraints, so we have a clear agreed idea of what we really want to have and to avoid

2. Learn to measure or estimate the corresponding performance/quality cost attributes , so we can fairly decide if they are relevant for our defined purposes.

3. learn to compare multidimensional objects, to find the alternatives that fit our requirements best.

Those who want detailed advice on such ‘engineering’ methods will find ample free data at gilb dot com

a beginners kit is in
How Good is a Process
Paper

-by Tom Gilb on 5/25/2011 at 3:15 PM

Signed.

-by Andrew Lenards on 6/2/2011 at 10:11 AM

great idea,

signed

-by Xavier Zebier on 6/9/2011 at 12:47 AM

This so harks back to the volatile environment of the original C2 days, when things were chopped and changed, considered, tried, commented and USED, and the proofs were what came through under fire. And everything was challenged. Everything was mutable. Wiki in the first sense.

Yes.

Signed.

Remembered.

-by Ashkelon on 6/9/2011 at 11:43 AM

At last – common sense is reborn!

-by Richard Scott-Will-Harknett on 6/16/2011 at 10:39 PM

Very sensible indeed. The sooner we stop splitting hairs and recognizing that all systems/schools/methodologies are made for the same human brains. They’re all facets of the same truth looked from different vantage points.

I am in…

-by Peter Tillemans on 6/19/2011 at 3:37 PM

Nice one. Ideas should always be considered on technical merit not politics.

-by Phil H on 6/21/2011 at 2:02 PM

I was sure I signed this after Agile 2010, but it appears not. Agile Australia 2011 reminded me to take another look.

So count me in as officially signed.

-by Craig Smith on 6/22/2011 at 8:07 AM

Thank you for this Alistair. I am so sick of small minded zealots. Aren’t we all in this thing to try to improve the industry rather than scrap amongst each other? Well done. Count me in.

-by Edwin Dando on 6/22/2011 at 4:50 PM

Count me in!

-by Cristine Naylor on 6/23/2011 at 12:07 PM

Where do I sign?....

-by Nick Borders on 6/23/2011 at 3:33 PM

I agree

-by robert McDonald on 6/24/2011 at 12:57 AM

I agree

-by robert McDonald on 6/24/2011 at 1:27 AM

dengis > signed :)

-by jon stahl on 6/29/2011 at 10:15 PM

Previously I worked for a company that invented the saying “not invented here!” so you learn to not look out the window so you don’t get inspired. But I have since long escaped that mental prison and arrive here to swear the oath!

-by Patrik Malmquist on 6/30/2011 at 4:03 PM

Here comes (finally ;-) the Italian translation.

“Prometto di non omettere di considerare nessuna idea in virtù sulla sua origine, ma di considerare invece idee provenienti da scuole ed eredità differenti, al fine di individuare quelle effettivamente più adatte alla situazione corrente.”

I’m officially signing :-)) ... and I’ve put the badge on my website.

ciao
carloz

-by carloz on 7/2/2011 at 1:56 PM

Signed!

-by NAKA Yamato on 7/6/2011 at 10:35 AM

You’re right! I agree.

-by Takahiro Nohdomi on 7/6/2011 at 10:54 AM

I agree. Signed!

-by Liza Wood on 7/9/2011 at 8:50 AM

Signed!! To become a master in something one should be able to surpass different schools of thought.

-by LeanAdaptiveManager (@PatrickSteyaert) on 7/13/2011 at 3:37 AM

Signed! We need to get rid of that God complex and be prepared to make good mistakes, see Tim Harford: Trial, error and the God complex on TEDGlobal 2011

-by Peter Bakker on 7/24/2011 at 3:46 AM

Signed.

-by Allan Stoneham on 7/24/2011 at 8:15 AM

Wholeheartedly agree!

Signed…in blood.

-by Dacid Dame on 7/29/2011 at 3:27 PM

Closing your mind indiscriminately is much worse than opening it indiscriminately and neither are as good as open in consideration.

Count me me.

-by Matt Grierson on 7/29/2011 at 4:54 PM

But wait… which flavour of Agile is supporting this Oath thingy?

Ah what the heck, put me down for it… it’s what I do anyway.

-by John Carter on 8/3/2011 at 10:12 PM

I agree with that.

I cannot stand strict adherence to any process/strategy that is unwilling to embrace the fact that situations vary and may require a modified approach to achieve a practical, valuable solution.

-by Gordon J Milne on 8/3/2011 at 10:27 PM

Count me in! I don’t mind which technology you use as long as you agree with what I think… :)

-by Phil Barr on 8/4/2011 at 5:58 AM

I’m in. I promise…to find the ones that best suit the current situation. Thanks!

-by Brent Oglesby on 8/4/2011 at 3:49 PM

-by Tamas Rev on 8/8/2011 at 4:26 AM

Interesting. Here is the translation in Greek:

Υπόσχομαι να μην εξετάζω ιδέες με αποκλειστική βάση τήν προέλευση τους, αλλά να συμπεριλαμβάνω ιδέες από όλες τις σχολές και κληρονομιές για να βρω αυτές που ταιριάζουν καλύτερα τα δεδομένα της συγκεκριμένης περίστασης.

-by ΗΜ on 8/22/2011 at 2:30 PM

Allegiance to ideologies always results in some perversion of the original intent anyway. Schools of thought are valuable, but shouldn’t way any more than their component thoughts.

So this Oath represents a school of thought – not an ideology, right?

I hereby take the Oath!

-by Matthew Liddle on 8/26/2011 at 10:52 AM

I also promise to understand that understanding agile means there is no Agile

-by Erik Klein Nagelvoort

Hi, Erik. Thanks for the Dutch translation! I moved the comment about agile down here because the oONA is wider than just agile – the agilist exclusionist mindset is just a subset of the issue. bests, Alistair.

+1

I created a Linked In group for this (Group ID=4081877). If you’re on linked in, then join the group and the butterfly logo will be displayed along all your other group memberships.

-by Steve Tendon on 9/11/2011 at 9:30 AM

“The other terror that scares us from self-trust is our consistency; a reverence for our past act or word, because the eyes of others have no other data for computing our orbit than our past acts, and we are loath to disappoint them. ” —Emerson
Count me in!

-by Kim Forthofer on 9/13/2011 at 5:33 PM

So signed.

- Joel I. Hart

-by mprototype on 9/27/2011 at 2:29 PM

I’m in and hereby sign the oath

-by Joel Oosthuizen on 9/28/2011 at 4:48 PM

I am in complete agreement with this objective and hereby sign the oath.

-by Ramesh Nori on 10/6/2011 at 10:06 PM

This is how I’ve been working through all these years of coaching, I’m definitely in!

-by Jussi Markula on 10/14/2011 at 1:06 AM

I’m in!!

-by Leandro Fernandes Fraceto on 11/8/2011 at 11:34 AM

I completely agree and endorse this stance. Sign me up!

-by Andrew Annett on 11/8/2011 at 1:35 PM

Simple but profoundly important. I sign the oath.

-by Declan Whelan on 11/8/2011 at 7:59 PM

This is pragmatic and I agree with the statement made by the Oath of Non-Allegiance. I officially sign.

-by Christopher R. Goldsbury on 11/13/2011 at 11:26 AM

I’m in! Openness to ideas regardless of source is essential in all aspects of life.

-by Shawn Button on 11/17/2011 at 11:36 AM

I Signed it!!!

-by Pablo Bender on 11/18/2011 at 4:10 PM

Firmly signed.

-by Nigel Smith on 11/19/2011 at 7:01 PM

I’m in!

-by Sean Farmar on 11/20/2011 at 6:57 AM

Signed: Supporting open sharing and re-using of ideas!

-by Ben Linders on 11/30/2011 at 9:20 AM

Thank you Alistair for this pragmatic statement!

-by Anda Abramovici on 11/30/2011 at 3:05 PM

Thank you. I sign.

-by Ken Hansen on 1/2/2012 at 11:38 AM

Signed. Thought I signed it the first time I saw it – guess not! Good way to start the year off!

-by Jake Calabrese on 1/5/2012 at 8:51 PM

I whole heartedly agree with the Oath and have been living by it for sometime now. Thank you for putting it into words.

-by Andrew Rusling on 1/7/2012 at 10:58 PM

If you meet the Buddha, kill him. Signed.

-by Alex Kell on 1/17/2012 at 4:02 PM

I take the oath, maybe… I’ll withdraw my oath if something better comes along!

-by Mike H on 1/17/2012 at 5:45 PM

I agree with the Oath. I hope people will be open minded to the ideas from different sources.

-by Hulisi PEKSÖZ on 2/6/2012 at 8:23 AM

I agree with the Oath. I hope people will be open minded to the ideas from different sources.

-by Hulisi PEKSÖZ on 2/6/2012 at 9:13 AM

Listening means to first assume, the other opinion is right, and then to scrutinize the own opinion again in this light.

Signed!

-by Gerd Bleher on 2/7/2012 at 11:37 AM

I continue to encounter those who refuse to get it – just had one of those discussions this morning.
I sign and will stand by this Oath of Non-Allegiance!

-by Richard Dolman on 2/8/2012 at 7:01 PM

I continue to encounter those who refuse to get it – just had one of those discussions this morning.
I sign and will stand by this Oath of Non-Allegiance!

-by Richard Dolman on 2/8/2012 at 7:03 PM

Signed and extended beyond software development
Thank you.

-by Igor Shchetinin on 2/9/2012 at 1:20 PM

I swear! (the oath, of course!)

This reminds me of Buddhism’s emphasis of experience over doctrine: it is not enough to hear about or think a thing in order to determine its truth, you must experience it firsthand.

-by Nigel Runnels-Moss on 3/4/2012 at 8:14 AM

On board and signed!

Wise words in the Oath of Non-Allegiance!

-by David Kohrell on 3/12/2012 at 4:48 PM

roger that, signed and practiced today – before I read the Oath

below the Danish translation

Jeg lover ikke at udelukke nogen ide på grund af dens oprindelse, men at inddrage ideer på tvœrs af skoler, kultur og baggrund til at finde den løsning der er bedst til den aktuelle situation

-by Kasper Jørgensen on 3/14/2012 at 4:22 PM

Signed!

Great idea – there is no one right answer – miss out when we dismiss without thinking first.

-by Gary Rush on 4/1/2012 at 10:36 AM

What a profoundly simple yet amazing concept. To open one’s mind to accept knowledge no matter the source

-by paul mahoney on 4/2/2012 at 10:34 AM

I can’t improve on Paul Mahoney’s comment. Ditto.

-by Kevin Hart on 4/2/2012 at 1:25 PM

It takes experience to realize that a single methodology does not work in every situation. The clever system architects and designers blend ideas from a variety of approaches to deliver results.

-by Aakash Sahai on 4/3/2012 at 11:48 AM

I’ll link to that.

DOWN with Dogma :-)

-by Mike Robinson on 4/5/2012 at 10:08 AM

Very cool!

-by Elinor Buxton Slomba on 4/5/2012 at 12:46 PM

Heureka! – heuristic development …

-by Göran Hagert on 4/7/2012 at 12:36 PM

Signed!

-by Adrián Boimvaser on 4/9/2012 at 10:27 AM

Signed!

-by Takeshi Arai on 4/10/2012 at 12:14 AM

Signed!

-by Carl Blomberg on 4/13/2012 at 3:56 AM

Hi Alistair,

Can I post a Bengali translation of the Oath? Bengali is the national language of Bangladesh and a very widely used language in India. People who speak Bengali form a significant section of the computing community too.

Here it is:
আমি শপথ করছি যে আমি কোনো চিন্তা বা ধারণাকে তার মূলের ভিত্তিতে বিচার করবো না, বরং বর্তমান প্রসঙ্গে কোন ধারনাটি সবচেয়ে বেশি উপযুক্ত তাতে উপনীত হওয়ার জন্য সমস্ত চিন্তাধারা ও ঐতিহ্যের ধারণাবলীকে বিচার করে দেখব |

If you feel, you can validate and modify this from other reliable sources.

With best regards,
Sayan

-by Sayan Mukherjee on 4/13/2012 at 8:12 AM

Great idea and let’s hope to see many more signatures and not just confined to software environments.

-by Craig Strong on 4/13/2012 at 10:40 AM

Signed!!!

-by Abhilash Kuzhikat on 4/20/2012 at 3:20 PM

Signed!

-by Tomi Schütz on 4/25/2012 at 6:40 AM

Signed!

-by Tomi Schütz on 4/25/2012 at 9:37 AM

Seems like a good idea

-by Marjie Carmen on 4/28/2012 at 10:20 PM

Hiya, Brilliant, most definitely support this. Ta Roy

-by Roy Gouck on 5/7/2012 at 7:27 AM

Signed! Fantastic initiative!

-by Constantijn Blondel on 5/10/2012 at 5:20 AM

Spot on. Signed.

-by Bill Nicolich on 5/10/2012 at 10:50 AM

Yes, i promise.

-by Madhu on 5/24/2012 at 5:02 AM

Fantastic Initiative. Good Job.

-by Homayun Zahidi on 5/29/2012 at 4:45 AM

I pledge non-allegiance! +1

-by Brian Teachman on 6/3/2012 at 7:40 PM

I’m in.

-by Dana Fortier on 6/12/2012 at 11:12 AM

I hereby swear.

-by Josh Devins on 6/14/2012 at 5:04 AM

Bravo!

-by Gene Hughson on 6/26/2012 at 11:23 AM

Signed

-by James A. Curtis on 6/28/2012 at 10:17 AM

Filipino Translation:

Ipinapangako kong hindi isantabi ang pagsasaalang-alang sa anumang ideya na batay sa kanyang pinagmulan, bagkus isaalang-alang ang mga ideya sa kabuuan ng mga paaralan at mga heritages upang mahanap ang mga pinakamahusay at angkop sa kasalukuyang sitwasyon

-by gio on 6/30/2012 at 10:53 AM

Ako din – me too!
signed.

-by gio on 6/30/2012 at 11:01 AM

Signed. Very well put.

-by Ilan Kirschenbaum on 7/2/2012 at 4:22 PM

Signed! The “no good, not agile” attitude has weakened products, projects and worst of all teams in the past.

-by William Braymer on 7/9/2012 at 8:44 AM

This is spot on. Signed. I’m in! Done!

-by Glenn Thimmes on 7/10/2012 at 10:29 PM

I most gratefully sign. Thank you for this vision!

-by Birgitte Due on 7/13/2012 at 4:30 AM

Yes, I swear

-by Fernando Martin Maroto on 7/13/2012 at 10:23 AM

+1000

-by Gian Carlo Pace on 7/16/2012 at 5:35 AM

This oath works in so many contexts…

-by Melissa Plicque on 7/17/2012 at 3:10 PM

Love it, solutions often exist for problems in completely unrelated areas or fields, from science and engineering to putting a sandwich together in a canteen or cafe.

Leveraging off others individuals skills and experiences is common sense.

Always bodes the question ‘Why is the common sense approach always so uncommon?’

-by Mike Amur on 7/18/2012 at 1:16 AM

Love it, solutions often exist for problems in completely unrelated areas or fields, from science and engineering to putting a sandwich together in a canteen or cafe.

Leveraging off others individuals skills and experiences is common sense.

Always bodes the question ‘Why is the common sense approach always so uncommon?’

-by Mike Amur on 7/18/2012 at 1:37 AM

signed…....

-by Raghu on 7/23/2012 at 6:54 AM

I acknowledge the intent in this Oath to discuss ideas no matter the school. However, I am missing a little discussion about how people will behave after they have signed this oath.
What will you say to the Project Manager that says “I have a lot of experience in different schools and kind of uses my own mixture of them all – I choose what fits best in each situation”? I would ask the Project Manager “How will your project members know how the project should run and how can we evaluate how well you practice your own discipline?”.
My point here is that thinking out-of-the-box requires a common box to escape when the situation requires it. What if no common box has been selected?
Isn’t a common box NEEDED to be “default” thinking in a team or a community? At least then we together can try to master one discipline at a time. A discipline may work terrible if not followed in full e.g. take the Scrum vs. ScrumBut discussion.
Does signing this Oath mean that you and your team members do not strive to learn how to master a discipline?

-by Keld Ølykke on 7/25/2012 at 8:17 AM

Hi, Keld: I see 5 paragraphs there, so I can respond by referring to the para number:
para1: hopefully they will discuss what they found along the way, and the ways those things work, not fixate on where they found the ideas (although heritage to ideas is useful information, too.
para2: PM is giving answer in keeping w OONA, your reply is out of scope of OONA: the OONA does not assert that everyone is an expert in their discipline, only that good ideas are not excluded on the basis of their point of origin.
para3: Personally, I offer that there is no “box” to think out of, there are only situations. The “box” we standardly operate within without deep introspection grows larger as we incorporate more ideas from more schools.
para4: imho: No, no default box is needed. I personally dislike and disapprove of the Scrum v ScrumBut discussion, because it starts with the assertion that Scrum is good and ScrumBut is bad, a straight violation of the OONA. Instead, how about just investigating what the situation is, and what might work in that particular context, without regard to where the ideas come from, usual or unusual though they may sound? That is what I am after with the OONA.
para5: au contraire, you will master the discipline better if you are open to ideas from all schools of thought, you will always have more tricks in your bag and better understanding than your neighbors, who are excluding useful ideas out of preconceptions about the source of the ideas.
best wishes, Alistair

Craig Smith made me sign it (only joking) ;-p

Great idea and a very valuable statement that everyone should sign up to!

-by Craig Aspinall on 7/30/2012 at 10:46 PM

Perfect! I plan to use it as part of the “ground rules” for meetings with stakeholders.

-by Al Wilkinson on 8/1/2012 at 9:53 AM

I am into it. Don’t want to be considered as a one-trick pony.

-by Marc Otto on 8/2/2012 at 3:54 PM

good luck with that, Al :). Alistair

-by Alistair on 8/3/2012 at 4:58 AM

Signed.

-by Hass on 8/3/2012 at 7:46 AM

Signed!

-by Viktor Nyblom on 8/9/2012 at 5:10 PM

Better late than never (wrt me signing)

Adult thinking in software development – hooray!

-by Andy Longshaw on 8/16/2012 at 5:40 PM

Signed!

-by Mats Berglund on 8/20/2012 at 7:02 AM

Signed!!

-by Girish on 8/21/2012 at 11:18 PM

Signed; we need to listen and speak without prejudice if we are to grow

-by Ian Cooper on 8/22/2012 at 4:14 AM

Signed / all in!

-by Tony Brill on 8/22/2012 at 3:45 PM

Signed!

-by Giuseppe De Simone on 8/30/2012 at 3:57 AM

Signed!

-by Giuseppe De Simone on 8/30/2012 at 9:03 AM

Signed! :)

-by Naveen K Agrawal on 9/3/2012 at 1:08 AM

Thank you, Alistair, for putting this into words. Signed !!

-by Todd Ross on 9/12/2012 at 9:30 AM

Yup – been on board and din’t even know it! :D

-by Leyton Collins on 9/22/2012 at 4:33 PM

Signing this with honesty is a marker in progressing from Agile Zealot to Agile Thinker…also, i guess, in understanding why that is an upward evolution.

-by David Babicz on 9/24/2012 at 7:28 PM

I pledge to seriously consider the oath.

-by David Nieman on 9/25/2012 at 6:37 PM

10-4

-by Jedd Parker on 10/4/2012 at 7:54 PM

Sold!

-by Marc-André Langlais on 10/12/2012 at 12:56 PM

Signed!

The Parable of the Raft

A man is trapped on one side of a fast-flowing river. Where he stands, there is great danger and uncertainty – but on the far side of the river, there is safety. But there is no bridge or ferry for crossing. So the man gathers logs, leaves, twigs, and vines and is able to fashion a raft, sturdy enough to carry him to the other shore. By lying on the raft and using his arms to paddle, he crosses the river to safety.

The Buddha then asks the listeners a question: “What would you think if the man, having crossed over the river, then said to himself, ‘Oh, this raft has served me so well, I should strap it on to my back and carry it over land now?’”
The monks replied that it would not be very sensible to cling to the raft in such a way.

The Buddha continues: “What if he lay the raft down gratefully, thinking that this raft has served him well, but is no longer of use and can thus be laid down upon the shore?”
The monks replied that this would be the proper attitude.

The Buddha concluded by saying, “So it is with my teachings, which are like a raft, and are for crossing over with — not for seizing hold of.”

-by Jason John Wells on 10/19/2012 at 9:19 AM

Signed!! Thank-you for the Oath and thank-you for the Logo!! It’s a great idea of true compassion!!!

-by Wanda B. on 10/22/2012 at 11:17 AM

Less dogma, more catma. Signed!

-by Larry Farmer on 10/22/2012 at 1:43 PM

I love the oath – it isn’t just limited to programming – it applies universally – this should be a precept that is taught in all schools world-wide beginning with kindergarten (actually at birth)

I’m going to post this on my Facebook page, giving you attribution

Cheers!

-by Robb Sauerhoff on 10/24/2012 at 6:47 PM

Sage words to guide the practitioners of our profession, count me in!

-by Michael Banks on 11/6/2012 at 12:03 PM

Signed!

-by Lisa Weiss on 11/7/2012 at 10:55 AM

Signed!

-by Pepijn van de Vorst on 11/10/2012 at 5:41 PM

Applies universally! Favors think-for-yourself approach, based on ideally having learned and experienced a few ways things methods beforehand ;-) I’m in!

-by Martin Kontressowitz on 11/12/2012 at 10:57 AM

Signed!

-by Claudio Ravizza on 11/21/2012 at 6:25 AM

Signed! I feel better already.

-by Kim Adelhardt on 11/23/2012 at 9:46 AM

Ever since I read your Crystal Clear book I’ve felt this way. Open minds, unite in non-conformity!...or don’t unite…I’m open…

-by Derwyn Harris on 11/29/2012 at 2:16 PM

Signed.

-by Ryan Kelker on 12/14/2012 at 12:14 AM

Signed!

-by Sibylle Peter on 12/21/2012 at 3:33 AM

I follow this concept from the beginning. It helped that I saw every single trendy idea of today before it was fully formed.

-by AkitaOnRails on 12/23/2012 at 11:21 AM

Signed! We need to new ideas and hybrid approaches.

-by Guillaume Iacino on 12/26/2012 at 7:56 PM

Just be Open Mind and consider other paths

-by Fáber F. Giraldo on 1/9/2013 at 2:28 AM

¡Firmado! Being open-minded is essential for evolution. Be water, my friend.

-by Amador Durán Toro on 1/9/2013 at 4:16 AM

It makes sense!

-by Gu Xuan on 1/9/2013 at 4:31 AM

Signed!

-by Ramon Gorrin on 1/10/2013 at 9:37 AM

Signed

-by Meenakshi Ramesh on 1/13/2013 at 8:24 AM

Excellent idea. I will happily put my name to this.

-by Daniel Hardman on 1/17/2013 at 11:46 PM

I hearby swear to never agree with anyone’s ideas ever again… oops did I take it too far the other way? :) Its a great oath that I’m happy to sign my name to.

-by Jason Ivey on 2/9/2013 at 12:08 AM

HERE HERE!

-by Justin Thomas on 2/28/2013 at 1:42 PM

I’m surprised I hadn’t already signed this… :)

This is clearly a great idea.

-by John Heintz on 3/5/2013 at 3:00 PM

Stumbled across this Oath while looking for “Use Case” vs “User Story”. Great philosophy! I’m signing on!

-by Trish White on 3/8/2013 at 12:00 PM

Only too glad to sign. Glad Dr. Cockburn initiated this.

~mc

-by Mark Carroll on 3/9/2013 at 7:08 PM

I support it from the bottom of my heart.

-by Karthik Sirasanagandla on 3/12/2013 at 3:48 AM

Signed! Hungarian translation: Megígérem, hogy egyetlen ötletet sem hagyok figyelmen kívül a forrása alapján, hanem megfontolok különböző iskolákból és örökségből származó minden gondolatot, hogy megtaláljam az adott helyzetre legjobban illőt.

-by Gaboo on 3/12/2013 at 7:15 AM

Spondeo ac policeor :-)

-by Ondrej Krajicek on 4/4/2013 at 5:33 AM

Joining the club

-by Nigel Foley on 5/13/2013 at 5:32 PM

Joining the club

-by Nigel Foley on 5/13/2013 at 5:32 PM

Sad that ‘religion’ invades distructively even in this sphere of endeavour

-by Sion Harri, D4-Accred, PMP, CGEIT, P2-RP, Mor-RP on 5/14/2013 at 3:38 AM

Count me in too!

-by Cheryl Court on 5/14/2013 at 10:09 PM

I also support the efforts to eliminate the “I have a certificate, therefore this is how we must…” attitude. PM’ing requires nimble minds in addition to a common understanding of how a thing will work best in production. And if someone produces the PERFECT PM tool — Sign me up for that too… though I’ll probably be dust by then… :)

-by Jeff Jack on 5/17/2013 at 11:21 AM

Thank you. Count me in.

-by Tribezmaan on 5/21/2013 at 4:58 AM

A Detailed Critique of the SEMAT Initiative

Mon, 20 May 2013 20:39:21 +0000

Dr. Alistair Cockburn, Humans and Technology, inc.
Humans and Technology Technical Report HaT TR 2010.02, April 16, 2007

In time sequence:

Alistairs January 2010 proposed agenda for the SEMAT software engineering initiative (discussion: Re: Alistairs January 2010 proposed agenda for the SEMAT software engineering initiative)
Larry Constantines January 2010 proposed agenda for the SEMAT software engineering initiative (discussion: Re: Larry Constantines January 2010 proposed agenda for the SEMAT software engineering initiative)
Alistairs SEMAT presentation Zurich 2010.ppt (discussion: Re: Alistairs SEMAT presentation Zurich 2010.pps)
SEMAT attendees in discussion.jpg
Comments on the SEMAT initiative (discussion: Re: Comments on the SEMAT initiative) (by another person)
Why I withdrew from SEMAT (discussion: Re: Why I withdrew from SEMAT)
A Detailed Critique of the SEMAT Initiative (discussion: Re: A Detailed Critique of the SEMAT Initiative) (this page)

Author’s Note

The purpose of this article is not to dissuade those already participating in the SEMAT discussions from continuing their discussions; it is to arm those who have not been participating in the discussions and who may not be versed enough in the field to read through the spin emanating from the initiative to determine what the group is really up to.

Background

The “Software Engineering Methods And Theory” (SEMAT) initiative started with a call for action in three articles in Dr. Dobbs Journal late in 2009, followed by a request for signatories, leading to a meeting in Zurich in March 2010. That will be followed up by small group meetings at different times and places.

The call-for-action was itself fairly contentious, as was the meeting in Zurich. The organizers called it a great success; I viewed it otherwise and withdrew from the initiative.

To understand SEMAT, we first need recognize that SEMAT is just a group of people getting together to discuss whatever they want. They are free to discuss matters that do not interest others. They are free to change directions as they wish should they themselves feel a change is needed. To the extent that the group wishes to gain wider respect and become a funded initiative, however, they should take the critique in this article into account.

Quick Summary

Here is a quick summary of the final critique:

The call-for-action was inflammatory, poorly researched and logically broken; it uses the very hype-for-fashion language that it decries, it is internally contradictory, the problems it deplores it cannot fix, and its proposed solutions do not address the problems named. It sets a direction in tone and content that does not do the topic justice. It is a red herring, intended to generate support through appeal-to-authority, hype, and ambition.
The organizers are not interested in the same topics I am.
They are unlikely to discuss either engineering or engineering theory – a more accurate name for the initiative would be the Meta-Process-Kernel initiative.
Whatever they produce is unlikely to affect topics that matter to the industry.
They are unlikely to produce anything soon.

The rest of the article will address primarily the first and the third points. The second and fifth are strictly personal opinion; for the fourth, time will tell.

Stage 1: The SEMAT Call For Action

SEMAT originated with three articles:

Methods Need Theory

Why we need a Theory for Software Engineering

The SEMAT Initiative: A Call for Action

The Authors

The primary authors of the articles and founders of the initiative are Dr. Bertrand Meyer, Professor of Software Engineering at the ETH in Zurich and Fellow of the ACM, and Dr. Ivar Jacobson, one of the co-creators of the Unified Modeling Language and the Unified Process. Both have doctorates in the field, both have published articles in academic and popular journals, both are supposed to know the state-of-the-art in software engineering and software development methodologies.

The articles are, however, not written as peer-quality pieces. They are simple advertisements for the SEMAT initiative, full of the “fear, uncertainty and doubt” rhetoric common to sales campaigns in general. More seriously, they misrepresent the state of the industry along the way.

As an expert in the field, I found the following deficiencies in the articles:

“Method Needs Theory”

In this article, Ivar and Bertrand lament that software development methodology selection looks like fashion or politics. They write:

”The prevalence of fads more typical of fashion industry than of an engineering discipline.”

They are correct, it does look like fashion or politics – indeed it always will. There is nothing the SEMAT initiative can do to change the nature of human beings, or the tendency of human beings to be attracted to new and popular trends. In fact, the attention being given to SEMAT is exactly from the fashion, hype, and sloganeering that they decry in this article.

My assessment is that since this lament is quite true, fully irrevocable and outside the scope of anything SEMAT can hope to accomplish, they should not introduce it as an enticement to join the initiative or bring it up as a problem to solve.

”… the elegantly written foundational document of the [Agile] approach is a “manifesto”, long on emotional appeals in the first person plural and short on facts. This style may be effective to capture attention, but as ideas mature it should yield to more traditional (even if also more boring) forms of argumentation.”

The authors once again use precisely the polemical language they decry.

They are correct in saying that the manifesto is a statement of personal values (which have, indeed, shown themselves valuable to the industry). They neglect, however, to mention the over eight years of carefully constructed literature that they should well know, which are exactly the traditional (and more boring) forms of argumentation they ask for. See, for example, these books:

Anderson’s Agile Management for Software Engineering

Armour’s The Laws of Software Process

Cockburn’s Agile Software Development: The Cooperative Game

Poppendieck’s Implementing Lean Software Development

Reinertsen’s Managing the Design Factory

There are many other writings in articles and journals examining and testing the validity of the agile approach; those books constitute a good starter set.

“If we separate the ingredients from the cocktail we can empower people to build the methods they need”

The first problem is that they are contradicting their own position. Doing what they suggest will produce exactly the explosion of methodologies they lament at the start of the article. What will the difference be?

The second problem we have at this point is that it has long been established in the professional literature that methodologies will inevitably increase in number, not decrease. When I “established” this result for my doctoral dissertation (discussion: Re: People and methodologies in software development) in 2002 it was already then considered an old result, not a new one, and therefore not of interest to the review committee. Recognizing the need for multiple methodologies was not only a foundational view of the Unified Process that Ivar Jacobson helped to design in the mid-1990s, it was foundational to his preceding methodology family, Objectory, around 1990.

Methodologies come in the tens of thousands, a well-established if tiring fact that every manager in our industry needs to absorb. The question is not whether there can be fewer but how to handle the ever-increasing number and flavors of methodologies.

For the purpose of the SEMAT initiative, their own recommendation invalidates their opening complaint about the number of methodologies in use. This is the self-contradiction inherent in the call-for-action.

”Software development is a human activity, but it consists of well-defined steps with well-understood relations between them.”

That assertion is not backed up in the research literature. On the contrary, the state of research more indicates that we don’t yet understand what is happening on software projects, and as we start to understand it, there are not well-defined steps, and there are fuzzy, overlapping relations between them.

”Find the Kernel — the Mother of all Methods.”

This is a variant of the self-contradiction above, that there should be both one and many methodologies. As indicated earlier, all the research indicates that there is no “mother of all methods,” but rather, we will find a never-ending set of localized methodologies that depend on the technologies employed, staff size and distribution, the financing model, and more. More on this can be found by established researchers such as Capers Jones and Barry Boehm.

Phil Armour in his "Second Law of Software Process" (at ACM but an account is needed there) phrases the paradox this way:
“We can only define software processes at two levels: too vague and too confining.”

The authors don’t seem to be aware of this law. They should take it under consideration as a factor in their agenda.

“What we are missing is the cornerstone of science and engineering: a theory, and its validation.”

There are three problems with this:

They never say why we need a theory of software engineering and its validation. To motivate the request, they should point to such a theory and its validation in another branch of engineering, and show how that has benefited that industry.
A theory of the type they ask for exists and has been published since 2006. As experts in the field, they would be expected to know of its existence, and would either refute or include it in their plans for validation.
The theory they end up proposing is not a theory at all, but is the design of a meta-method-kernel (more on this, below). The artifact they propose to create does not meet the request they themselves issue.

That concludes the analysis of the first article in the series.

“Why We Need a Theory for Software Engineering”

From the title of the second article, written by Ivar Jacobson and Ian Spence, we would expect to get the answer to the dangling question from the first article, why we need a theory for software engineering. That answer never shows up.

After much the same diatribe as in the first article, they show what they do have in mind.

”Find the ‘truth’ of software engineering. We can then describe and capture this small set of essential concepts in the form of a minimal, practice independent process.”

Their theory of software engineering, it appears, is to be a practice-independent process of some sort. It is not actually a theory at all, as called for in the first article – it does not admit of validation and falsification, it does not produce predictions. It also runs into Armour’s second law of software process, that of being too vague.

”This approach will make it easier to adopt new practices without having to change the other practices you have.”

Leaving aside the continued contradiction over one-versus-many methodologies, I also hunger for a way for people to adopt new practices without having to change the other practices in place. I have ever since 1991,when Wayne Stevens, the architect of the IBM Consulting Group’s methodology family, introduced me to his approach to that very problem. Unfortunately, in two decades of looking, we have not yet found a way to do this well. Having such a thing would certainly be valuable. It is not a theory, but it is a good thing.

They close with, ”Our understanding of software engineering lacks a basic theory.”

The article ends with the same three problems as the first article:

They still never say why we need such a theory.
They still ignore the existing theories on the table.
Their proposed theory is not a theory at all, but just the design of a meta-method-kernel. The artifact they propose to create does not meet their own request.

“The SEMAT Initiative: A Call for Action”

The final article of the three, the call-for-action, is authored by the three creators of the SEMAT initiative, Ivar Jacobson, Bertrand Meyer, and Richard Soley, a key organizer of earlier OMG efforts. In this article, the authors announce: ”the goal of “re-founding” software engineering as a rigorous discipline.”

I analyze the call for action in the next section.

Stage 2: The SEMAT Call For Action

The call for action reads:

Software engineering is gravely hampered today by immature practices. Specific problems include: ...

The prevalence of fads more typical of fashion industry than of an engineering discipline.
The lack of a sound, widely accepted theoretical basis.
The huge number of methods and method variants, with differences little understood and artificially magnified.
The lack of credible experimental evaluation and validation.
The split between industry practice and academic research.

We support a process to re-found software engineering based on a solid theory, proven principles, and best practices that:

Includes a kernel of widely-agreed elements, extensible for specific uses.
Addresses both technology and people issues.
Is supported by industry, academia, researchers and users.
Supports extension in the face of changing requirements and technology.

The Problems SEMAT Proposes to Address

Let’s look at the specific problems they set out to address with SEMAT:

“The prevalence of fads more typical of fashion industry than of an engineering discipline.”

That people become attracted to fads is part of ordinary human nature, it is not due to the immaturity of the industry. Nothing SEMAT can accomplish will affect this problem.

Oddly, the SEMAT itself uses the exact fad/fashion rhetoric in its founding articles and call-for-action that it decries in this first problem topic.

“The lack of a sound, widely accepted theoretical basis.”

In none of the articles did they get around to showing why this is a problem, nor did they hint at the existence of the theories already present.

The key phrase, though, in this bullet is the phrase “widely accepted”. When I pointed to the presence of my theory, Ivar told me, “But that’s not widely accepted.” That true statement is the primary reason I joined SEMAT. If I wish my theory to get critical review, it needs to go through this sort of a challenge process.

However, it is also a catch-22. No theory of software engineering will pass critical review and become a “widely accepted basis” at this early stage of our industry. This includes even after the SEMAT initiative if finished. More generally, there is no sound, widely accepted theory of any of the engineering disciplines.

I accepted to join SEMAT in order to join the search for such a thing, because that topic interests me. I do think there is a possible theory and that it can be useful both in industry and in education; and I think that my own proposal is a decent starting point – and still falls short of what’s needed.

With regard to the problem-statement opening of the SEMAT call-for-action, I do not dare hope that the SEMAT initiative can resolve this problem.

“The huge number of methods and method variants, with differences little understood and artificially magnified.”

They authors have cycled back to their self-contradiction. The large number of methods and method variants is a well-established fact of life, not an “immature practice gravely hampering software engineering.”

The phrase “artificially magnified” is a reference to ordinary human nature, and is not something SEMAT can aspire to addressing.

“The lack of credible experimental evaluation and validation.”

This is a problem, all right, but it is not something SEMAT can address. Researchers in all fields gnash their teeth at creating credible experimental validation of almost any idea. It has nothing to do with immaturity in our field, it is a natural problem in all fields.

“The split between industry practice and academic research.”

The problem is on both sides: That academic research does not yet value field research in our industry; and few practicing developers read the research literature. It will be good if SEMAT can draw some of each together to discuss, almost regardless of what they center discussions on.

Of all the problems given in this call-for-action, only the idea of getting industry and academia together is addressable by SEMAT.

The Solutions Proposed

Let’s next look at the solutions they propose to address those problems:

“We support a process to re-found software engineering based on a solid theory, proven principles, and best practices.”

This phrase attracts me. I have been working on this topic since 1991, and continue to be interested in it. I agreed to join SEMAT in large part because I would find differently-minded peers to argue with and work through what it means to establish this.

I did not understand at the time that they had no real intention of discussing what “software engineering” includes, or that by “solid theory” they mean “meta-process-kernel”. “Proven principles” is obviously not possible, since we can’t prove any of these things, and “best practices” is a suspect term in many places, since what is best varies from context to context.

What remains of this point is that I am interested in this topic at a personal level, and am happy to join other people to discuss it.

“Includes a kernel of widely-agreed elements, extensible for specific uses.”

The design of a meta-process-kernel turns out to be the heart of the SEMAT initiative. If you interested in that topic, then SEMAT is the place to be. If you are not interested, as I am not, then SEMAT is unlikely to be for you.

The topic has some value. If it is achieved, we will have a normalized vocabulary for discussing software development processes and practices. It doesn’t match the rest of the call-for-action, but it has some value.

“Addresses both technology and people issues.”

This is good as stated. It was only during the Zurich meeting that I came to the conclusion that the group is primarily interested in mathematical formalisms. Since I don’t think mathematical formalisms capture what happens on a project, this goal seems out-of-reach for this initiative.

“Is supported by industry, academia, researchers and users.”

A good idea, if the results fit industry needs.

“Supports extension in the face of changing requirements and technology.”

It is not clear to me what this means, whether the meta-process-kernel will be so robust as to be able to handle all future ideas or that there will be an ongoing committee of people to add to the meta-process-kernel.

Summary of the Call-For-Action

Following these three articles, my (incorrect) interpretation of the SEMAT initiative was that this group intends to:

Define what the phrase software engineering means.
Place that on a “solid theory”.
Design a meta-process-kernel allowing people to discuss the commonalities and differences of the inevitably ever-growing number of local software development processes.

Rereading those three points, I am left with the question asked by many others: Why is the term engineering being used in this call-for-action? What part of the problem statement is sensitive to the difference between engineering software and simply developing it.

This question remains unanswered.

Stage 3: The Zurich Meeting

Part of attending the workshop was preparing a statement addressing ”How to find solutions to the problems addressed by the SEMAT effort.”

Here is my position statement.
Here are the slides I presented at the workshop.
Here is Larry Constantine's position statement, which I considered most interesting.

The meeting was two days long, with about 32 attendees, sitting in a U-shape around a long room.

(You may need to maximize the window to get all of this photo in view).

A formal report from the meeting was published on the SEMAT site.
.
No agenda was presented upon arrival; the agenda we followed was this:

- On the first morning, key attendees were given 5, 7.5 or 10 minutes to present their views.

- Starting after lunch the five tracks proposed by the organizers (Ivar, Bertrand and Richard) were formally introduced to the group at about 1.5 hours each (this took through lunch on the second day). The five tracks presented were

1) Definitions

2) Theory

3) Universals

4) Kernel Language

5) Assessments

- On the last afternoon, Bertrand and Ivar each gave a prepared talk. That took the meeting to 5pm on the second day.

- After 5pm on the second day, largely because of my evident dissatisfaction with the meeting, we discussed whether SEMAT might address the questions of interest to me: what is software engineering, what do other engineering disciplines think engineering is, and how might SEMAT link to those other efforts. I offered to lead that aspect of SEMAT (and canceled that offer when I withdrew from SEMAT a few days later).

On the morning after the workshop, about 1/4 of the participants stayed over, including notably Scott Ambler, Ivar Jacobson and Larry Constantine.

- For the first hour, under Scott’s guidance, they ran an agile-styled “cardstorming” exercise to list the possible stakeholders of the SEMAT initiative.

- In a second hour, under Larry Constantine’s guidance, they worked on possible alternative tracks for SEMAT. The result was the addition of track 6) Requirements for SEMAT.

Evaluation of the Meeting

What was startlingly missing from the agenda was time to discuss the group’s purpose and its strategy for getting there. Although over quarter of the participants requested time for this at varying times and with various strength over the two days of the meeting, it was never put on the agenda. By the end of the meeting, we had not taken any time to discuss what we were there to do.

Although we didn’t discuss what SEMAT should attempt to accomplish, Bertrand produced productivity goals for us (see the SEMAT report):

50 key concepts in the definitions track,
3-5 relevant theories in the theory track, justification of their relevance, and identification of areas where theories are needed,
20 universals in the universals track, with justification of their relevance, basic design and demonstrator applications in the language track,
5 assessment techniques in the assessment track.

What it means to have productivity goals without purpose, structure or strategy is not clear to me.

What was present during the meeting was something I hadn’t expected, but has since become evident: the interest of the organizers to have a mathematically rigorous description of software development processes. The appendices of the SEMAT report contain the details. In the results of the Theory track we see:

“First, the session chair presented a short list of properties regarding the kind of rigour / formalism one would like to have. Also the range and kind of theories should be discussed. It presented a wish list, which is not intended to name necessary conditions. On the list of desired properties are: · rigor, math-based · compositionality, interoperability and · pragmatics of notations and methods.”

I look for a theory to provide explanation and prediction of what happens on a project. The organizers of SEMAT are looking for a theory to be mathematical and composable. I do not think it is possible to have both, and I think that having accurate predictions from a theory is the more important of the two.

It would be one thing if we had taken some time to properly discuss this topic during within the SEMAT workshop, but instead it is currently being taken as a given in the structure of the work.

After the Meeting

I reflected on the meeting, discussed with other people who had been following the proceedings, and concluded for myself:

The organizers have strong views about their direction which they are not yet sharing and which prevents open discussion about the important issues.
The organizers are determined to work with mathematical theories of software development, which will make their end results inapplicable in both teaching and in practice.
The organizers are too determined to create a meta-method-kernel as an antidote to the industry’s problems. A meta-method-kernel does not solve the problems listed in the call-for-action.
I misunderstood why we were in Zurich. I thought we were gathered to discuss the topics. As one participant asked on the third day, “But if we don’t do our work when we are together, when do we do the actual work?”
I don’t think the matters being discussed are significant or will improve the way software is developed.
I fear that other people will not read what is produced by the group, but will instead hang onto the names of the people involved and have faith in an outcome that won’t appear.
I don’t have the time, patience, or funding to participate on the topics that seem to interest this group at the timeframes it appears that will be involved.

At this point I withdrew my support for the initiative.

Summary and Conclusion

Let’s review why I am writing this article.

”The purpose of this article is not to dissuade those already participating in the SEMAT discussions from continuing their discussions; it is to arm those who have not been participating in the discussions and who may not be versed enough in the field to read through the spin emanating from the initiative to determine what the group is really up to.”

”To understand SEMAT, we first need recognize that SEMAT is just a group of people getting together to discuss whatever they want. They are free to discuss matters that do not interest others. They are free to change directions as they wish should they themselves feel a change is needed. To the extent that the group wishes to gain wider respect and become a funded initiative, however, they should take the critique in this article into account.”

With those notes in place, my current view is that

The call-for-action is factually and logically broken.
The use of the word “software engineering” is not relevant to the initiative as it currently stands. Further, the group is unlikely to seriously discuss either engineering or engineering theory.
The initiative should more accurately be named the Meta-Method-Kernel initiative to reflect its actual goal.
The organizers are generally not interested in the same topics I am.
Whatever they produce is unlikely to affect topics that matter to the industry.
They are unlikely to produce anything soon.

You may be interested in those discussions, or the direction of the discussions may change. Just be sure to read through the hype and past the famous names to the real content and make sure you are in the discussion you intend to be in.

Postscript: What Do I Think “Software Engineering” Is?

Based on Foundations for Software Engineering (discussion: Re: Foundations for Software Engineering) and the later Design as Knowledge acquisition (discussion: Re: Trim the Tail), here is what I think a theory of software engineering looks like (omitting the ethics portion).

Craft Professionalism teaches us about lifelong learning, deepening mastery over time, and about developing skills in a medium. For software development there are a number of significantly different craft specialities, each working in its own medium.

The Cooperative Game model teaches us about the human component – trust, morale, strategies, the importance of things like invention techniques, decision-making conventions, and the properties of communication.

Lean Processes provide useful mathematics to the design assignment, once we recognize unvalidated decisions as the unit of internal inventory. Having made this adjustment, large amounts of manufacturing theory drops in our laps.

Design as Knowledge Acquisition teaches us that we can pay to learn, and structures our efforts to optimize both knowledge gained and business value accumulated. This view helps get rid of the tension between no-design-up-front rabid agilism and all-design-up-front conservativsm.

The above theory is fairly sound and fairly complete. It does a good job of handling key criticisms and goals:

It explains project success and failures quite well,
It predicts important issues in running projects quite well,
It helps practitioners formulate effective strategies on the fly,
It provides a sound pedagogical basis for teaching.

The four elements of software engineering are elaborated in more detail in my Keynote at Agile2009.pps.
My thanks go to Philippe Kruchten for pointing out that Professional Ethics is significantly missing from the above elements. It might fit under Craft Professionalism, but since I am not an expert on engineering ethics, I hesitate to go there. I look forward to longer discussion.

Scrum on a post-it note

Sun, 19 May 2013 19:37:22 +0000

We think so slowly because the mind is a meme garden

Sat, 18 May 2013 14:42:12 +0000

(http://www.1st-art-gallery.com/thumbnail/135661/1/Tangled-Garden.jpg)

I am always amazed at how slowly we think. We call ourselves the “rational” animals, but that is not because we do it well – rather, it is because we’re surprised we can do it at all. Far from being the logical-deductive engines portrayed from the Age of Enlightenment through the late 20th century, we are – if deductive ability and rationality were a 100 meter high cliff, about half a centimeter above the flatworm.

After an important meeting, on the way home, I had follow-on ideas about it. We had the meeting, then I saw more clearly what had been happening as I walked home, and then again more later in the day, and more yet again today.

If the brain were a decent deductive engine, it shouldn’t have taken that long to link those observations.

Why do we think so slowly?

In 2001, John Carter posted a brilliant note on a Yahoo discussion group, which I captured from the internet logs and posted under The mind is a meme garden (discussion: Re: The mind is a meme garden). Besides being hilariously funny (the I am brilliant or you are stupid (discussion: Re: I am brilliant or you are stupid) neurons), it is also a fabulous predictive model of how we think.

Normally, when we (read: I) imagine thinking, we (read: I) imagine electrical waves running up and down neurons at something near the speed of light. That’s fast, right? Then why so many hours or days to connect two related pieces of information (“She’s sleeping with him? Then that’s why she wasn’t there that night when …? ... Oh.”)

But imagine instead, a tangled busy garden, the wind blowly lightly through it. The plants are thoughts or ideas. When the wind blows two leaves or plants together, they exchange chemicals. Now we see thought moving at the speed of plants blowing in the breeze, not at the speed of light.

Plant A has memory A; plant D, some distance away, has a related memory D. For your mind to connect A to D, you have to wait until the breeze blowss A into B, B into C ,and C into D, which could take quite a while depending on how the breezes are blowing that week.

And of course, you have quite a lot of meme plants in your mind, so it takes an awfully long time and an awful lot of breezes to collect together all the relevant facts about a situation.

Hence the time lag between when something happens in front of you and when you connect it to something else you wish you’d thought about right then.

I often curse the meme garden and the slow breezes, but I thank John Carter for offering such a fabulous metaphor.

(lovely image at http://bethvendryeswilliams.files.wordpress.com/2009/12/img_8420-e1259753142861.jpg)

Part 2. Meme gardens and marketing

But wait! There’s more! ...

Meme gardens don’t just explain all the above wonderful things, they also tell us that the way to influence someone isn’t to apply deductive reasoning (after all we’re only just above flatworms in reasoning, but we’re way up the cliff when it comes to emotions).

The way to influence someone is to plant a new meme, of course a virulent, bad-ass weed meme, in their meme garden.

“Plop, Plop, Fizz, Fizz, Oh What a Relief It Is”

Waterfall development is a fabulously virulent meme. “Get it right, then move on.” “Plan the work then work the plan.” No wonder presenting it’s flaws logically hasn’t changed people’s behavior much in 40 years.

Scrum, thank goodness, is dead simple: “Make a list of everything you want. We’ll tell you what we can deliver in a month. Don’t disturb us for that month and we’ll deliver it. In the meantime, update and change your list any way you want for the next month. You get deliveries every month, you get to change your mind every month.” Wow.

The “War on Terrorism” is a fabulously virulent meme. It’s also fabulously inaccurate as a metaphor – terrorism is more like a lifelong sickness you continously strive against but never eliminate; wars are things you win or lose but that come to end. It doesn’t matter though, “Long-term striving against the ongoing unconquerable sickness of terrorism” isn’t going to hold its own in the meme garden against “war on terrorism”.

The rules for how to create a virulent meme are allegedly in the book Made to Stick, by someone and someone else. They’re brothers (I think). One’s a professor. They summarize their advice with the acronym SUCCESs.

I can’t remember what the acronym stands for, mostly just that we are not to write the last s as a capital letter. So it’s not SUCCESS, but SUCCESs. And one of the Cs is for concrete : make it concrete. I guess the acronym SUCCESs isn’t concrete enough for me. ... And one of the Ss is for simple. I guess the 6 elements of SUCCESs aren’t simple enough for me. It’s clear SUCCESs isn’t a virulent meme.

Hunt for your own virulent meme weed thing. I’d probably start by studying advertising, not logic.

(http://farm1.static.flickr.com/179/438102368_fba9612cc9.jpg)

Just released - Microsoft Enterprise Library 6

Fri, 26 Apr 2013 00:55:00 +0000

Five months ago we formulated our vision for the new version of Enterprise Library. Now we are delivering on it. I’m excited to announce the latest release of Microsoft Enterprise Library: version 6.

What is Enterprise Library?

Enterprise Library is made up of application blocks, each aimed at managing specific crosscutting concerns. Crosscutting concerns are those tasks that you need to accomplish in several places in your application. When trying to manage crosscutting concerns there is often the risk that you/different team members will implement slightly different solutions for each task at each location in your application, or that you will just forget them altogether. Writing entries to a system log file or Windows Azure table storage, dealing with transient error conditions and validating user input are typical crosscutting concerns. While there are several approaches to managing them, the Enterprise Library application blocks make it a whole lot easier by providing generic and configurable functionality that you can centralize and manage.

Enterprise Library application blocks are standalone. They work well together, but you only have to get the ones that you need. They are also customizable and extensible, so you can extend them to provide what you need in your specific contexts. You can choose to use it as a seedwork and grow your own library, which you can later reuse and sell. We ship under MS-PL, so this is allowed.

What are the main themes for this release?

Simplifying the library all around
Embracing semantic logging
Increasing resiliency to errors
Enhancing Unity type registration
Supporting Windows Store apps (Unity, Topaz)
Streamlining programmatic configuration of all blocks
Integrating with other technologies (ASP.NET MVC and ASP.NET Web API)
Improving ease of learning, ease of experimentation (fast start), and ease of use

What’s in the box?

New block

Semantic Logging Application Block (v1.0)

New programmatic configuration
Updated 7 blocks:

Data Access Application Block
Exception Handling Application Block
Logging Application Block
Policy Injection Application Block
Transient Fault Handling Application Block
Validation Application Block
Unity Application Block/DI Container (v3.0)

Configuration console (largely unchanged since v5)

As usual, we are shipping not only the binaries, but also the source code and test cases (unit, integration). To see the details of what have changed and deployment instructions, see the Release Notes.

The diagram below depicts all application blocks and their dependency on the Common package (needed to support configuration tool experience) and optional interblock dependencies.

Additionally, in the next couple of weeks we’ll be shipping a reference implementation and several Quickstarts to showcase how the Enterprise Library can be used in certain scenarios.

How to get it?

Our primary shipping channel for code is NuGet. There are 27 NuGet packages. Search for Unity or EntLib inside NuGet Package Manager.

Additionally, we’ve made all deliverables available as self-extractable zip packages via Microsoft Download Center.

Our guidance deliverables are available on Codeplex today. After post-production work is completed, they will be published on MSDN. You will also be able to order the hardcopies of the Developer’s Guides or get them in PDF, Epub or Mobi formats.

How to get started?

Whether you are experienced with Enterprise Library or new to it, we have guidance to help you make the most out of this release:

Dependency Injection with Unity – new Developer’s guide (preview on Codeplex)
Updated Developer’s Guide to Enterprise Library (preview on Codeplex)
Updated reference documentation (preview on Codeplex)
Reference implementation (v5 and v6) (available in May)
Reference API (on MSDN)
Quickstarts (available in May)
New Migration Guide to help you move from v5 to v6
Videos (on Channel 9)

The table below will help you orientate:

Do I have to upgrade?

Strictly speaking, no. If you are happy with Enterprise Library 5.0, you can continue using that version. If the new and improved features of Enterprise Library 6.0 appeal to you, then you would want to migrate. Note: Enterprise Library 6.0 targets .NET4.5 framework only. Enterprise Library 5.0 works fine on .NET3.5, .NET4.0 as well as .NET4.5. So, in order for you to move to .NET4.5, you don’t have to upgrade.

How to get help and provide feedback?

Many people provided feedback on our vision, our backlog and CTPs. We thank you all.

If you’d like to provide further feedback, please post it via the Codeplex forum. This is where you can also get support. We have a dedicated sustained engineering team monitoring the forum regularly. To report a bug, use online Issue Tracker.

If you have a story of how your team leverages EntLib and would like to share it with the broader community, please contact us. We’ll be happy to work with you on a case study.

Happy coding!

Agile Feeds

Courses

Courses available by request only

Re: DAKA: The Design-as-Knowledge-Acquisition Movement

The Design as Knowledge Acquisition Movement

Re: A user story is to a use case as a gazelle is to a gazebo

Dealing with Windows Azure Storage transient faults

Preamble

Retries in Windows Azure Storage Client

Why would you want to use Topaz's retries instead of the built-in retry support from the Windows Azure Storage Client Library?

Does this mean that Topaz does not support Windows Azure Storage Client Library v2?

Can you show me the difference in usage?

Re: Oath of Non-Allegiance

A Detailed Critique of the SEMAT Initiative

Author’s Note

Background

Quick Summary

Stage 1: The SEMAT Call For Action

The Authors

“Method Needs Theory”

“Why We Need a Theory for Software Engineering”

“The SEMAT Initiative: A Call for Action”

Stage 2: The SEMAT Call For Action

The Problems SEMAT Proposes to Address

The Solutions Proposed

Summary of the Call-For-Action

Stage 3: The Zurich Meeting

Evaluation of the Meeting

After the Meeting

Summary and Conclusion

Postscript: What Do I Think “Software Engineering” Is?

Related reading on this site

Scrum on a post-it note

We think so slowly because the mind is a meme garden

Just released - Microsoft Enterprise Library 6

What is Enterprise Library?

What are the main themes for this release?

What’s in the box?

How to get it?

How to get started?

Do I have to upgrade?

How to get help and provide feedback?