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.
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.
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
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
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.
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.
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.