I still want my agile back

A dialogue with a colleague

Inviting Radical Candor (Modern Agile, Psychological Safety Cheat Sheet, Creative Commons)

It’s the end of 2022 and I’m still working with companies to implement anything resembling Agile and XP development processes. Over the years, I’ve worked with some excellent teams, and many times I’ve worked with companies that pay lip service to the ideas, but don’t take any of the actions.

They recite the buzzwords, and catchphrases, but don’t actually do the things.

I’ve best heard it described as Waterfall in Sprints.

Recently I was reminded of some excellent articles on this I read around 2015 and started to have a conversation with myself regarding the matter. Yes, I talk to myself, because sometimes that’s the only way to have an intelligent conversation.

It occurred to me that Dialogues are a time-honoured publishing format and while I’m no Plato…

💂 Jeff —

I’m currently taking the corporate course in “agile” and every lecture leaves me fuming.

I want my agile back

Taking Back Agile

I Want Agile Back

Alice —

I really only know Agile from some theoretical academic classes from my college days. Whenever I’ve been told we are running in “agile” mode, it has only ever meant “busy” and “hectic”

💂 Jeff —

I lived it in the early days of the 2000s, implemented it at my small company, and debated and discussed the literature with some of the greats. It’s funny that you mention “busy” and “hectic” since that’s almost straight from one of the articles I sent you.

Are we tired of seeing “sprints” and “iterations” used as ways to pressure people into working harder and longer

— Tim Ottinger, I want agile back

👩 Alice —

Yes, that’s exactly how it works

💂 Jeff —

Agile was always about slowing development down, not speeding it up. Slowing it down so fewer errors got made, resulting in an overall increase in speed.

👩 Alice —

Exactly. Instead, they will see how many story-points you complete and review it against other co-workers

💂 Jeff —

Story-points were a dumb idea, it becomes a performance metric.

👩 Alice —

Yes.

👩 Alice —

One that creates competition, so people work harder to avoid looking bad.

I felt it because there was a time when I worked for my previous company, I delivered 1 story point but it was 80% of the work of the whole project

💂 Jeff —

When a measure becomes a target, it ceases to be a good measure

— Goodhart’s Law

I mean, I get the point to story-points; not everybody works at the same speed, so the time it takes me to achieve 8 points of effort isn’t the same as it takes you. Unfortunately, because they are so abstract, I think they just end up being a way to dictate how much time it will take you.

Story points for me have always and will continue to be, estimated hours to complete. How long do you think it will take to implement

…. AND… they will be used to ensure that staff are not overburdened with work!

THAT SHALL BE THEIR ONLY PURPOSE!

👩 Alice —

I think so.

💂 Jeff —

NO

not “THINK”

👩 Alice —

haha. Yes

💂 Jeff —

[jumps up on the desk. Fist strikes high into the sky]

IT SHALL BE

👩 Alice —

I mean sometimes people interpret things differently.

💂 Jeff —

I know you are right.

It just makes me sad.

👩 Alice —

hahaha

I mean the way people interpret agile and story points differently.

💂 Jeff —

That article “I want my agile back” … I’ve been reading those works for years. The original point (2002?) was to slow down the expectations so that developers had time to “do it right”.

It was a framework to help set boundaries on expectations.

👩 Alice —

Yes. That’s right

I’m never in a management position so I don’t really know how Agile works and how it helps achieve the project goal and timeline.

💂 Jeff —

(this is why I’m not either)

💂 Jeff —

At one of my previous companies, my manager was pretty cooperative with it… I would tell her how much could get done, she would yell at me to do more, I would yell back that I’d shown her the math …. and we would go with what I had shown her.

(The yelling was mostly a side effect of her having been to a rock concert the night before)

👩 Alice —

But according to one friend of mine, the project she took over was running in a waterfall mode, and was a total failure.

There is another term “waterfall”… I don’t really know what that is supposed to be either.

💂 Jeff —

I don’t think anyone really does. I’ve heard some pretty powerful metaphors and pretty flowery explanations.

Ebor falls (Wikimedia, Creative Commons)

Have you ever heard where the term ping comes from?

When I was a teenager, the term was widely understood to be a reference to submarines sending out sonar pulses and waiting for the response to come back. While in college, my textbooks described the same concept. Then, about a few years later, I came across a reference that stated the term was P.I.N.G (Packet InterNet Groper).

I can only imagine how this came about. I’m assuming some student put their hand up and asked a professor what it stood for… a little dumbfounded the prof jokingly stated “Packet InterNet Groper”, but the joke got taken seriously. (Wikipedia has an interesting history for this)

My point is that people like to invent complicated explanations for obvious naming conventions.

What is “waterfall”?

[Wikimedia, CC-SA]

