The Agile Boom

Oops. This is one of the articles I had on my “To Write” list. I mentioned this article in a comment and then came here to write it. After four introductory pages of “The history of software development” that were boring even me, I decided to cycle back to that part later.

So, let me bottom line it.

There is a tremendous amount of excitement out there about Agile software development and the various #framemethods that have been associated with it.

And rightfully so! It’s a great idea and I think it has much potential.

But lately, I have been hearing about or reading about many companies who have concluded that they need to or have to adopt the Agile philosophy throughout their entire company.

This is a big mistake and represents one of the most common misunderstandings about Agile.

Agile is about software development. It has absolutely nothing to do with anything other than software development.

What companies do need to understand is that virtually everyone in the company is part of the software development process. It’s not just the IT department, those geeky folks to whom you send instructions. Everyone is part of the process and how well each person performs his or her role in that process has a direct impact on ETA reliability, cost, and end-user satisfaction.

Is anyone actually using Agile or Scrum?

There is such a tremendous amount of misunderstanding and misinformation floating around out there about the Agile philosophy and the Scrum framework that I sometimes wonder if anybody is actually using this stuff.

It’s frustrating because these concepts and processes make so much sense to those of us who do understand them. It makes it very difficult to even converse with the masses of people who think they “get it” but don’t. Sometimes I even doubt that the creators of the Agile Manifesto truly understand why it works or why it has caught on so quickly. There really is no great mystery about that either.

Beyond that, I’ve been reading lots of job descriptions recently advertising for an Agile Coach or Scrum Master. I also participate in a number of Agile and Scrum discussion groups. I am shocked by the obvious lack of understanding by the people who create these things or make these comments.

So, let me see if I can bring some clarity to this.

Agile is a hypothesis. Scrum is a theory.

If you are not familiar with the Scientific Method, the basics are:

  • You notice something happening and wonder why.
  • You come up with an idea about why you think this thing is happening. This is called a hypothesis.
  • You then design a test, an empirical, fact-based test to prove or disprove your hypothesis in a controlled environment. As in: if my idea is correct and I perform these specific steps then I should see these specific results.
  • You then look at the results and come up with other ideas and tests.

For Agile, seventeen successful software developers noticed that they were successful and wondered why. They decided to get together to see if they could figure out why they were all successful. They wanted to see if there was any commonality.

Together, they came up with the four Values and twelve Principles that compose the Agile Manifesto.

But this is just a hypothesis. They do not provide any empirically testable proof that these conclusions are true. It’s all anecdotal.

For Scrum, Ken Schwaber and Jeff Sutherland were successful software developers who noticed that they were successful and wondered why.

They came up with a hypothesis, based on their experience and observations. They designed ways to test their hypothesis in a controlled environment. They then tested it and proved that it worked. They revised and updated their hypothesis, retested it and re-proved it. They continued this cycle until they could prove that they had a working model.

The problem is that they could not definitively prove that this model would work in other environments so, they called it a Framework.

In this case, framework means, a theory for software development that may or may not work in other situations.

I’m not trying to take anything away from the creators of Agile or Scrum. I know that they are all brilliant and successful developers. I’m just suggesting that they don’t truly or fully understand why they have become successful software developers because, if they did, they could prove it with empirically testable, fact-based steps that others could confirm independently. So far I have not seen any such evidence.

This mirrors my long-held opinion that the worst people to ask about success are successful people. I think this is because they were so busy being successful that they didn’t have time to think about why. So, when you ask a successful person to reflect on their own success, they are giving opinions or impressions, not facts. We all know how memories have a way of morphing away from the truth.

So the final question is; do I have any way to substantiate these comments about Agile and Scrum?

And the answer is Yes, because, I have created the missing formula.

I have taken the output from those who created Agile, Scrum, and the other #framemethods and developed my own hypothesis for why they have been successful. I also included my observations from my own 30 years in software development.

I then created empirically testable, specific processes that will work in any situation. These work every time and in every environment. Unfortunately, like Albert Einstein, I didn’t pay much attention in math class so, I have not quite been able to reduce these to an equation but, the processes themselves are solid and I can prove it.

This is why I am so comfortable in saying that most of the stuff I read about Agile and Scrum is incorrect, sometimes grossly incorrect.

And that is frustrating.

Is Scrum a Framework or a Methodology?

I am so sick of this conversation. I CAN’T TAKE IT ANYMORE.

I write a lot about Scrum and, God forbid I should accidently call it a method or methodology. Invariably, some bonehead will comment “It’s not a methodology, it’s a framework” and then go off on a tirade designed to show just how smart they are. And then all the other boneheads go off-topic chasing bonehead #1.

I know because I used to be that bonehead. (I apologize)

I get it. It’s a framework. It’s a framework. Yes, dear God in heaven, it’s a framework. But most of the times when I’m writing about Scrum, I’m discussing a specific step or rule that is part of the method that partially defines the framework. Other times I want to mention all the methodologies that are associated with Agile but again, I have to differentiate Scrum as being a framework.

So, I have created a new word and hashtag; #FrameMethod and a hyperlink to this post at http://bit.ly/2oBGBtX to explain what it means and how it can be used. Which can also be added as a link FrameMethod

I intend to use it instead of the words method, methodology or framework whenever I am writing about Scrum, as in:

