Skip to main content

Agile Management vs Herding Cats

I recently blogged about agile, building teams and herding cats. It's a topic that's always close at hand. I've had several job interviews over the last 4 months and agile always comes up.

Agile used to mean the tight feedback loop between the client and the producer (the producer can be a programmer). Today it has come to mean so much more.

I asked an agile coach, friend of mine, about the cats and agile thing. His response was that you cannot heard programmers like cats. And that you had to have strong leadership and define clear goals.

So I went back to my Agile Project Management book and started thumbing through. I found a passage where the author said that teams were meant to be self organizing.

All of the contradiction is making my head spin.

Agile Suggests:

  • there are no managers

  • that the teams might be made up of cats, but so what, they will self organize

  • priorities are set by project managers who manage projects and not people

  • producers don't have to make value decisions just do the work

But my friend suggests that:

  • you need a strong manager

  • clear goals (probably priorities)

  • don't bother with the cats, that's so yesterday

hmmm... So I skimmed my Scrumban and Kanban books again; looking for references to teams. The common "self-organized" statement was there... but that was it. And then Eureka.

Agile Project Management is meant to be implemented by strong and seasoned managers. Managers who already heard cats at an intuitive level. And so my blood pressure is resuming it's normal level as I recognize the fact that strong/good managers already herd cats and probably to agile on the fly by intuition; where new PMI, paper dragons, rely on the strictest sense of the "written" agile process instead of a functional blend between project management and people management.

PS: Many years ago I took a class on "root cause analysis" that was being given by a consultant for my employer. Root cause is pretty easy to do; it's essentially a recursive investigation into the mathematical significance in the problem/error space. The instructor was clear to say that noobs should recurse down all paths until the numbers were flat. And more importantly leave intuition out of it. Your intuition will work but later. This was practical advice because "we" were always in the data. Day-in, day-out. This is different than management. There is room for intuition in people and product management. But you need "strong" skills to be there.

Agile is ok. I'm certain it works. But it should not be the only tool in the managers toolbox. Teams, people and projects are much more complicated than this. Otherwise the ten commandments would have been enough.


  1. My suggestion? Learn the buzzwords, and have enough knowledge to have a conversation with a hiring manager mapping what you've done and the way you've done it to Agile concepts. I agree with your friend. You need a strong manager to remove roadblocks.

    I think Agile was born out of -- as you say close producer - client relationships -- the ability to shorten those very cycles, because of languages like Python and Perl, where you can get a lot of function going quickly.

  2. I agree. The challenge, however, is when someone asks "Do you know Agile?" or they want a definition or "What does agile mean to you?" It's actually a sign that they might be misusing agile. The fact of the matter is that Agile seems to be more of a process than anything else. And as such is is subject to adjustments from the user-space. While there are descriptions, explanations and rules... there is nothing that is absolute. At the end of the day you have to use what works. I think the best answer might be a sort of self referencing response:

    Q: What does agile mean to you?

    A: Agile is a set of practices or processes whereby the stakeholder set priorities for smaller tasks/assignments that result in the completion of a bigger project with short feedback loops to the stackholders in order to allow for adjustment in future prioritization.

    NOTE: I just cannot bring myself to say that "the teams are organizationally flat and allowed to self-organize." It feels too... (I don't know) socialistic or "socially ideal".


Post a Comment

Popular posts from this blog

Entry level cost for CoreOS+Tectonic

CoreOS and Tectonic start their pricing at 10 servers. Managed CoreOS starts at $1000 per month for those first 10 servers and Tectonic is $5000 for the same 10 servers. Annualized that is $85K or at least one employee depending on your market. As a single employee company I'd rather hire the employee. Specially since I only have 3 servers.

The pricing is biased toward the largest servers with the largest capacities; my dual core 32GB i5 IntelNuc can never be mistaken for a 96-CPU dual or quad core DELL

If CoreOS does not figure out a different barrier of entry they are going to follow the Borland path to obscurity.

UPDATE 2017-10-30: With gratitude the CoreOS team has provided updated information on their pricing, however, I stand by my conclusion that the effective cost is lower when you deploy monster machines. The cost per node of my 1 CPU Intel NUC is the same as a 96 CPU server when you get beyond 10 nodes. I'll also reiterate that while my pricing notes are not currently…

eGalax touch on default Ubuntu 14.04.2 LTS

I have not had success with the touch drivers as yet.  The touch works and evtest also seems to report events, however, I have noticed that the button click is not working and no matter what I do xinput refuses to configure the buttons correctly.  When I downgraded to ubuntu 10.04 LTS everything sort of worked... there must have been something in the kermel as 10.04 was in the 2.6 kernel and 4.04 is in the 3.x branch.

One thing ... all of the documentation pointed to the wrong website or one in Taiwanese. I was finally able to locate the drivers again: (it would have been nice if they provided the install instructions in text rather than PDF)
Please open the document "EETI_eGTouch_Programming_Guide" under the Guide directory, and follow the Guidline to install driver.
download the appropriate versionunzip the fileread the programming manual And from that I'm distilling to the following: execute the answer all of the questio…

Prometheus vs Bosun

In conclusion... while Bosun(B) is still not the ideal monitoring system neither is Prometheus(P).


I am running Bosun in a Docker container hosted on CoreOS. Fleet service/unit files keep it running. However in once case I have experienced at least one severe crash as a result of a disk full condition. That it is implemented as part golang, java and python is an annoyance. The MIT license is about the only good thing.

I am trying to integrate Prometheus into my pipeline but losing steam fast. The Prometheus design seems to desire that you integrate your own cache inside your application and then allow the server to scrape the data, however, if the interval between scrapes is shorter than the longest transient session of your application then you need a gateway. A place to shuttle your data that will be a little more persistent.

(1) storing the data in my application might get me started more quickly
(2) getting the server to pull the data might be more secure
(3) using a push g…