Looking Back

  • Comments posted to this topic are about the item Looking Back

  • Sounds like the Japanese industrial process known as Kaizen.


  • I think "Evolution" is a good concept to keep in mind in improvement exercises - and, especially, the follow-on. Why? The theory of evolution includes "The Survival of the Fittest". What I find so often in my work is "The Survival of the Unfit Legacy". Something has been superseded for a good reason, purge it! So often the job of implementing a good change is never finished. Evaluation exercises have a reputation for being ineffective because the outcome of the exercise is never completed. That completion includes not only the work going forward but also all the legacy that does not comply.

  • I have not been fortunate enough to work on a team that did retrospectives. There were normally a few of us who wanted to, but it never happened. I was one of those who wanted to learn from what we did, when working on a big problem, but it  never happened. Perhaps the manager thought about it. Perhaps it was just the need to start the next thing.

    On the other hand, I've never been a part of a "ship party" whenever we released anything. My experience has always been, "OK, you got project A done; now onto project B." Perhaps the same thought processes are in play, if no one either celebrates a win nor spends any time learning from overcoming a huge challenge?

    Kindest Regards, Rod Connect with me on LinkedIn.

  • I think the article just misses a very important point. Direct democracy often fails. While I believe leaders should seek input from those they are leading, they should remain leaders and in charge. A leader should also know that just because something is my biggest concern doesn't mean it is my biggest problem.

    As for the lack of retrospective or celebration I think it comes from failed management theory. I hope that most managers will learn from this pandemic and adjust their theories accordingly. I suspect the nature of remote work will change at any rate. Even for those who don't bother to look back.

  • Something has been superseded for a good reason, purge it!

    The purging of legacy stuff will require code changes and thus introduce risk, while keeping the (now non-functional stuff) around may be inefficient but also avoids the risk of changing something that still "just works". Where possible I generally prefer to postpone purges until the code has to change anyway due to new requirements. Not exactly ideal but less risk.

Viewing 6 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic. Login to reply