My most Relevant posts on Agile organized for your Tight Timeline

Note: This is a sticky post and not necessarily the most recent. Scroll down for the most recent postings..

However if you are new to this blog you should definitely read this post!

Since blogs in general and this one in particular tend to highlight recent postings, and since reading my recent postings alone might lack context,  I’ve decided to curate many of my most relevant blog postings together in an order that will provide the most context for the reader.

Post Agilism: Moving beyond the Outdated and Misdirected aspects of Agile

A Flattened Cost of Change Curve: An economic analysis

 The High Cost of Emergent Design/Subsequent Refactorings

By Popular Request: What my Approach Is

The flawed rhetoric about “Scrum” and “Organizational Dysfunction”

Is the Agile Community still “uncovering better ways of developing software…” or just debating whether to implement Scrum or Kanban?

Scrum as the new “Command and Control”

Is Scrum just a series of Mini Waterfalls?

Rhetorical Anti-Patterns in Scrum and XP

Agile and Waterfall are two sides of the Exact Same Coin

And some Humor with a heaping dose of truth

Howto: Create and Promote a new (but popular) Agile Methodolology

Scrum Deprogramming Seminars Coming to a City Near You

The New New Agile Manifesto

Planet of the Extreme Programmers

Posted in Uncategorized | Tagged , , , , , , , , | Leave a comment

Challenges in Mobile Development

As I’ve been working in the mobile field quite a bit lately I’ve identified some “pain points” related to mobile development.

Since I’ve been involved in software development since it predated Mobile and even the Web, I’m surprised at how chaotic and frustrating mobile is compared to more traditional endeavors.

Here are some I’ve identified

  • Unlimited Parrotism — although one might think, that, mobile would be filled with unique applications, in fact, what clients are hiring for is a lot of “me 3” type stuff. Yet another Skype. Yet another livingsocial. Yet another uber. But catered to some niche. *Yawn*
  • Ridiculously Short Time Frames — I remember when a 6 month project was a short project. Then when a 3 month project was a short project. Now, people want a full fledged app, on “all” android devices, in 3 weeks. Um sure?
  • Lack of Understanding that there is R & D: There isn’t just execution there is you know, like Research and stuff? Valuable? R&D? With an R?
    Sprint 0? Heresy! Sprinting at all? Stupidity! Just whip the field hands. ‘Nuff said?
  • Clueless newbie managers — Out there to whip the devs who have 10x more experience than they do to follow their cargo cult scrum process down the rabbit hole.
  • Signing Meaningless NDA’s just to have a discussion — OK, your knockoff of uber has zero intellectual property. And you want some sweat equity deal or $10/hr rate. OK, so why make everyone spend time and money on this NDA stuff? Just say your idea. Money is in the execution. I don’t have time to waste on your NDA’s and if I do sign them it’s only because they are worthless since there was no consideration (eg, money paid). Enough with this NDA stuff

Feel free to add to the list especially with suggestions on overcoming some of these!


Posted in Uncategorized | Tagged , , | Leave a comment

The Difference between Scrum and kanban approaches

Today I’m going to talk about the difference between Scrum and “kanban” type approaches.

To make things simple, I am going to coin a new acronym — CFS — meaning continuous flow for software development — as a genericized “kanban”  approach

There are many interpretations of kanban and so  dealing with it as a general sotware case  — as opposed to it’s legacy manufacturing heritage or even David Anderson’s “Kanban” will uncover what is really the magic sauce here.

Therefore I will use “CFS” or “continuous flow” instead of the word “Kanban” most of the time.

In a nutshell a CFS

  1. Focuses on doing the most important work first
  2. Focuses on completing work already started
  3. Focuses on quality of each step completed
  4. Limits work in progress

That is it. Don’t worry about the Japanese, the manufacturing, anything else. In a nutshell that is what a continuous flow system looks like.

