On Feb 7, 2024, at 4:37 PM, Esther <esther@...> wrote:

You know me and my Hive Mind stories. The last time I did something like this it turned into “Why your users hate Agile?development (and what you can do?about it)"?

Now I’m working on an article about Agile development (for a new-to-me tech magazine), and I’d like your input.

In short: Tell me what FAKE AGILE looks like.

The story’s working title is “How to Recognize ‘Fake Agile’ Development” or “You Thought Agile Development Failed You. Turns Out You Weren’t Actually Doing Agile.”

My premise is that some companies claimed to adopt Agile — but in reality they dressed up hidebound old development practices with a new label. And they present this as “Agile failed.”

I want real practitioners to talk about recognizing “fake” Agile, the disservice it’s doing to software development processes, and what people should do to counter it.

For instance, in the discussion that inspired this article, one friend wrote that large companies love sprints and ‘stand-ups’ that are really just status meetings. But despite their lip service to agile, they regularly deliver systems that are not what the customer wants. Another said, “One of the clients I worked on used SAFe and just… ugh, if I never have to go through PI planning again that’ll be just fine with me, from what I can see SAFe is just three waterfalls in a trenchcoat.”

At the end of Frank Zappa’s song “Cosmic Debris” he asks, "Now is that a real poncho or is that a Sears poncho?” I aim to recognize the “real” thing and separate it from ersatz claims. And to give actionable advice to the people who aim to do it right. (This isn’t a pure Agile fanfest, mind you; I encourage acknowledgements of the methodology’s imperfections.)

I hope you can answer:

·????? What have you seen called “Agile” that isn’t?

·????? What did they do, and what did they think they were doing?

·????? What should they have been doing instead? What can be done to counter it, and who should be doing that?

·????? Let me know if I can quote you directly (by name, role/title, company) or indirectly (“a software developer at a Midwest insurance firm”). I prefer the former but I’m okay with the latter.

I like to think that this will spark a conversation (It’s been too long, folks) but I’m fine with private messages.

—贰蝉迟丑别谤?

You know me and my Hive Mind stories. The last time I did something like this it turned into “Why your users hate Agile?development (and what you can do?about it)"?

Now I’m working on an article about Agile development (for a new-to-me tech magazine), and I’d like your input.

In short: Tell me what FAKE AGILE looks like.

The story’s working title is “How to Recognize ‘Fake Agile’ Development” or “You Thought Agile Development Failed You. Turns Out You Weren’t Actually Doing Agile.”

My premise is that some companies claimed to adopt Agile — but in reality they dressed up hidebound old development practices with a new label. And they present this as “Agile failed.”

I want real practitioners to talk about recognizing “fake” Agile, the disservice it’s doing to software development processes, and what people should do to counter it.

For instance, in the discussion that inspired this article, one friend wrote that large companies love sprints and ‘stand-ups’ that are really just status meetings. But despite their lip service to agile, they regularly deliver systems that are not what the customer wants. Another said, “One of the clients I worked on used SAFe and just… ugh, if I never have to go through PI planning again that’ll be just fine with me, from what I can see SAFe is just three waterfalls in a trenchcoat.”

At the end of Frank Zappa’s song “Cosmic Debris” he asks, "Now is that a real poncho or is that a Sears poncho?” I aim to recognize the “real” thing and separate it from ersatz claims. And to give actionable advice to the people who aim to do it right. (This isn’t a pure Agile fanfest, mind you; I encourage acknowledgements of the methodology’s imperfections.)

I hope you can answer:

·????? What have you seen called “Agile” that isn’t?

·????? What did they do, and what did they think they were doing?

·????? What should they have been doing instead? What can be done to counter it, and who should be doing that?

·????? Let me know if I can quote you directly (by name, role/title, company) or indirectly (“a software developer at a Midwest insurance firm”). I prefer the former but I’m okay with the latter.

I like to think that this will spark a conversation (It’s been too long, folks) but I’m fine with private messages.

—贰蝉迟丑别谤?

On Feb 8, 2024, at 11:25 AM, Dave Nicolette <davenicolette@...> wrote:

Hi Esther,

It's an interesting question. I find myself at a loss, not for lack of observations and experiences, but because there's so much to say and most of what I might say does not conform with the standard assumptions about "agile".?

