Everyday Kanban

Discussing Management, Teams, Agile, Lean, Kanban & more

Category: Agile (page 7 of 8)

Is your Agile agile?

I noticed today that I’m starting to channel people like Jim Benson without even realizing it – until afterwards. I found myself explaining to someone at work today that the tendency to prescribe to others how things should have to be done is pervasive, even in – or maybe especially in – many “Agile” implementations (yes, that’s with a capital A). Upon reflection, I think it is a hallmark of many Agile initiatives driven from the top-down through standard command and control structures. You end up making a complete new command and control structure under a new name and the part that kills me is that you don’t even realize it.

There’s a misconception that standardization is a holy grail. If something works for one team – or maybe, its just the way someone decided to start doing Agile – then everyone should do it. What happened to self-organizing? … to agility? … to the ability for a team to recognize that they are doing something that’s suboptimal to their end goals and then change that thing? Should there really be sacred cows? A quote that stuck with me is that “standardization often inhibits optimization.”

Continue reading

Measure twice, cut once?

Last week I attended my first Lean Coffee here in my new city, Seattle. It was a great experience that I look forward to going to again. In fact, I suggest that everyone look for a Lean Coffee in their area, or create one!

At this Lean Coffee I was challenged, albeit nicely, on my desire for my development team to do more thinking before execution and creating more design documents. In fact, I’m strongly encouraging it in my team. The premise to the challenge is that this felt more waterfall than agile. That, maybe it is preferred to do a rapid prototype approach with a higher acceptance of risk.

Continue reading

The only constant is change

Businesses want ultimate flexibility and speed to market. Developers want complete requirements so they can do their jobs right the first time without a lot of back and forth. Historically, companies have implemented a waterfall approach in which all the requirements are complete before any development is done. It can take a while to gather all the requirements for large initiatives and then just as long, or longer, to develop against those requirements. After that is done, a single long round of QA testing is undertaken and only then do products release to the wild.

Who’s happy in that scenario? You would think that developers win and businesses lose. The developers got exactly what they asked for, right? Continue reading

« Older posts Newer posts »

© 2025 Everyday Kanban

Theme by Anders NorenUp ↑