Friday, September 9, 2011

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.

2 comments:

  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.

    ReplyDelete
  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".

    ReplyDelete

prod, staging, QA, dev in your CI/CD?

I've been developing with CI/CD since before it was a straw, let alone a pipeline. No, graduates of 2020 you did not design or discover ...