So, how can I begin in a way that makes sense, and where should I stop, to avoid offense?

[1] Perspective

The question was posted to an Extreme Programming mailing list. Extreme Programming is not dependent on Scrum or Kanban or RUP or you-name-it. Process improvements are one thing and technical practices another. Conflating the two under a heading like Scrum or "agile" muddies the waters.?

On this list, you're likely to get responses from the perspective of programmers. Maybe that's what you want. But remember the recent discussion on Mastodon about software quality. Many developers insisted their product had high quality. Why did they say so? Because they always met their Definition of Done. What do real people say about software quality generally - the apps they depend on for daily life? It's a different story. Many programmers don't look beyond their own team's Definition of Done, and that may not correlate well with end user experience.

When you ask programmers about programming, you may not get a broad perspective in response. You'll get details: One respondent mentions a team's braching strategy as the very first bullet point to describe fake Agile. What's the relative importance of that, really? The last bullet point in the same list reads, "No process improvement actually happens."?

Shouldn't that be first? Isn't that The Thing that would solve the branching issue along with everything else? If your face is being pushed into the details every day, then naturally the details will be top of mind for you. But does that answer your larger question? In a large company that's struggling with SAFe, questionable technical practices on one of their 2,500 teams is probably not the largest contributor to their problems.

It might be interesting to hear from some of the creators of XP and/or the Agile Manifesto on this question. So far, I haven't seen responses from them. I can only offer one more opinion from the peanut gallery. So here goes.

[2] Old and new and old again

It's 2024. Concepts and techniques that later became associated with the buzzword "agile" have been around since before the occupation "programmer" had a name, even if they were not formalized and didn't stick.?

The women who plugged in patch cables to program ENIAC in the 1940s worked in pairs. Was that pair programming? Maybe it doesn't matter, as solo work soon became the standard. Pair programming came back years later, when members of another generation believed they invented it. They named it, anyway, and maybe naming is better than inventing, because that's how you get remembered.

Margaret Hamilton's Higher-Order Software from the 1960s looks a lot like static code analysis. After the Moon, she and her Apollo manager Dan Lickly started a company named Higher-Order Software to peddle the solution, but they were unable to convince companies of the value of checking the quality of their software. Static code analysis came back years later, when the market was a little more ready for the idea...when companies had become heavily dependent on software whose quality was out of control.

It seems to me people working on software in the 1960s, when it was still new and so much work was done in an ad hoc way, hit upon many of the same ideas that we still talk about today. For instance, the 1968 NATO Software Engineering report quotes Kolence as saying, "The manufacturers are always under pressure from the users to give them something that works even if it is not complete. The classic trade-off in software production is between features and schedule — not between working well and not working well."?

Now, tell me how that differs from the idea of a "vertical slice of functionality" that has been thoroughly tested and meets expectations. Tell me it differs from the advice given by "agile" coaches who warn teams against cutting corners to try and meet deadlines. The software has to work well. That's definitional. It can be incomplete, but whatever is delivered must work well.

The seed was there and in hindsight we can easily see what might have grown from it. Yet, the idea was lost shortly after 1968. Even the 1969 NATO conference, just a year later, focused on improving and streamlining linear SDLC approaches. The clear warning in Royce's 1970 paper was lost amid the noise of people developing linear "engineering" methodologies for software development. ?

[3] Pattern

There's a repeating pattern in the software field of new (or at least different) ideas coming along, following the diffusion of innovations curve, and being displaced by the next new idea.?

V-Model has the concept of "verification" - it's the "testing" side of the V. It's still based on linear thinking, but it's an improvement. Spiral has the concept of incrementally building up the solution through a series of iterations during the construction phase. It still has fixed requirements and design phases and a fixed testing phase, but it's an improvement. RUP ties together several other good ideas into a cohesive set of guidelines and normalizes terminology and diagramming conventions. A little document-heavy, at least as usually practiced, but still an improvement.

People continued to think of improvements over RUP. Cockburn's Crystal methodologies improve on RUP (in my opinion) because they are simpler than RUP. Arbitrary complexity is unhelpful, in my view. Extreme Programming and Scrum are both successors of the RUP era, too.?

