fbpx  

Agile Failures

, ,

Non-Agile Scrum

You may have adopted Scrum, and you may be following its rules quite exceptionally. Daily Scrums(stand-ups) take no longer than 15 minutes. At the end of Sprint Planning, you may have a solid plan for the upcoming Sprint including tasks, test cases…the whole 9 yards. You have a demo at the end of the Sprint and even a retrospective. Hurray! You’re agile!

Or are you?

Why do I keep hearing people say things like “I will never do agile again!”, or “I was on an agile team, it was horrible!”?

Hearing comments like these are very common. What’s happening here?

I think there are two things happening.

Scrum as a Silver Bullet

Companies typically implement Scrum because they are having significant problems with delivery, quality, or budget which makes for very unhappy customers and loss of revenue.

Why Scrum? Probably because they hear all the success stories from their peers…and it is the most popular agile framework after all.

The fallacy is that Scrum will “solve” your delivery, quality, and budget problems. That is not true…it will shed light on “why” there are delivery, quality and budget problems. It could be inadequate skills, too many hand-offs, too much bureaucracy, etc. These types of things would be the impediments that Scrum-ists talk so much about that need to be removed.

If you implement Scrum but do not remove the impediments it exposes, you aren’t really “doing” Scrum.

Non-Agile Scrum

Scrum is an agile framework, but all agile is not Scrum. It’s the same thing as saying that macaroni is a noodle, but not all noodles are macaroni. There are lots of agile frameworks, and Scrum is one of them.

Almost 100% of the time, when I talk to leaders and they say “we’re doing agile”, what they really mean is “we’re doing Scrum”.

The reason I think that this is important is that if you don’t make that distinction, you may miss out on what’s really important, the principles and values of agile.

Agile says nothing of 2-week Sprints, Sprint Planning, a Product Owner, a Scrum Master, etc. Nothing. However, the theory is that you follow Scrum, you are getting a great start on being agile.

Many teams will implement Scrum by implementing the roles, events, and artifacts. However, if they don’t understand agile, they may miss the point and end up no better than when they started.

When Scrum is implemented without an understanding of agile, and with the idea that Scrum in and of itself will solve every problem, you end up with non-agile Scrum. You may follow all the “rules”, but if you follow them in a prescriptive way, you are missing the point.

Agile Scrum

In my view, to have a truly agile implementation of Scrum (or any agile method), you need the following:

Self-organizing, cross-functional, empowered teams

This is indeed the most difficult goal to achieve. However, I believe this is the cornerstone of any agile transition. Leadership must change from a command-and-control perspective to one of support and empowerment of the teams. Since the teams are the ones who know best how to deliver, they should be allowed to do just that.

This does not mean that the team adopts the “wild west” style with no constraints. On the contrary, leadership provides those boundaries, and then the team will do anything necessary within those boundaries to deliver the best product possible. An example of some boundaries that I’ve seen are acceptable:

  • Use TFS for code management.
  • The team cannot spend more than $300 on software without approval.
  • The screens must be constructed adhering to our company’s style guide.
  • Don’t introduce new open source libraries, tools, systems, etc. without checking first if we already have something similar available. If you need to include a new open source item, make sure to add it to the corporate development wiki so others can learn about it.
  • Since we work with PII, no production data will be allowed in development environments. If it’s absolutely necessary to work with PII, the data must be de-identified.
  • All code must work on Edge, IE 11, the latest version of Chrome, Safari, and Firefox.
  • Make sure your code is tested using some kind of automated framework.

I think these boundaries are very reasonable. The team still has quite a bit of latitude to be creative. These boundaries not only have impact on the team itself, but also all the other teams.

On the Non-Agile Scrum Teams, I’ve seen boundaries such as these:

  • Every team will have a physical board with the columns “To-Do”, “In Progress”, “Done”.
  • Every team will write every requirement in the user story format “As a __ I want to __ so that __”.
  • Every team will perform code reviews Friday afternoon at 2 PM.
  • Each developer will create a design document before they code. They must review this document with the architect before coding begins.
  • Each team will schedule their planning session for no less than 8 hours.
  • Each team must post their retrospective notes on the Sharepoint site.

Hopefully it’s obvious that these kinds of “rules” take the wind out the team’s sails and kills any hope of creativity. These rules are somewhat arbitrary and ultimately if your team has rules such as these and are doing Scrum, you’re not doing it right. Understandably this is not a problem with the team. It’s a problem with leadership not understanding the concepts of self-organizing teams and empowerment

Dependencies

If you find that your team is not able to deliver any working software at the end of a Sprint without waiting on another team to perform a task, you most likely need to rethink how the team is formed.  Dependencies and hand-offs kill team productivity, predictability, and morale.  Here’s a great read on options to structuring teams – Feature Teams

Prioritized Product Backlog

This one appears to be pretty straight forward.  However, it surprisingly is not very common.  The Product Backlog is what anchors the team.  This describes the software that the team must deliver.  If there is not a clear Product Backlog, the team has idea what to deliver, and chaos ensues.

Below are the attributes of a well formed Product Backlog

Valuable

The Product Backlog contains items that are valuable to the customer.  This does not include technical tasks.  Technical tasks are included in the Sprint Backlog (a topic for another post).  There is a tendency to include technical tasks in the Product Backlog.  When this happens there is no clear understanding or traceability as to what is actually important to the customer.

Transparent

The Product Backlog must be available for anyone and everyone to see.  There should never be any surprises.  During the Sprint Planning session, the team should have already have pretty good idea of what’s coming up.

Consistently and Frequently Maintained

