Bad implementations often ruin good ideas.

Take Scrum, for instance. It’s surprising to me how many organizations say “We’ve tried Scrum; it just didn’t work for us.” I am tempted to reply “You did it wrong!” but instead, I usually ask a bunch of questions that are strong indicators of trouble:

  • Are your customers involved frequently during the development process?
  • Do you have strong product owners with a clear vision of what success means?
  • Do your sprint lengths change in response to changing uncertainty? (more uncertainty => shorter iterations => faster feedback)
  • Does the team communicate openly and honestly during stand-ups and retrospectives?
  • Does the team adapt based on feedback received during showcases and retrospectives? (this applies to everything: coding practices, team ceremonies, metrics used, working conditions… everything that pertains to team success is fair game)
  • Does everyone on the team buy into the vision of success, and the metrics used to measure progress?
  • Are QA, BA, UX and PM treated by the Dev team as first-class citizens on the team?

You might be agile if you can answer Yes to the above. If not, there are many legitimate reasons why it failed for you, that have nothing to do with Scrum itself.

Let’s go back and examine Ken Schwaber’s original description of Scrum:

Scrum is a feedback-driven empirical approach which is, like all empirical process control, underpinned by the three pillars of transparency, inspection, and adaptation.

Transparency. Inspection. Adaptation. Pause here for a second to really evaluate if your team has these.

While we’re at it, let’s also revisit the values of Scrum:

  1. Commitment: Team members individually commit to achieving their team goals, each and every Sprint.
  2. Courage: Team members know they have the courage to work through conflict and challenges together so that they can do the right thing.
  3. Focus: Team members focus exclusively on their team goals and the Sprint Backlog; there should be no work done other than through their backlog.
  4. Openness: Team members and their stakeholders agree to be transparent about their work and any challenges they face.
  5. Respect: Team members respect each other to be technically capable and to work with good intent.

If you don’t have these, you aren’t doing Scrum and you are not Agile.

It’s valid to ask “whose responsibility is it to make all these things happen?” Short answer: leadership. If any of these are missing on your team, you have a leadership problem.