I’ve talked before about the dangers of a “cargo cult” mentality when it comes to Agile practices, but in this instance I’m going to take a Devil’s Advocate position, at least it will appear that way. All too often, people and companies start their Agile transitions with training about the “theory” of Agile — what it means, how it should work, what glorious and wonderful benefits are, and to attempt to indoctrinate people into concepts that may be entirely foreign to them and how they’ve done their work in the past. The problem is, nobody really cares about theory — and all too often the theoretical underpinnings are lost as soon as people get back to their desk and start their next day of work. Here, however, I’m going to propose a plan to implement Agile practices without the theory, and without creating a “cargo cult” mentality where you’re just going through the motions without understanding why…
Everyone in tech has seen the word, repeated ad nauseum as the “silver bullet” for everything from go-to-market timing to quality to product discovery. But like many terms bandied about by those both within and on the periphery of Product Management, the term “iteration” often comes with connotations or meanings attached to it that aren’t really quite right — almost to the point where the word itself begins to lose its meaning and becomes a “cargo cult” phrase without any real “there” there. In this post, I want to explore what I think are five common myths about iteration that if busted will let us renew the meaning of the word and make it something worthwhile in our profession.
I’ve touched on User Stories on several occasions, my favorite being Why Your User Stories Suck! Today I’m here to share with you a very common, yet very commonly overlooked, way to check each and every User Story on your backlog to see whether or not it’s really “ready” for your Dev teams. One of the most frequent causes of delays and slowdowns in most Agile implementations that I’ve seen comes from a lack of balance in the User Stories that the team is being given to deliver — stories that are too big, or which are dictates, or which just exist on the backlog because “someone asked for it”. What we need to do as Product Managers is to occasionally take a close look at each of our backlog items and make sure that they meet the INVEST criteria — Independent, Negotiable, Valuable, Estimable, Small, and Testable. If we do this simple gut-check on a regular basis, we’re far more likely to see our teams succeed and to reduce the amount of time wasted in long, drawn-out planning sessions.
A common question posed to Product Managers in organizations interested in or transitioning into Agile is, “How do we know that we’re Agile?” Because agility is a cultural value, there’s no pre-determined checklist of things that one can step through and certify your company as 100% Organic Agile. There are, however, indicators that we look at to determine whether or not the company, a team, or even an individual, is thinking and acting in an Agile way. Here are a few key indicators that you can use to weigh your assessment of how agile you, your team, or your company are…
There seems to be a lot of discussion these days about whether or not Agile still works, and whether or not Scrum in particular is “dead” or at the very least dying. The common thread that I see in these discussions is usually something to the effect of “why do we need set iterations” or “user stories suck as requirements documents” or comments in a similar vein about some fundamental part of the Scrum methodology. But, what many of these people forget — on both sides of the coin — is that if we are to truly embrace Scrum as an Agile methodology, it requires us to focus on one measure of success — actual, demonstrable results.
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.
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.