Note the shape of this Gantt chart. Notice how it cascades down the page, almost like a “waterfall”?

People like to over complicate some explanations.

Before I heard about Agile, this is what Project Management looked like. I filled out hundreds of charts, just like that. When we started talking about Continous Improvement, Iterative Development, and … Agile … we need some way to define the “old” way of project management. We needed a word to describe “not Agile”, so someone looked at the chart and called it “Waterfall”.

As people are apt to do, they have extended the metaphor.

Once the water is over the falls, its hard to go back and change the course of the river. (a good analogy)

I’m concerned about our project, and what I’m hearing in the corporate training. I’m concerned that we are creating “waterfall with sprints”, a common euphemism for the fixed project timeline project management (waterfall), but with 2-week time frames (sprints).

Waterfall with a bit of makeup on it to dress it up.

origin of ‘you can’t make a silk purse out of a sow’s ear’

💂 Jeff —

I taught an intro project management class at a Community College. The previous instructor handed me his curriculum (still grateful for that), but on the first day, I felt the need to explain that those two terms are very loaded. They don’t mean what they originally meant. The terms have been hijacked and used as slurs and changed and …. so we need to lay out what we mean by them, and what we think others might mean by them.

What they mean in the ideal case, and what they probably mean in the workplace.

👩 Alice —

My understanding of those methods is based on my work experience. So if it aligns with the definition or not, I don’t know.

It depends on how the PM runs it.

💂 Jeff —

At least you know what you don’t know.

I will always refer to the “ideal” and the “actual” because who knows what the academic definition is anymore

Ideal: I want to use a system that works well. Not abuses people. Not pits people against one another. The one that increases love in the universe.

👩 Alice —

Based on my experience, when people tell me they are running agile, I automatically assume they need me to get work done fast and they are going to change the requirements frequently and without notice.

💂 Jeff —

I actually originally introduced it as a way to reduce the scopes change rate.

💂 Jeff —

“increases love” is actually part of the original academic definition

👩 Alice —

When I worked for my previous company, they ran an agile and asked me to deliver a report without any requirements.

So I put together a report based on my understanding of the report. The BA took the report and show clients and got feedback from them. They would then come back to ask me for revision.

There were a few back and forths until the report meet the client’s expectations.

That is how I was told what agile is.

💂 Jeff —

Individuals and interactions over processes and tools

— Manifesto for Agile Software Development

👩 Alice —

Do you know how we talked about creating the structure of datasets? That’s what I did for that company. I created the structure of the dataset they were looking for. The clients then inspected the data and started to comment if it was correct or not.

💂 Jeff —

That’s worth doing… back and forth design.

👩 Alice —

I feel that method is good for initial development when the client doesn’t know what they exactly looking for.

💂 Jeff —

Absolutely, but once you pin that down as “designed” it needs to be captured as a signed-off agreement and only tweaked from there.

I wanted the most recent transition you and I are working on to be done that way. I wanted to bridge it by us writing exact duplicates of the original way. If we weren’t matching 1-to-1, something was wrong.

Over time we would have just slowly transformed into the new interface.

👩 Alice —

Yes. So all the terminologies are vague to me.

💂 Jeff —

Good…. I like you better that way

👩 Alice —

Why? It’s more changeable that way?

💂 Jeff —

Basically.

There are only four terms you really need:

• pass or fail: was whatever we did a success or not? This is a boolean, there is nowhere to hide from the truth.
• better or worse: whether it was a success or failure, we need to ask how we could do it better next time. This is a scale, is whatever we tried better than the way we did it before, or worse?

We don’t ask

• is it agile?
• is it waterfall?

We ask “is it better?”

👩 Alice —

Haha, totally

As I said I’ve never been in a management position. For me, it’s just about getting the work done on time.

💂 Jeff —

“on time”

That’s a dangerous phrase. It comes with being told when “it is due”

👩 Alice —

Yes.

Some companies just give you a deadline and squeeze it out of you.

💂 Jeff —

Jeff’s ideal process: “we tell how much we can achieve and explain when it will be done”

My classic story…

• Monday: customer calls me and asks for a new feature ( f1 ). I estimate a week for the work and get started.
• Tuesday: around noon the phone rings. The customer is in a panic. He’s just come out of a meeting and the executives really desperately need a different feature. I put down my planning for f1 and get started on f2
• Wednesday: at noon the phone rings. The customer is in a panic. He’s just come out of a meeting and there has been a catastrophic business failure, heads are going to roll. He immediately needs me to start work on f3
• Thursday: first thing in the morning there’s an email in my mailbox asking me for a status update on f1. When I called and explained that I had tabled that to work on f3 he panicked. f3 was low priority. Instead, he had promised f1, and it was absolutely needed by Monday.