Scrum superseded RUP as the market-leading popular method accompanied by much gnashing of teeth by the many RUP consultants and trainers whose business models and careers were cemented into a foundation of RUP. "But nothing says you can't do RUP in a way that resembles Scrum! We're not obsolete!" I can still hear their desperate voices fading away into the temporal void.

As the software world became aware of Lean Thinking, the same pattern repeated. This time, consultants and trainers whose business models and careers were cemented into a foundation of Scrum were gnashing their teeth. "But nothing says you can't do Scrum in a way that resembles Lean! We're not obsolete!" I can still hear their desperate voices fading away into...oh, wait; they're still screaming.

Scrum is disruptive, and rarely is implemented properly because organizations can't change in a meaningful way until after thay've changed in a meaningful way. Catch-22. Maybe organizations aren't doing Scrum right because they should be doing something else.

Scrum consultants have cleverly characterized Lean (or Kanban) as "too advanced" for organizations that are only just beginning to attempt improvement. They claim you must master Scrum before you can attempt Kanban. The truth is, Lean/Kanban is significantly easier for organizations than Scrum, and yields very good results. Also, Lean-based methods don't rely on self-referential metrics (e.g., velocity or test coverage) to measure progress.

[4] Religion

Scrum offers a good starting point for improvement in organizations that operate in 1980s style. It forces the organization to dismantle structures and processes that hold the old way of doing things in place. In the right context, it's a good model.?

It's a good model for greenfield development. Unfortunately, most IT work isn't greenfield development. Most development teams spend a lot of time addressing unplanned work that comes up mid-sprint. Scrum is extremely clumsy in that situation. Teams can spend more time and effort trying to force Scrum to "work" than they do completing real tasks.

Sutherland's brand of Scrum incorporates software engineering principles, as does Extreme Programming. The outer ring of Ron's XP diagram is similar to Scrum. But Scrum as such is simply unnecessary.

Scrum is a victim of its own success. Or perhaps I should say, Scrum's customers are victims of the success of Scrum's certification program. The ease of earning basic certification has led to a veritable army of unqualified people leading software development work in thousands of companies.?

I've met Scrum Masters who were bus drivers or loading dock workers two months before being assigned to mission-critical software development teams. In my opinion, someone who has never been responsible for production support or customer service for a software product should not hold any sort of leadership or guiding position in a software organization. Scrum has poisoned the industry.?

At the same time, the growth of "frameworks" has led to cookie-cutter "agile" implementations in which companies hire 150 or more "agile coaches" whose only job is to teach the staff how to use Jira (or similar) to fake Scrum.?

