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…”

Are you really Agile to begin with?

I’ve touched on this topic in a couple previous posts — Agile is not just something that organizations just “do”, it’s something that they are…or that they aren’t.  Being “agile” with a lower-case “a” or being Agile with an upper-case “A” are different levels of devotion to a very fundamental concept — we don’t know what the market will want in a year, so we’ll do the things that we know are important now and adjust our priorities as we learn more about our market needs.  That’s a pretty basic concept, but it has some serious implications not only for product development teams and Product Managers, but really at all levels of the organization.  Additionally, being “Agile” with a capital “A” implies that we have accepted and internalized at least the core principles of the Agile Manifesto:

• Valuing Individuals and Interactions over Processes and Tools
• Valuing Working Software over Comprehensive Documentation
• Valuing Customer Collaboration over Contract Negotiation
• Valuing Responding to Change over Following a Plan

What does this mean?

• If your company claims to be “Agile” but still requires specifications that are detailed “checklists” for the developers to execute against, they’re not “Agile.”
• If your company claims to be “Agile” but places heavy micromanagement reporting requirements on top of their development teams, they’re not “Agile.”
• If your company claims to be “Agile” but the developers never actually show stakeholders or customers what’s done at the end of a sprint, they’re not “Agile.”
• If your company claims to be “Agile” but has a detailed, specific 24-month roadmap that commits to features both internally and externally, they’re not “Agile.”

When used merely as an industry buzzword, “Agile” is utterly useless — just as any other trendy label that people want to apply to their organization.  When used only by development teams in an attempt to get “more product” out the door “faster” but without buy-in from the rest of the organization, “Agile” is utterly useless.

There are a great many ways in which we can set ourselves up to fail when we’re looking at a transition to “agile” or “Agile” practices — and saying that we are something which we’re really not is absolutely the most sure way that such a change will fail.  Every. Single. Time.

Do you really know what you’re doing?  Why you’re doing it?

So very many teams start out implementing Agile practices — especially Scrum — without actually training up or doing their due diligence in understanding not only what the methodologies expect you to do, but why you do them.  This inevitably leads to people either doing things the wrong way for the right reasons, or the right way for the wrong reasons — and both are utterly deadly to any successful implementation of Agile practices.

Just because Scrum and Agile were originally thought up by teams of developers doesn’t mean that the concepts and principles and practices are necessarily intuitive for developers to simply jump into and adopt without some detailed understanding of the “what” and “why”.  Developers don’t just start using NoSQL databases in their projects without some research, training, and understanding — so why do they think they can do the same with project management methodologies?

And yes — Scrum in particular is a project management methodology.  It sets up practices and principles which allow teams to know what they’re working on, where they’re at in the progress on that work, and to deliver something on-time and within a budget.  Project management is not always the biggest core competency of a development team — solving problems is usually their core competency, and more often than not, project management comes in second place (or third, or fourth).

The single biggest failure that I’ve seen in Scrum teams is simply a lack of real understanding about why Scrum says to do things the way that they do.  And that this is a baseline set of practices that one should try out first, and then adjust as needed to fit the needs of the team and of the organization as a whole.  Any team that is considering shifting to or implementing any set of Agile practices needs to be trained by a professional before they start mucking around.  And they need to start out implementing the whole package, not just bits and pieces that they like or feel comfortable with.  Half-assing an Agile methodology is no better than half-assing a database architecture — if you don’t think it through from the beginning, you’ll get bit by some fault or failure shortly down the line.

All of the “ceremonies” involved in Scrum have a purpose, and understanding the “why” helps us to understand the “what”:

• Backlog grooming creates the prioritized backlog off of which work will be pulled, so that both the team and the stakeholders know what’s likely to be worked on, and in what order.
• Sprint planning creates a commitment, so that both the team and the stakeholders know what is being worked on for the next interval.
• Daily standups create an accountability within the teams to demonstrate that you’re making progress and a structured time for check-in and notice of blocking issues and questions.
• Sprint reviews allow developers an opportunity to hear directly from the stakeholders how their work is or isn’t meeting the needs intended through the user stories.
• Sprint retrospectives reinforce internal accountability within the teams, and allow them to identify things to change and try in order to continually improve their efforts.

We don’t just do these things to do them; we don’t hold meetings just to hold meetings; we look at these things through the lens of lean manufacturing — what’s the least amount of overhead that we need to impose in order to maintain visibility and accountability in the system and achieve the most with the limited resources that we have.

Development doesn’t exist in a vacuum; development teams and their results create the product that everything else in the organization depends upon.  Stakeholders, managers, and executives have to have trust in the things the development team is doing and their reasons for doing so.  Scrum attempts to put a minimal amount of managerial overhead in place to ensure that the teams remain self-organized and focused.  When these practices are abused or twisted into micro-management controls, Scrum is destined to fail.

These are two of the most common ways in which Agile and Scrum teams wind up shooting themselves in the foot before they even start working within the frameworks — making the switch or implementing Agile principles just isn’t as easy as turning to your CEO one day and saying, “We’re Agile now!” — it takes preparation, perseverance, and understanding across the board.