The Product Owner and the team must consistently maintain and refine the Product Backlog (it’s mentioned in the Scrum Guide as “Product Backlog Refinement).  It must be ensured that the team knows exactly what the next most important item is to work on.  Refinement includes adding additional detail when necessary, adding/refining estimates, and ordering.

Exists at All Levels

There should be some definition of “valuable deliverables” starting from the corporate vision.  Now, at the higher levels in the organization, it isn’t called a “Product Backlog”, but it really serves the same purpose.  You may have a Product Roadmap, Product (or Project) Portfolio, etc.  You get the idea.  What the team works from is the “Product Backlog”.  There typically is “line of sight” from every item in the Product Backlog all the way through the Portfolio or Product Roadmap.  

“What” exists at all levels is dependent on the size and complexity of your company.  Some companies may only have a set of Product Backlogs at the team level. Other companies may have a complex set of roadmaps and portfolios.  The point is that they should exist where appropriate and there should be traceability all the way to the Product Backlog item.

One Product Backlog Per Team

Quite frequently I see multiple Product Backlogs per team.  They may have a “product” Product Backlog, a “bug” Product Backlog, a “small requests” Product Backlog, etc.  That causes confusion for the team.  How does the team know what is next if there are multiple Product Backlogs?  They don’t.  

Summary

If you’ve been doing Scrum for a while and aren’t seeing the benefits, take a look at your teams and your Product Backlog.  Are the teams self-organizing, cross functional and empowered?  Can they deliver working software to the customer without depending on other teams?  Is there a Product Backlog?  Is it actively maintained?  Is there only one Product Backlog?  If you answered no to any of those questions, then there’s work to do!

This stuff is easy conceptually but hard to implement.  If you’d like help making your Scrum more agile, please feel free to contact us here.  

 

Beware of Snake Oil: The Agile Tool Salesperson

There are some great Agile tools on the market to manage backlogs, track metrics, create visibility, and measure capacity & velocity.  These tools range anywhere from free to several thousands of dollars.  We have nothing against these tools, as a matter of fact One80 even partners with several of these tool vendors.

That said, we have seen an alarming trend in the project management world of using expensive Agile tools to drive process.  This trend doesn’t apply to just companies using Agile but it seems to be accelerating, and it goes directly against the Agile Manifesto.

People and Interactions of Processes and Tools

This new trend follows into two categories:

1Molding Agile, Scrum, or Kanban (you pick the mythology) to fit a software tool.

We see many companies pick a tool and then force Agile to adapt to the tool.  Now to be clear, I am not against software tools.  There are some great tools on the market that can help manage backlogs, track metrics, create visibility, and  measure capacity & velocity.  Each tool approaches Agile in a slightly different manner.  The DANGER comes when a company chooses the tool first allowing the tool to drive the Agile implementation.

We recommend that when starting an Agile journey, always start low-tech: Post-it notes, whiteboards, flip-chart, or excel.  There is no need to get fancy.  Allow your team to focus on what is important – The Agile Manifesto and continuous improvement.  Over time the team(s) will create an Agile approach that works for them.  The Enterprise will begin to learn how to scale agile and develop effective Metrics that actually drive value.  Once a stable Agile solution is established, then and only then, can a company begin its evaluation of tools.  This is exactly the process the One80 follows in our Agile Kickstart program.

2Using expensive Agile tools or frameworks to solve team dynamic problems.

Every implementation of Agile and every team has their own unique challenges. These challenges range from Team Dynamics, Communication, Cross-team Coordination, Scaling, Vendor Management, Change Management (the list can go on and on).

We have found more times than not the solution to almost all of these situations is staring you in the face. Just ask the team, listen to them, trust them, and they will solve 90% of the problems. Yes, they may need a good facilitator to guide them, but let the team self-organize, let the team build some information radiators , let the team us their retrospective skills.  After all, isn’t that what agile is all about?  Inspect and Adapt.

 

Talk to Us Today

Agile Failures: Just in Case

A huge form of waste (leading to Agile failures) many people don’t talk about are those features we build “just in case” we might need them some day.

I think that those involved with building a product often forget that everything we build costs something. Nothing is free. Who’s paying for it? The customer.

Everything we do must deliver some kind of business value, either by reducing risk, meeting compliance, cutting costs, increasing revenue, etc.

blog image 2There are certain phrases that I listen for such as, “it would be cool if…”, “someday we might want to…”, “what if a client requests …” etc. Some Product Owners want to build to accommodate edge cases that are often so ridiculous that they would never happen.

What gets really tricky is when there is only one SME in the product group, and no one else really knows that domain. In those cases, that SME acts as the Product Owner and has the power to create work that may actually be of little value and may lead to the snowplow trap.

The only way to get around this is to fearlessly and relentlessly ask “why?”. In these situations, there is typically a touch of fear that compels the team to simply accept directives rather than asking probing questions.

Agile Failure funnel effectA good way to think of this is to envision a funnel.  Only so many widgets can fit into the funnel at a time. If you need for a specific item to go through the funnel, something else is not going to get to pass.  This is very much like building a Product.

Only so many pieces of functionality can be built.  Eventually the project ends or funding is eliminated and you are left with features that did not get built, while ‘never to be used’ functionality was completed.  Some of the functionality that was not built may have had business value and\or high ROI. This is waste and is often perceived as an Agile Failure when in-fact it is a Product Owner prioritization issue..

There are some ScrumMasters (and Project Managers) that typically stay out of those kinds of details. Yes, the team is self-organizing. Yes, the team has to learn by making mistakes. However, the ScrumMaster has to be involved enough to not allow the “just in case” methodology take hold. If it’s allowed to happen, you will find that what you have delivered in the end is not of the highest value.

Talk to Us Today
post =