Worrying about whether the system is “push” based or “pull” based is also not really important; it could be either or both; what matters is that the highest priority work is worked on, and things get completed.

How is that different from Scrum? Don’t they both have a taskboard with roughly similar columns?

To understand this, consider the difference between a 4 stroke gasoline engine and a jet engine.

In a 4 stroke engine, power is delivered in discrete phases — sort of sprint like chunks. There is a lot of complicated gearing and timing to make sure that the fuel is sprayed in at the exact right moment, etc.

Fuel can only be added during the injection cycle — just like tasks can only be added to the beginning of a sprint.

A 1 cylinder gas engine would lurch forward every so often, just like a one man team “sprinting” through scrum.  In a gas engine multiple cylinders are staggered in time to simulate continuous power output. In scrum however, all the cylinders are aligned so that the entire team lurches forward every sprint, but farther.

As you can see above — there is a lot of complex gearing and overhead just involved in keeping all the timing coordinated. Just like in Scrum.

In a jet engine, everything is happening all the time, or at any time. You can add fuel whenever you want to, air and fuel get mixed and combusted with no particular regard to the timing of any particular sets of molecules, etc.

In the diagram above, the yellow/orange areas are where fuel is burning. It can burn at any time or all the time, air moves from the front, and out the back. Note there is no need to correlate and synchronize any of the blue arrows. It’s a continuous flow system.

Scrum requires but CFS does not:

  1. Tasks/stories be delivered together in chunks, called sprints
  2. To achieve this, these need to be estimated
  3. Scrum commits to completing these tasks even though the estimation is vague
  4. There is huge pressure to complete tasks at all costs in a given, with quality and technical debt as the first casualties —
  5. There is a huge set of sociopolitical theology associated with Scrum, such as no titles, do the simplest thing first, no prototypes, YAGNI, etc
  6. Scrum focuses on timeboxing work into discreet phases for no apparent purpose, similar to how a gas engine focuses on discretizing combustion — for a small car that might be ok, for a passenger plane it isn’t efficient enough to consider doing anymore
  7. Everything must be potentially shippable — all prototypes are endless maintenance exercises since the product is the prototype

CFS does not require

Estimates? You can do them or not do them in CFS.

All day  planning sessions? Relatively unnecessary in CFS, but they can be done if you want them.

Retrospectives? Up to you.

Demos? Whenever you want.

Delivery? Whenever you want.

Documentation and prototypes? Up to you.

User stories or tasks? Tasks are fine.

No experts? Architects and planning/prototypes are fine


I hope this helps and please feel free to ask questions


Posted in Uncategorized | 3 Comments

Retrospecting my blog


Do you find this blog informative? Please comment below and let me know your thoughts so I can improve/focus/clarify what topics are most useful to readers.

Also, if you find this blog, or various postings useful: please feel free to share links etc with your colleagues and coworkers and yes, even social media fans.

My goal here is to help share information and getting into six degrees of sharing is always a good thing!

Thank you,


Posted in Uncategorized | 16 Comments

New York Post Agilists

In good news for post agilism, a group of PostAgilists is gathering in NYC tonight.

This is great and I’d like to see these types of activities springing up in cities around the world!

For those attending in NYC feel free to post some comments as to what was uncovered and discussed to share with your fellow postagilists!

Posted in Uncategorized | 1 Comment

#NoEstimates and all that

Lately there has been a fracas brewing about the “No Estimates” movement.

I have some meta commentary before diving into the subject at hand.

First of all, like “agile vs waterfall” itself, or the agile word itself, “no estimates” tries to capitalize on novelty, disruptive shock value, and binary thinking as opposed to a holistic reasoned discussion.

Let’s all agree on something — estimates are vague. How vague are they?

While I agree that we should let everyone know that estimates are — well estimates, and not guarantees, it’s folly to think that we should do no estimating. (Note this means I don’t agree with sprint “commitments” — especially in a vague or no estimate world).

