bdehaaff

How about a series of Haikus? Building size is not poetry.

I tend to agree with you on this. I don't understand the ruling.

Indeed. The response was terrific and we were humbled that so many folks wanted to participate.

Thanks for taking the time to respond.

Agreed. It's fundamental to address the "whys" and "whats" in addition to the "hows."

Agreed. The point I am trying to make is the following: I think you need to do both and that's why building great products/software is hard. You need to see the big picture yet deliver against it in bite-sized chunks. Good PMs and Engs are capable of doing both at the same time. That's the key. Give folks responsibility for owning big ideas and allow them to get their work done in an agile, incremental way. Kanban really is about the incremental "getting there" part.

I think there are all types of tools and techniques that can work. The fact is that Kanban or any other tool can not fix lousy strategy, culture, or leadership.

There is a good overview here for Kanban for development: http://en.wikipedia.org/wiki/Kanban_%28development%29

Thanks for the detailed thoughts. I am not sure though that Kanban or an other agile tool can solve the problem when it is one of leadership or direction. Strategy and management do not rise out of the incremental planning bits.

Yikes. Who vets what comes down the line vs the key business objectives? And who is looking out past three months to make sure you are building what will matter as the market shifts? I feel for you.

The point I am trying to make is the following: I think you need to do both and that's why building great products/software is hard. You need to see the big picture yet deliver against it in bite-sized chunks. Good PMs and Engs are capable of doing both at the same time. That's the key. Give folks responsibility for owning big ideas and allow them to get their in an agile, incremental way. Kanban really is about the incremental "getting there" part.

I think you need to do both and that's why building great products/software is hard. You need to see the big picture yet deliver against it in bite-sized chunks. Good PMs and Engs are capable of doing both at the same time. That's they key. Give folks responsibility for owning big ideas and allow them to get their in an agile, incremental way.

True. As you point out it starts with understanding why something needs to get built and its importance to the business. If you do not have clarity on that, everything looks like a priority.

I would suggest the core issue was that you did not have the freedom to go get the important work down and be responsible for it. Too often work is subdivided so no one actually owns anything important -- because the bits are too small.

You touch on another interesting area. How to rank the importance of features. I am careful to highlight our own work, but do a search for Aha! Scorecards and Aha! Scores. We introduced a way for teams to enter into their account their own key business metrics and then rank features against them. It's hard to game the system when you are asked to rank the importance of features against real business goals (sales, support, internationalization, mobile, etc.) and then forced to defend your rankings if there is disagreement.

Totally agree. The challenges are multi-faceted, but one of the biggest issues is that it's not for deciding the "whys" or "whats." Why we are doing something is strategy and what and when we are going to deliver is the roadmap. Kanban can be used for working on the "hows" (even though it was never intended to be a software development framework).

Thanks for the comment. The point is that using Kanban or implementing "agile" is not a savior from the engineering death spiral. The post includes that exact point in the first paragraph.

Great insights. Give the folks who can get the work done the freedom and responsibility to get the work done. Managers should remove barriers -- not impose additional ones ever time something goes wrong. It's hard enough to build great software.

Great. Thanks for sharing this success story. It would be interesting to know if the engineering team is motivated and understands the why they are building what they are.

Kanban does nothing to solve the product strategy and market fit questions and is often applied as a fix-all for much deeper rooted problems. I would also argue that Kanban has the tendency to turn engineers into widget builders and is demotivating. Here, take this tiny piece of work and when you finish it I will reward you with another. Keep your head down and just trust me.

True. That's one of the ways that you end up in this engineering death spiral -- bad market / product fit and thrashing strategy.

Yep. Big change is needed one way or another because the ground is approaching faster than most teams in the death spiral think.

I love the honesty of this story and I wish it were told more often. I just kept nodding. You did touch on one concept that I almost added to the piece... "we always do it like that". If this post continues to grow in popularity I think I will add an "after thought" with additional insights like what you shared. Thanks.

Exactly. Put the folks who can get the work done in charge of actually getting the work done. Give them the responsibility and allow their courage to flourish 9and remove barriers when needed). Celebrate their accomplishments.

Yes, I think you are saying that the focus needs to be on results. Not effort. I agree, but is that what you are highlighting with your comments?

It's been fixed.

Thank you for pointing that out. Grateful for the call out. Best.

Very true. There is always some new "fix it." The problem is often that the engineering tools do not improve product management in the least and if the product strategy is bad and customer understanding is missing, no engineering team or tool can solve that.

Personal experience after being an early employee or founder of six software companies and knowing or speaking directly with folks in hundreds of others. Simple experience and pattern recognition. Not science.

Thanks. The point is that applying simple tools like Kanban or trying to "shock" the system by "becoming" agile typically does not work because these tools do not address the underlying issues.