Scrum Does Not Equal Agile

We hear the cries almost daily.

“We need a Scrum master in here right away. That will fix all of our Agile problems.”

“I’m trying to run these sprints, and no one will stick to the time limits! What is wrong with this team?! They just can’t do Agile right!”

“We purchased this Agile software and it’s still not improving our efficiency, so I don’t think Agile is the right fit for us.”

Does any of this sound familiar to you?

I know it does to me and when I was first getting started, I had no clue about this Agile nonsense. I said, “No thanks.” Give me the traditional, predictive, waterfall methodology we all know and love. It’s as comfortable as my favorite pair of jeans.

Once I dug in, I was surprised to realize that the Agile methodology has been around for twenty years much in the same way that 1990 is still ten years ago. Besides almost being of drinking age, Agile is surrounded by quite a few misconceptions that especially regard what it is, means, and does.

Agile is a METHODOLOGY.

It’s not a widget, software, hardware, type of meeting, poster, or clothing style. The Agile manifesto was drafted because software developers needed a better way of managing their projects. The manifesto has four basic values:

• people over product,
• viable software over excessive paperwork,
• collaboration over negotiation, and
• change over plans.

These values tied into the twelve clarifying principles of the manifesto.

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
• Frequently deliver working software from a couple of weeks to a couple of months, with a preference to the shorter timescale.
• Business people and developers must work together daily throughout the project.
• Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
• Working software is the primary measure of progress.
• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
• Continuous attention to technical excellence and good design enhances agility.
• Simplicity – the art of maximizing the amount of work not done – is essential.
• The best architectures, requirements, and designs emerge from self-organizing teams.
• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

If Lean Six Sigma had two babies, they could possibly be the Kanban methodology and Agile methodology, although there can be some overlap of Kanban into Agile. By that I mean there can be Kanban practices within the Agile methodology.

Scrum is a PRACTICE.

Scrum is not a methodology. What becomes confusing is when Crystal, XP, DSDM, AUP, FDD, and ScrumBan all start to get used interchangeably with Agile. NO! This happens because of poor implementation and lack of training at the onset. Processes, workflows, and simple transactions get tangled. Then, when you start building on those mistakes and cement in poor habits – disengagement sets in.

What can you do?

• Be sure that you are properly educating your employees from the start and use the correct methodology for your company needs.
• Train everyone then review the training to ensure that it has not been wasted.
• Post visuals and engage every learner.
• Make sure you are properly assessing the appropriate level of uncertainty, risk, and lifecycle for your company.

Today, and especially now, everyone is under pressure to deliver faster, smarter, and more Agile. Are your methods and practices working for you? We can help you discover the right solutions for your business.