This is the fourth (and possibly final!) installment of my series of posts discussing why Agile may not be working for you or your organization. Part One focused on the role of culture and training; Part Two focused on the importance of continual improvement and evangelism; and Part Three focused on lack of knowledge, lack of commitment, and lack of demonstrable progress as contributing factors. In this installment, we’re going to talk about what you can do when you encounter situations where Agile (or “agile”) approaches aren’t working — small things that you can do to influence and support the transition of your teams, organization, and culture.
Archives for March 2016
If you’ve been on the job market in the past several years, you’ve undoubtedly come across the phrase “bias toward action” in one or more job descriptions or company overviews, or even during a call with a recruiter. It’s become something of a buzzword, and in the way that many buzzwords do, has a meaninglessness to it that often causes us to shrug it off as just another “thing that ‘they’ say”. The problem is that having an “bias toward action” can also be code for “completely unstructured” or “constant fire drills”, so rather than shrug it off we should dig deeper to uncover the real meaning behind the term for that particular organization.
A very common topic of discussion amongst Product Managers in general, and Agile practitioners in particular, involves the comparison of different forms of process and project management. By far the most prominent and popular of these are Kanban and Scrum. And, much to my own personal dismay, often these discussions wind up devolving into some form of “religious war” between fanatical fundamentalists on either side — insisting simply and without substance that their way is the best way.
The simple fact is that one is not necessarily better than the other — when, how, and where you use either of these approaches depends greatly on what problems you’re trying to solve, what kind of culture you have or want to have, and how the people you have doing the actual work want to manage themselves. To say, in broad strokes, that either Kanban or Scrum is objectively “better” than the other misses the point entirely. Both are equally good and equally bad, depending on the circumstances.