Scrum (or a child's drawing of it) has become de rigueur for companies of all sizes. It's no longer a "lightweight management wrapper for empirical process control," as Ken called it. It's a religion, with its own deities, prophets, saints, demons, scripture, rituals, incantations, sins...and excommunication, for any who dare suggest the idols will not smite you if you deviate from dogma.

Today, even the "agile" true believers speak in Scrum terms. For instance, XP has "iterations," not "sprints," but members of the XP list consistently say "sprint." The word "iteration" is general; if "agile" encompasses Scrum and Scrum is just one approach among many that are consistent with "agile," then logically Scrum people should adopt the word, "iteration".?

The word "sprint" implies running as fast as possible with no thought of what happens after you cross the finish line. "Agile" development is about steady delivery at a sustainable pace. "Sprint" is the wrong word. Maybe it's the right word for Scrum - remember Ken's article about Scrum as a developer pressure cooker - but it's the wrong word for "agile".?

Frameworks for scaling "agile" (or de-scaling organizations to fit "agile") are all based on Scrum. Every one of them assumes Scrum is the core of everything. Some of them tack on a few Lean buzzwords as an afterthought, but the frameworks don't operate on Lean principles.

Scrum has won the game. That means customers and users of software have lost.

[5] Improvement

There is continuing improvement. Agile, XP, TDD, and you-name-it are not static, final solutions.?

Yet the question before us seems to have an unspoken underlying assumption: There are two camps of "agile", both of them closed to change, sniping at each other like the Catholics and Protestants of Ulster. One camp is represented by frameworks and corporate Scrum, the other by true believers who quote the Manifesto again and again to people who don't understand the meaning.

But "agile" is not static and isn't meant to be.

Test-Driven Development is one of the most talked-about aspects of software development today, but people seem to forget that others had considered the importance of testing as an integral part of development before the buzz-term "TDD" was coined.?

TDD didn't spring forth spontaneously in 1990 in its present form. Details of how to apply TDD have evolved over the years.?

Today we assume TDD implies test-first, but the original concept of TDD didn't insist on that. The idea of being "test infected" was an outgrowth of early experiences applying the idea of TDD. Moving the tests ever leftward eventually found them all the way to the left - before the code. The idea of emergent design came to the fore after the possibility of it became visible through improvements in TDD practice.?

Years ago, TDD proponents like Bob Martin would set up starter code when teaching TDD and then ask programmers to flesh out the implementation through test cases. But that approach assumes you begin with a solution design in mind; not really emergent design. Later, practitioners like George Dinwiddie asked people to drive out the logic without any assumptions - no starter code. We would extract "production code" only when the test suite made it necessary to do so. We would let the code tell us what the design needed to be.

People have applied TDD techniques and tools to do things other than greenfield development. I recall a conference presentation (but not the names of the presenters) years ago where the presenters demonstrated a technique they called "core and slice" to isolate code when tracking down a production bug, using a strict mocking framework to force exceptions that guided them to the source of the bug. Behavior-Driven Development (Dan North, Liz Keogh) is an offshoot of TDD. Arlo Belshee has applied TDD tools and methods in various ways, like his Read By Refactoring approach to learning a code base. Emily Bache's Approval Test approach to legacy code combines TDD techniques with other testing techniques.?

Today, most of us consider GeePaw Hill's idea of Many More Much Smaller Steps as the current state of the art in TDD practice. Is it the end state of TDD? Probably not. Even the person credited with inventing (or re-discovering or naming) TDD, Kent Beck, moved on to a different approach he calls "test && commit || revert". Maybe he's moved on again since then.

I think people should be trying different ideas all the time. I remember hearing that the idea of XP was to find what works and turn the dials up to 10, and if something doesn't work then stop doing it. Whatever the state of the art is today, it can be improved.?

So, is Company XYZ doing "agile" right? Well, maybe not if they're doing it the same way they were yesterday or last week. Maybe not, if they've stopped questioning it.

[6] Timing?

In view of the repeating historical pattern, the single-minded focus on the word "agile" circa 2024 seems to miss the point. Is Company XYZ doing "agile" properly? Are they doing Scrum properly? What does fake "agile" look like? What does real "agile" look like?

Who cares??

I'd be more interested to know whether Company XYZ is satisfied with their current outcomes. If not, have they identified what is not satisfactory? If so, what steps are they taking to improve matters? How are they measuring the effects of those changes??

They can implement SAFe or LeSS or Scrum-But or Kanban or RUP or Spiral with all I's dotted and all T's crossed and still be dissatisfied. They're focused on implementing a Thing instead of on improving their situation. The problem isn't the Thing, it's the focus.

On Thu, Feb 8, 2024 at 4:58?AM Avi Kessner <akessner@...> wrote:

In my experience, it usually goes like this.
We look at the agile principles, (copying from JeffGrig)

• Individuals and Interactions over Processes and Tools
• Working Software over Comprehensive Documentation
• Customer Collaboration over Contract Negotiation
• Responding to Change over Following a Plan
  

Then from my experience, Individuals?and Interactions are not trusted. The individuals are junior, the interactions are blocked by hierarchy. The processes and tools are the first thing the company looks for to be agile. Let's use a ticketing product, and declare the Git branching strategy we must use, and here is the CI tool we need to get, and which tools does this, and which process enables that?? At no?time does the manager ask the team, "what do you think?, how can I enable it? Go talk to these?complaining customers and figure out a solution."

Working software? Yeah we have that already, and now it needs to be maintained, and new people need to join, and we don't have time to interact with them, so make sure we have everything documented. If we don't have documentation, the person will sit for hours not knowing what to do. Oh, and this back and forth is taking too long, so let's document the plan before we write the change, get agreement, and you can go work. In short, a whole bunch of gatekeeping and lack of trust.

The third agile point is really not relevant in most jobs I've had. Sometimes it comes up, And when it does, it's REALLY bad, like "don't fix that bug, it's better to charge them for manual fixes". But that's super rare in my experience. And I don't think companies that do that even claim to be "Agile".

The last point is the only agile point that I think most companies that do fake Agile will actually care about. They want to respond to change, and they are ok modifying their plan. However, they want a plan on how to do the change!

brought to you by the letters A, V, and I
and the number 47

On Thu, Feb 8, 2024 at 1:51?AM JeffGrigg <jeffreytoddgrigg@...> wrote:

When I'm suggesting agile improvements to their processes, and they insist that they're agile already, because they do SCRUM, or SAFe, etc., ...

I open the "Manifesto for Agile Software Development" and have a talk with them about the Four Core Values, and how they fall on each one:

• Individuals and Interactions over Processes and Tools
• Working Software over Comprehensive Documentation
• Customer Collaboration over Contract Negotiation
• Responding to Change over Following a Plan

In practically all cases, it quickly becomes clear that their actual day-to-day practice, and hence actual values, are more aligned with the things on the right than the things on the left.

So, like, "It's a free country and you can do whatever you like." ***BUT*** "You can't honestly call it 'Agile'."

?

(We could talk about the Twelve Principles.? But after getting most or all of the core values?backwards, what's the point?)

Esther

February 7, 2024 at 2:37 PM

You know me and my Hive Mind stories. The last time I did something like this it turned into “Why your users hate Agile?development (and what you can do?about it)"?

Now I’m working on an article about Agile development (for a new-to-me tech magazine), and I’d like your input.

In short: Tell me what FAKE AGILE looks like.

The story’s working title is “How to Recognize ‘Fake Agile’ Development” or “You Thought Agile Development Failed You. Turns Out You Weren’t Actually Doing Agile.”

My premise is that some companies claimed to adopt Agile — but in reality they dressed up hidebound old development practices with a new label. And they present this as “Agile failed.”

I want real practitioners to talk about recognizing “fake” Agile, the disservice it’s doing to software development processes, and what people should do to counter it.

For instance, in the discussion that inspired this article, one friend wrote that large companies love sprints and ‘stand-ups’ that are really just status meetings. But despite their lip service to agile, they regularly deliver systems that are not what the customer wants. Another said, “One of the clients I worked on used SAFe and just… ugh, if I never have to go through PI planning again that’ll be just fine with me, from what I can see SAFe is just three waterfalls in a trenchcoat.”

At the end of Frank Zappa’s song “Cosmic Debris” he asks, "Now is that a real poncho or is that a Sears poncho?” I aim to recognize the “real” thing and separate it from ersatz claims. And to give actionable advice to the people who aim to do it right. (This isn’t a pure Agile fanfest, mind you; I encourage acknowledgements of the methodology’s imperfections.)

I hope you can answer:

·????? What have you seen called “Agile” that isn’t?

·????? What did they do, and what did they think they were doing?

·????? What should they have been doing instead? What can be done to counter it, and who should be doing that?

·????? Let me know if I can quote you directly (by name, role/title, company) or indirectly (“a software developer at a Midwest insurance firm”). I prefer the former but I’m okay with the latter.

I like to think that this will spark a conversation (It’s been too long, folks) but I’m fine with private messages.

—贰蝉迟丑别谤?

On Feb 8, 2024, at 2:55 PM, Jeff Langr <jeff@...> wrote:

Hi Esther,

At the heart of agile is an iterative-incremental mindset for just about everything. That includes "better ways of developing software."

Stand-ups are a great and immediately visible microcosm of dysfunction, for one example, and everyone here has seen all sorts of bad manifestations of them. And yet, I've engaged with teams who have obviously been running more-or-less-the-same tedious, protracted stand-ups for a long time. And while the stand-ups might be helping a little, they've not helped to the extent that folks are investing in them. (Hint: closer collaboration and less WIP are often a big problem.)

How do you recognize fake agile via stand-ups? I have a great picture from maybe 15 or more years ago, showing maybe 2-3 folks actively engaging--likely the project manager person and a developer or two. The remainder of people are disengaged, with arms crossed or holding up the wall, and are likely focusing on "What am I gonna say when it's my turn?"

Fake agile = "we ain't gettin' any better," to summarize--this apparent lack of interest in trying to find those better ways. (That they don't know they're not getting better, well, that's another piece of it.)

When leaving an organization that I've coached, I tell them (in a nicer way) that if I come back in six months, and things still look the same, they've kind of missed the point.

Cheers,
Jeff

Jeff Langr / +1-719-287-4335

Esther

February 7, 2024 at 2:37 PM

You know me and my Hive Mind stories. The last time I did something like this it turned into “Why your users hate Agile?development (and what you can do?about it)"?

Now I’m working on an article about Agile development (for a new-to-me tech magazine), and I’d like your input.

In short: Tell me what FAKE AGILE looks like.

The story’s working title is “How to Recognize ‘Fake Agile’ Development” or “You Thought Agile Development Failed You. Turns Out You Weren’t Actually Doing Agile.”

My premise is that some companies claimed to adopt Agile — but in reality they dressed up hidebound old development practices with a new label. And they present this as “Agile failed.”

I want real practitioners to talk about recognizing “fake” Agile, the disservice it’s doing to software development processes, and what people should do to counter it.

For instance, in the discussion that inspired this article, one friend wrote that large companies love sprints and ‘stand-ups’ that are really just status meetings. But despite their lip service to agile, they regularly deliver systems that are not what the customer wants. Another said, “One of the clients I worked on used SAFe and just… ugh, if I never have to go through PI planning again that’ll be just fine with me, from what I can see SAFe is just three waterfalls in a trenchcoat.”

At the end of Frank Zappa’s song “Cosmic Debris” he asks, "Now is that a real poncho or is that a Sears poncho?” I aim to recognize the “real” thing and separate it from ersatz claims. And to give actionable advice to the people who aim to do it right. (This isn’t a pure Agile fanfest, mind you; I encourage acknowledgements of the methodology’s imperfections.)

I hope you can answer:

·????? What have you seen called “Agile” that isn’t?

·????? What did they do, and what did they think they were doing?

·????? What should they have been doing instead? What can be done to counter it, and who should be doing that?

·????? Let me know if I can quote you directly (by name, role/title, company) or indirectly (“a software developer at a Midwest insurance firm”). I prefer the former but I’m okay with the latter.

I like to think that this will spark a conversation (It’s been too long, folks) but I’m fine with private messages.

—贰蝉迟丑别谤?

On Feb 7, 2024, at 2:37 PM, Esther <esther@...> wrote:

You know me and my Hive Mind stories. The last time I did something like this it turned into “Why your users hate Agile?development (and what you can do?about it)"?

Now I’m working on an article about Agile development (for a new-to-me tech magazine), and I’d like your input.

In short: Tell me what FAKE AGILE looks like.

The story’s working title is “How to Recognize ‘Fake Agile’ Development” or “You Thought Agile Development Failed You. Turns Out You Weren’t Actually Doing Agile.”

My premise is that some companies claimed to adopt Agile — but in reality they dressed up hidebound old development practices with a new label. And they present this as “Agile failed.”

I want real practitioners to talk about recognizing “fake” Agile, the disservice it’s doing to software development processes, and what people should do to counter it.

For instance, in the discussion that inspired this article, one friend wrote that large companies love sprints and ‘stand-ups’ that are really just status meetings. But despite their lip service to agile, they regularly deliver systems that are not what the customer wants. Another said, “One of the clients I worked on used SAFe and just… ugh, if I never have to go through PI planning again that’ll be just fine with me, from what I can see SAFe is just three waterfalls in a trenchcoat.”

At the end of Frank Zappa’s song “Cosmic Debris” he asks, "Now is that a real poncho or is that a Sears poncho?” I aim to recognize the “real” thing and separate it from ersatz claims. And to give actionable advice to the people who aim to do it right. (This isn’t a pure Agile fanfest, mind you; I encourage acknowledgements of the methodology’s imperfections.)

I hope you can answer:

·????? What have you seen called “Agile” that isn’t?

·????? What did they do, and what did they think they were doing?

·????? What should they have been doing instead? What can be done to counter it, and who should be doing that?

·????? Let me know if I can quote you directly (by name, role/title, company) or indirectly (“a software developer at a Midwest insurance firm”). I prefer the former but I’m okay with the latter.

I like to think that this will spark a conversation (It’s been too long, folks) but I’m fine with private messages.

—贰蝉迟丑别谤?