“Scrum is a framemethod…”
“Scrum is a #framemethod…”
“Extreme Programming, Kanban and Scrum are just some of the #FrameMethods that are often connected to the Agile philosophy”

This completely eliminates the bonehead factor. (I did apologize for my past boneheadedness, right?)

As mentioned above, it could also be used to describe the methods that are part of the Scrum framework, as in:

“Scrum is a software development framework that comprises a number of principles and #framemethods”

#tapft

The Scrum Formula

After many years of effort, I have been able to create a formula-based method for implementing the Scrum framework.

Scrum may not be a methodology but, my implementation method certainly is.

It’s a wrapper method. It contains specific steps for implementing Scrum in any environment. It’s testable, verifiable and reproducible. It works every time.

The formula not only describes how to implement Scrum, it is designed to be used on an ongoing basis to provide feedback for improvement and to ensure that the Scrum organization is staying on track.

Lastly, this formula also describes how to implement and do Scrum in a way that is 100% consistent with the 4 values and 12 principles of Agile.

No, I don’t think Scrum is an Agile method

Now, before you get out the stake and firewood to set this heroic ablaze, please hear me out.

Think about Scrum by itself, as if you had never heard of Agile. Scrum is a software development methodology (or framework). Scrum can be implemented strictly, adhering rigidly to the steps and protocols provided by the creators of Scrum. Scrum can be implemented flexibly, where the steps and protocols are viewed as guidelines.

View it as a spectrum with rigid rules on one end and flexible guidelines on the other. It is up to the organization implementing Scrum to determine where along this spectrum they feel they get the best results.

The message of Agile is that any software development methodology will yield better results if that methodology is executed with a specific mindset. This specific mindset is encapsulated within the 4 values and 12 principles of the Agile manifesto. It is also expressed as doing things agilely.

Scrum works best if it is done agilely.
Kanban works best if it is done agilely.
Waterfall works best if it is done agilely but, I would venture to say that no one would call Waterfall an Agile methodology.

Agile is an overlay for all software development processes. That doesn’t mean that the processes themselves are or are not inherently Agile.

CRAFTING USER STORIES

Suzy: Daddy, tell me a story.

Dad: Certainly sweetheart.

As a: Business person
I want: You to go to sleep
So that: I can go back to reading sales reports.

Suzy (Angrily): MOM, HE’S DOING IT AGAIN!

Have you ever noticed that articles about creating user stories never talk about the fact that it is called a story because it is supposed to tell a story? People know how to tell stories so why not let them?

Personally, I have found the “As a:, I want:, So that:” format to be restrictive. I have also found that it tends to stifles real communication (an Agile no-no).

If you think about it, software development is all about storytelling, with three basic types of stories:

What & When
How & When
Why

The customer or end-user tells us What they want and by When they need to have it.

We, the technical folks; usually business analysts, architects and product owners, work with the requester to clarify the story of What and When.

We then start writing, first at a very general level, the story of How the request might be fulfilled and When this might happen.

The story of Why is a very important story that often gets overlooked. It should be more than just “so that I can do X, Y, Z”. In fact, the story of Why is the thing that allows us to be agile. It identifies what is really important to the user and thereby tells us where we can be adaptive if we need to be.

For instance; if the Why is to reduce cost, then perhaps the user interface design is less important. If the Why is to increase sales, then fully developed functionality may not be as important (a.k.a., Lean Development).

The story processing itself is that we continue to refine, clarify and breakdown the stories of What and How and When to the point where we have everything we need in order to go into production.
Think of it like writing a book, a novel. We start with the basic concept. We then do an outline followed by fleshing out the parts and sequence of the story.

Jumping now to the bottom of this particular metaphor; think of sentences as the thing the programmers create. At the beginning of the Sprint, no one knows what those sentences are going to be. Everyone does know what story the chapter needs to tell (the Sprint goal).

In the Sprint, the programmer writes the sentences which make up the paragraphs. Each paragraph tells its own little story which can be confirmed by the testers. The paragraphs are then combined in the proper sequence to create the chapter which is itself a self-contained story (a potentially shippable iteration).

Lastly, we put together the chapters to create the book that tells the story of our product and over time, the collection of books comes together to tell the story of Our Product Library.

The Heart of Agile

I’ve been talking with lots of folks recently about Agile transformations.

The first thing I explain to them is that they are not just transforming from Waterfall to Agile. They are transforming from an empirical process to a non-empirical process.

Empirical processes have specific steps that are testable, verifiable and can be measured and tracked. Non-empirical processes, such as the processes for building loyalty, trust, and respect do not have specific steps. These processes are general, vague and are not testable or trackable.

Agile is a non-empirical process (or more technically, a theory about a non-empirical process).

But wait. What about backlogs, burn-downs, story points, definitions of done, etc.? These are all part of measuring and tracking (aka, Metrics).

Yes, these things are all part of an empirical process but, these things are part of Scrum. They are not part of Agile.

So why is Scrum considered to be “An Agile Methodology”?

Scrum is actually a mix of empirical and non-empirical processes. The Sprint part of Scrum is the only part that qualifies as a (potentially) empirical process. The rest of Scrum are non-empirical processes, including the admonition to do thing agilely.