Of course, the NoEstimators will say, well we didn’t REALLY mean NO estimates, that’s just another case of bait and switch and false advertising, similar to “agile” — why not call it deemphasized estimates?

So now on to the crux of the issue.

The estimates will get more accurate as the work is done.

Let’s say I own a 1920’s Victorian house and I say, oh, well, I want better, more energy efficient windows.

How much, dear Contractor, will it take to upgrade my house so all the windows are double pane glass, with or without LCD dimming.

Well, they can guess, but only after digging through each and every window frame will they determine, how much moisture rot there is, if any, how much termite damage there is, if any, how much settling of the house in any particular area might cause framing issues, etc.

So it’s like a Mandelbrot curve. The coastline gets  longer the smaller caliper you measure it with.

Any upfront estimates will be saddled with the Mandelbrot problem —  so let’s admit that.

That doesn’t mean estimates are useless, it means the estimates have a margin for error.

Let’s talk about that and bring it out into the open, not grandstand with shock value reactionism in hopes of getting linkbait.

We need modulated, varied reasoning, not drawing lines in the sand for shock value. Shock value won’t sustain lady gaga and it won’t sustain modern software development.

My proposal of range estimation ( which predates the NoEstimate movement, is a good place to start in this regard — not that I invented it — and I think this is a better root for discussion — as it avoids the extremes and focusses on the reality.


Posted in Uncategorized | Tagged , , | 1 Comment

Hating on Agile goes Mainstream

It had to happen sooner or later — as much as the Agilistas want to paint a picture of fuzzie bunnies, and shiny happy developers, now that more companies have considerable experience with agile and scrum, they are more than anxious to rid themselves of it.

What’s even better, more people are coming out and telling it like it is, versus being suppressed by agile propagandists and apologists.

A sample of recent blog postings along these lines:

In Talia mentions the following:

  “Velocity” is a unicorn. Things are never the same from sprint to sprint: there’s a holiday in the middle, someone takes a vacation, or gets pulled into debugging production issues. Even if everything else were perfect – spot-on estimations and no mid-sprint requirements – you still wouldn’t be able to accurately compare productivity from one sprint to another.

In the author mentions:

The second flaw, development over planning, hits the agile principle of “responding to change over following a plan.” In theory, developers code while collaborating with stakeholders to define, refine and change requirements as the projects goes along. The methodology, however, does not distinguish between big and small changes.

Every change has a cost, but agile does not account for this. The result? People often change really big things late in the game using the rationale that since it’s an agile project, it can handle it. The only way the project can handle this is by adding iterations. As that happens, defects that might have been easy to fix at one point get harder and harder to fix, since the code base keeps changing.

This principle encourages poor and irresponsible planning while hiding its effects. As iterations continue and the defect list grows, the customer becomes more frustrated-not only because of the lack of quality, but because delivery expectations aren’t being met either. This is much different from more traditional practices, where you have a project based on well-defined requirements and changes are managed through a Change Management process-which, while sometimes byzantine, will at least state time and monetary costs more clearly.


“There is no process. Things fly all directions, and despite SVN [version control] developers overwrite each other and then have to have meetings to discuss why things were changed. Too many people are involved, and, again, I repeat, there is no process.”

“Sometimes that “Agile means disorganization” mindset encourages users and clients to interpret the process as “It’s okay to be capricious.” Yes, Agile does permit users to swap priorities even towards the end of a big project. But developer Sorin Costea observed the downside when things worked smoothly: “These users could not believe there are also limits to the delivery power. They could not really grasp velocity or timeboxing, but expected to throw in stories any moment and also get them in time.” With the reasoning that, “Hey, we are Agile aren’t we?”   is a well known post and definitely worth a read, as is


Posted in Uncategorized | Tagged , , , , | 5 Comments

The Incredible Logic of Agile

Webster defines incredible as: too extraordinary and improbable to be believed.

Most of the incredible successes of agile, are in fact, incredible. I’ll be blogging about how some of these successes were actually colossal failures.

But what is equally incredible are the claims, and so called logic, that props up the deceptions that are the foundation of agile.

To be agile is to be free from the constraints of logic, and if you don’t believe me:

How often do you see…

  1. Using opinions/statements as fact: “Agile means to do xyz”  — It’s merely the opinion of the speaker, but it’s stated as a fact
  2. “Hyperproductive Scrum Teams” — while defining hyperproductivity in terms that are extremely suspect, such as using worst case as baseline, and using story points instead of real time units
  3. Calling Failures Successes– The C3 project that XP was initially used on was 6 years late and 50% complete. If it had been completed it would have been a dozen years late. That’s a success?  Scrum was used at Easel, a bit player in the Smalltalk world before Scrum and just as much a bit player afterwards. Delighted customers?  If there were any, they didn’t move the needle. Yahoo and Myspace were big Scrum users, even “hyperperforming” according to some reports. Hyperforming at lawndarting?
  4. “Do the simplest thing first” — Um, wouldn’t that be a prototype? But prototyping is forbidden in agile! Everything has to be “potentially shippable” (note: a mere statement of opinion by someone that has since been enshrined as fact) even given…
  5. “TDD” — if 90% of a system is never used, why write unit tests for it? If the situation is changing so often you don’t know what the customer wants, why write unit tests for it? Maybe after you decide what you want and the system stabilizes is a good time to write tests eh?

I could go on and on but please…. share your stories of the Incredible Logic of Agile!


Posted in Uncategorized | Tagged , , , | 2 Comments

Get your Agile Laundry

Recently an agile blogger had tweeted that the most mundane tasks can seem cool, if you preface it with the word agile. Eg, “Agile Laundry”, “Agile Chores”, etc…

I had responded with, well, maybe you’ll finally realize that agile has always been about buzzwords and scamming?

Anyway this morning I was reminded of that Don Henly song, “Dirty Laundry”, and so, without further ado and with apologies to Don Henly I bring you — Agile Laundry!

Continue reading

Posted in Uncategorized | Tagged , , , , , | 1 Comment

The Difference between “Agile” and “Lean”

The difference between agile and lean is simple to understand, but most people feel they are somehow equivalent.

They are not.

Lean — is designed to reduce waste and improve operational efficiency, especially related to repetitive tasks as often in seen in manufacturing.

Agile — is designed to execute tasks over a short time frame, with frequent customer involvement, and to be able to make changes quickly.

As you can see they have nothing to do with each other per se — one doesn’t need to be innovating new product to be lean, and one doesn’t have to be operationally efficient to be agile.

So why the confusion? One reason is that many people don’t understand the difference.

The larger reasons for the confusion is the vendors see both “Lean” and “Agile” as hot buttons and so they all say their method does both. “Scrum is Lean” shrieks Jeff Sutherland. “Lean is Agile” shriek the kanban vendors.

They themselves dilute the meaning of their own value propositions such as they exist.

They use a logical fallacy — that if A is “good” and B is “good” then A and B are equal and interchangable!

They are not — apples and oranges are still different, even if they both are useful.

Finally, it’s worth noting, that companies that revolve around operational efficiency (pumping out cheaper clones of competitors products) don’t last very long in the marketplace.

What works in manufacturing may not be appropriate for software development.

“Lean Startup” may in fact try to combine elements of both, but that doesn’t make Agile inherently Lean nor vice versa.

I question the validity of the “Minimally Viable Product” in any case — they are of the opinion that if you get there first you will own the marketplace.

Lots of people got there before youtube, lots of people got there before google and lots of people got there before facebook (myspace anyone?).

People need to understand and choose what to optimize for in their unique context, not just grab off the shelf buzzwords that other people fancy.

It would seem that marketplace is voting for the superior product, not the one that got there the cheapest (lean) or quickest (agile).


Posted in Uncategorized | Tagged , , , | 4 Comments