So I pulled out some early notes about f1 and got started wrapping my head around it. By noon, I was back up to speed on it, and ready to get started.

Because the customer changed his mind about what he wanted to be done so frequently, we (both he and I) lost 4 days of a work week.

That’s a true story, most people don’t believe me when I tell it. They will tell me that would never happen, but if I’m telling it to them its because they are experiencing exactly the same thing. I have seen that play out at (almost) every organisation I’ve worked for.

Key phrases I tend to watch out for:

• competing/multiple priorities: you can’t have “multiple” priorities such a thing cannot exist logically, similar to “competing” priorities.
• multi-tasking: Unless you are an octopus, you can’t. You can only rapidly task switch, which comes at a cost.
• immediate position: (in job postings) what lack of planning led to your organisation not scaling up effectively?

If you ever want to have fun, go take a job interview, talk up your predictive analytics skills, and then ask them what they are doing to address their analytic failings that led to the current hiring emergency/disaster.

👩 Alice —

Once upon a time, a friend of mine got fired because he was not able to deliver what the client asked for on time.

Exactly the same issue that you described above

The boss kept getting changing requirements from the client and asked the team to change priorities. In the end, they couldn’t deliver anything

💂 Jeff —

Precisely, this is a common and widespread problem.

At the time, I did some reading on how to solve this problem and came across a new concept called “agile”. I read a book, read some forums, and started to implement some boundaries in the workplace.

My customer wasn’t allowed to talk to me in the middle of a sprint, he had to commit to not changing requirements for at least 4 days (1-week sprints). When I said that, it actually freaked him out, sending him into a rant about him being the customer, and he pays the money … and that demonstrated a problem.

I told him that if he could not commit to a plan for 4 days, he obviously had not really thought it through. In the worst-case scenario, if he had made a mistake, I was asking him to live with it for 4 business days. At the end of 4 business days, he could totally change his mind and reschedule and get me to work on something else… but he had to wait 4 days.

Compare that to “waterfall” where in theory, he would not be allowed to adjust the plan because he had signed off on a plan. This is where the “agility” comes in, you have planned to totally change the plan regularly, whereas the rigidity of “waterfall” resulted in a culture of “emergency” changes to the plan, and constant last-minute demands.

So this customer and I put everything in a backlog, I started work on the first item … and he called me mid-week, with a small little quick extra. I cancelled the sprint to achieve what he wanted. Then sent him a report outlining that everything had moved out a week since we were starting a week later than expected.

He got angry, we had another very difficult conversation, and I pointed out it was simple math. I cannot be in two places at one time. The 6-month project estimate was from the “start” date, not the calendar date. If he was going to interrupt the plan, his project was going to start later. His “quick” change cost him a week, if he had waited 2 days, it would have cost nothing.

I have been accused of being a jerk for this, but I wasn’t, I had found a clear way to reflect reality to him. His quick change lost me a half week of effort and he needed to understand that.

After that, we settled into a groove: one-week sprints that started with a Monday meeting where told him what could get done during the week based on my review of the backlog. He would spend all week re-prioritizing and adding to the backlog for the next week (basically preparing for our meeting).

👩 Alice —

Switching between tasks is such a headache. I got re-tasked with an emergency a couple of times while working on our most recent feature. Every time I got back on it, I need to review and refresh my memory. So changing requirements really wastes lots of time.

💂 Jeff —

Knowing that feature, and the level of interruption you experienced, I would guess it cost half a day each time you had to get back into it.

💂 Jeff —

I used to track my time, and I counted every task switch as a lost 15 minutes.

A director and I got into an argument over it … she ordered me to count it as 30 minutes

👩 Alice —

even better

💂 Jeff —

Ya, but I’d hardcoded the math 🙁

👩 Alice —

Hahaha

💂 Jeff —

By setting the pace weekly, and not allowing change mid-sprint, you implement a cost to changed requirements. They actually take more time.

That means the business is incentivized to cooperate in getting them right the first time.

💂 Jeff —

That was one of my most successful projects ever. It was so successful that Customer A got bought by Customer B to get at the software (6 months later)

💂 Jeff —

I just realized I’m not talking “agile”, I’m talking eXtreme Programming

eXtreme Programming (Wikimedia)

👩 Alice —

Ha but that’s how people work under agile

💂 Jeff —

… whatever … same thing, different decade

• 1990: eXtreme Programming
• 2000: Agile
• 2010: DevOps
• 2020: DevSecMLUxOps

I’m actually a little disappointed with this decade. The renaming of the process clearly demonstrates a loss of creativity.

UPDATE: 2023–03–22

I came across “The Agile Death March”, by Dave Nicolette, and found it really speaks to the point I was trying to make

Modern Agile Wheel (modernagile.org, Creative Commons)