It seems that lately Agile (and Scrum in particular) have become the latest targets of non-stop complaints and criticism in the Product Management and Development worlds. I’ve read articles that talk about how “Agile is destroying the business” or where “Scrum is a career-limiting methodology that only creates generalists.” Neither of these are necessary conclusions from the data provided, nor are they necessarily a reflection of weaknesses of the Agile principles or of a specific methodology — more often than not, they’re a reflection of a certain culture or work environment that itself is fighting against the fundamental tenets of Agile and Scrum.

If you’re one of those people for whom either Agile or Scrum doesn’t seem to be working, here are some hard questions to ask yourself and your organization — “The fault…is not in our stars. It is ourselves…”

Since the Clever PM is recovering from a nasty bug, he’s going to rely on Quora for a little Clever content again, this time focusing on the question “How do you get developers to commit to finishing a sprint on time?” I chose this one because it plays into one of the common misconceptions about Scrum and Agile approaches — that it’s the responsibility of the Product Manager to ensure commitment from the Development teams; this is certainly how it works in the Waterfall world — the Product Manager negotiates a “contract” with the Development team for what they’ll do, how it will be done, and how long it can take. But in the Agile world, particularly in Scrum, it’s the team that makes the commitment to deliver, based on what they believe they can achieve in their next iteration. It’s the Product Owner/Manager’s job to ensure that the team has a well-groomed, prioritized backlog to choose that work from. [Read more…]

In the first part of this series, I talked about how many teams who try to transform into “Agile” teams fail because they don’t actually understand what being “agile” is all about, or because they try to cut corners by not fully embracing (at the outset, at least) the fundamental requirements of the methodology that they have selected. Today, I’m going to focus on three additional complications that teams often run into when they run headlong down the path of “Agile” without actually embracing the precepts of “agility” that provide the highest likelihood of success.

The first is the importance of continuous improvement practices — how ignoring the process review ceremonies hurts everyone involved. The second is how a lack of clear goals and expectations will lead to inevitable disappointment and disillusionment — both from the team as well as stakeholders. And the final point is how even though there are specific practices and ceremonies that are recommended by Scrum, the entire point of being “agile” (not “Agile”) is to assess what you’re doing, how you’re doing it, and what you’re achieving, and make changes to get better — even if that means doing things that “aren’t” Scrum. [Read more…]

I started this out as a single post, but it’s become far too unwieldy for a single day. Thus, I’m breaking this up into two segments — one focusing on missing the point, the other on finer mistakes that sink potentially “good” teams moving into Agile processes. It’s still one of my longest posts here, but I hope you find it worth the read.

“Agile” and “Scrum” have seemed to take a beating over the past few months, with a lot of criticisms and complaints online and off with regard to how it’s not the “silver bullet” everyone expects it to be and how it actually fosters a lot of dysfunction and bad behaviors in developers, Product Managers, and management. The problem with a lot of these criticisms, at least the ones that I’ve read, is that they take one or two bad experiences with agile methodologies and apply them as a blanket criticism of all agile methodologies — and almost universally one can look to the details of these complaints and see that it’s far more likely that the bad experiences are caused not by a bad philosophy or a bad methodology, but by bad implementation of those principles and processes.

I’ve worked with several companies to effective transform from backwater processes to effective, efficient, and successful product delivery teams through the use of agile philosophies and a variety of agile methodologies. The problem is, nearly every team has some level of dysfunction already (and likely always will), and if you go in blind to those dysfunctions, or with a belief that all you need to do is “be Agile”, then you’re destined to fail — but I would posit that it doesn’t matter what process you choose, if you ignore your dysfunctions they will always come back an bite you in the end.

To that end, I wanted to take some time today to discuss some dysfunctions that I’ve seen in teams claiming to transform into Agile/Scrum teams, all of which are not only contrary to the principles on which the methodology is founded, but each of which can sink any attempt to be more agile into an unending quagmire of crap.

We’ve all been there — we’re talking about our upcoming projects, discussing possible timelines and resource allocations, working to align our tactical work with the company and product strategy, when it hits you like a brick thrown through your living room window in the middle of the latest Game of Thrones episode:

So, where’s the project plan?

And that’s where it goes downhill. Because we all know that what’s usually meant by “project plan” is some extremely detailed, well-defined, cascading graphic from hell known as the Gantt chart. It’s been the go-to standard for project management and project planning for decades.

And it needs to die. A miserable, screaming, Melisandre-putting-it-on-the-fire-for-the Lord-of-Light death.

With Agile development and Lean practices so popular nowadays, sometimes the history behind these practices and philosophies is overlooked or skipped over entirely. Unfortunately, when people miss the underpinnings upon which these concepts are based, they also tend to distort and remake those principles into something that only barely resembles the original concepts behind them.

Most of what we consider to be modern “Agile” and “Lean” approaches to product design, development, and implementation all stem from a variety of manufacturing principles that coalesced into the Toyota Production System in the late 1940s. This process was a vast departure from the Western approach to production lines — the interchangeable parts an always-moving production line, in which people were just another cog in the wheel. Rather, the TPS system focused on several principles designed to implement systemic processes to allow people to provide feedback into the work being done and how it might be improved. The development of these principles, and their application in the “Toyota” way slowly built between the 40s into the 70s, where it became more broadly adopted under the guise of “just-in-time manufacturing.”

Many books have been written on the TPS process (with all apologies to Office Space fans), and I would encourage people interested in the history to do some research — but for this article I wanted to focus on what the TPS system views as “waste” and how each is specifically defined, because when we talk about Agile and Lean trying to eliminate “waste”, we probably really mean one of these three things:

Muda = “Waste” or failures of people or processes to efficiently deliver product.

Earlier this week, I discussed the common misunderstandings related to the first two statements made in the Agile Manifesto — Individuals and Interactions over Processes and Tools, and Working Software over Comprehensive Documentation. In that discussion, I focused on how important it is to remember that the Agile Manifesto itself was written largely in response to traditional “Waterfall” methods of product design and development. There was never any intent on the part of those who created the Manifesto to shift the focus entirely to the “left side” of the spectrum — but rather to propose a spectrum that was more responsive to change and that could accelerate the delivery of value to interested stakeholders. While these original concepts have brought forth many different specific approaches, the fundamental purpose of the Manifesto remains important in understanding when, where, and how to implement such practices, and why you should do so.