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