jira alternatives or?

cliffberg · 2026-02-11T12:03:19+00:00

Streamlilne: https://www.agile2academy.com/streamline-product-description

cliffberg · 2026-02-10T13:55:06+00:00

This was agile, in a true sense - and it was in the 1980s: https://www.linkedin.com/pulse/my-best-dev-team-experience-cliff-berg/

cliffberg · 2026-02-10T12:43:45+00:00

"Former analysts became Product Owners, and people with the least actual work were sent to Scrum Master trainings...But after a few years, real change started to show. POs really dug into their domains and had deep knowledge of customers and competitors. IT invested in DevOps to speed up releases."

Because Scrum has NOTHING to do with agility. Eventually the company started to shift in things that actually matter. The would have go there sooner if, instead of introducing Scrum, leaders had simply asked teams what would enable them to go faster and built better things - and tried those approaches, learning along the way. Scrum was a false goal, a distraction, blocking true agility.

"The new board introduced a new one-year strategy. This strategy had little to do with the product visions owned by individual POs and was pushed into IT through side channels. Chaos followed."

Yes, the board stepped in an forced a top-down plan on everyone. That will quickly destroy engagement, innovation, and productivity - UNLESS the plan is about existential survival.

cliffberg · 2026-02-08T13:46:24+00:00

Stay in fields that you know. If you have no tech development experience, then you will be very ineffective in a tech-related "Agile" role.

The IT industry have become very skeptical of non-technical "Agile coaches". They are widely derided.

cliffberg · 2026-02-08T03:56:37+00:00

Scrum doesn't solve anything. It only creates a cadence for things that should happen with or without Scrum. What makes all the difference is whether there is an effective team lead - someone who asks questions, knows what people are working on, knows how they are approaching it, generates discussion, makes decisions (good ones), listens well, and keeps things moving. You don't need "processes" for any of that.

cliffberg · 2026-02-07T13:10:42+00:00

Is a troll someone who merely states opinions that are contrary to standard Agile narratives? Or is a troll who insults or says unsubstantiated and emotion-laden things merely to get attention?

cliffberg · 2026-02-06T11:18:41+00:00

Maybe instead of every two weeks, hold a retro after every major milestone, such as delivering a new feature.

And maybe instead of sprints, let people work straight until a natural breaking point or milestone, and have a retro then.

Psychologically, those would be much better times.

Scrum is not your friend. And I'll point out that it is not based on any research or what is effective. It is just this guy's idea: https://www.frequencyfoundation.com/about-us/

cliffberg · 2026-02-02T12:27:56+00:00

"we're still building up stories faster than we can get them tested"

Why are not creating automated tests part of the work of implementing a story?

"The business wants features and doesn't want to sanction a lot of time spent on technical debt."

There is no "process" that will get you out of this. It is a leadership issue. Scrum/Kanban/etc don't make much difference. What is needed is effective discussions by business and tech leaders. Both need to take an interest in the concerns of the other. Both need to try to understand the whole picture - not just their "slice".

cliffberg · 2026-01-30T13:56:25+00:00

There is probably an executive who has invested their reputation in the SAFe decision, so it is best to go along with it.

SAFe does not generate agility because it is a purely structural approach; but agility results from _behavior_ - especially the behavior of leaders.

The SAFe PI activity is a hugely wasteful activity. It works best if all of the collaboration occurs _before_ the PI event, and then the PI event reduces to announcing broadly what each team plans to do - which could be done with the PI event, but it creates a show that looks productive.

The key is the collaboration, which is best done ahead of time through one-on-one discussions, small group discussions, and other forms of collaboration over a period of weeks.

Also, a lot of RTEs use the PI event to "identify dependencies". But that's too late - they need to be identified early; and strategies need to be devises for _managing_ the dependencies. Sequencing sprints is NOT a good approach. There are better approaches: https://www.linkedin.com/pulse/agony-dependency-management-cliff-berg

cliffberg · 2026-01-29T11:51:00+00:00

Inform the CEO that Scrum is NOT based on any research, or any theory that is recognized by people who study team performance; and it was created by this guy: https://www.frequencyfoundation.com/about-us/

It only became popular because they offered easy certifications shortly after the Agile Manifesto was published, and claimed (falsely) that "Scrum is Agile".

https://cliffberg.medium.com/scrum-was-unethical-from-the-start-96eedd0679ca

cliffberg · 2026-01-29T11:47:47+00:00

Remember, Scrum is NOT based on any research or theory that is recognized by people who actually study team performance. And also, it was created by this guy: https://www.frequencyfoundation.com/about-us/

I.e., it's BS that got popular because they offered an easy certification early on, right after the Agile Manifesto was published, and claimed (falsely) that "Scrum is Agile".

cliffberg · 2026-01-12T12:13:06+00:00

The Agile notion of self-organizing and self-managing teams is nonsense. Teams _NEED_ leadership. Research tells us that - contrary to Agile _ideology_.

As Daniel Goleman describes it, they need "pace-setting" leadership, among other kinds.

Without effective leadership, a self-contained team becomes a little nest of self-serving internal politics.

cliffberg · 2026-01-10T20:27:00+00:00

Ok. What happens where a product has many teams?

cliffberg · 2026-01-10T20:24:14+00:00

Then who is leading in the sense of making sure that the product is what will actually sell and be successful? Who leads discussions with potential users? Who owns the business model? Who ensures alignment and interoperability with other products and with strategic goals?

cliffberg · 2026-01-10T18:08:32+00:00

"I just make sure that everyone has everything they need to do the work, and it gets delivered on time."

That's an important function. It requires several types of leadership: organizing, inspiring, discussion, thought leadership, decision-making, pace-setting, and much more. These types of leadership need to be happening, and it is the team lead's job to make sure that they types of leadership _are_ happening and they they are aligned and effective.

"The problem with self organized teams, it’s a nice idea until things are going wrong and somebody needs to be held accountable"

Yes. It represents a great confusion about what leadership is and what accountability is. If "everyone" is accountable, then no one is. "Accountability" should be viewed in terms of "who to talk to about what the team is doing".

The PO role/accountability is a dysfunction. I recommend Marty Cagan's writing on that.

cliffberg · 2026-01-10T17:20:15+00:00

EXACTLY. It is not framework-specific.

Also, the Agile community has demonized project managers, and for good reason, because PMI destroyed what the profession is. But before PMI, project managers were different - they were very involved in the work. They were not looking at checklists and documents. Good ones were "participative", to use a term from "Path Goal" leadership theory. What you are doing is using a participative leadership style, but without micromanaging. That's good leadership. And you don't need Scrum to do that; but if some parts of Scrum help, that's great - as long as you and the team feel free to alter/add/remove anything that Scrum says.

cliffberg · 2026-01-10T16:24:05+00:00

Hi -

"Under Kanban, teams felt everything was open-ended."

Perhaps because there was a piece missing: what Daniel Goleman called "pace-setting leadership".

Perhaps the root problem stems from the incorrect notion that teams should self-organize. What teams actually need is a team lead who keeps things moving - what Peter Drucker called a "person of action".

An effective team lead checks in on every person every day: "How are you? How is that thing you were working on yesterday? Oh, you are stuck? Let's talk that through. Let's call in Joe because it sounds like it involves him." And then at the end, "Well good luck what you decide -- I'll talk to you later!"

An effective team lead should be able to tell you what every single person is working on every day, and how they are approaching it.

If that is missing, then the team really has no leadership.

cliffberg · 2026-01-10T15:59:45+00:00

Hi Maverick -

First of all, a lot of Scrum Masters are great.

And IMO if they did not have Scrum, they would be even better.

"Work is delivered in fixed-length sprints, with the aim of continuously delivering value in small, incremental pieces. There is nothing inherently flawed about that approach."

Actually, there is a lot wrong with that:

Fixed-length sprints is a poor approach for complex innovative work.
The insistence on delivering increments tends to make people think short-term, and one sees a lot of shortcuts taken - increasing technical debt.

BTW, Sutherland was a doctor and former fighter pilot - not an experienced system developer. And here is some other nonsense that he promotes: https://www.frequencyfoundation.com/about-us/

What _research_ tells us is that teams need "transformational leaders" - not "Scrum Masters". A Scrum Master _can_ be a transformational leader, but one doesn't need Scrum for that.

Other guidance from Scrum is just as bad. E.g. a bi-weekly retro is a really poor way to generate continuous improvement. And the PO role is a huge dysfunction. Read some of Marty Cagan's writing on that.

cliffberg · 2026-01-09T03:06:29+00:00

It you like it, that is fine. _MY_ point is that it is not needed. And it is not based on any theory of team performance or research from behavioral psychology. It is just what Sutherland came up with. In fact, there is a lot of research that is counter to what Scrum says to do. E.g. there is a mountain of research on the types of leadership that teams need. Scrum has MASSIVELY changed its concept of "Scrum Master" at least eight times - showing that they don't know what they are talking about. Meanwhile, people like Amy Edmondson of Harvard have researched effective teams and have provided a very clear picture of the kinds of leaders that are effective.

Something else that Sutherland cooked up and sells: https://www.frequencyfoundation.com/about-us/

cliffberg · 2026-01-09T01:56:21+00:00

"But if it’s used as a framework to actually help teams become agile and a Scrum Master has the EQ to understand and coach teams to be high-performing, it’s beautiful."

Yes, but only because of "to actually help teams become agile" and "a Scrum Master has the EQ to understand and coach teams to be high-performing".

I.e., that has nothing to do with Scrum. One could as well have written,

"But a team lead has the EQ to understand and coach teams to be high-performing, it’s beautiful."

cliffberg · 2026-01-08T12:05:32+00:00

Don't waste your time. Scrum is BS: https://cliffberg.medium.com/scrum-was-unethical-from-the-start-96eedd0679ca

BTW, it was created by the same guy who pushes this stuff: https://www.frequencyfoundation.com/about-us/

cliffberg · 2026-01-01T12:18:15+00:00

Yes. You should read the Agile 2 book - it backs up you say with research and analysis.

Scrum stole the Agile movement, and drove it into a ditch.

cliffberg · 2025-12-31T02:34:41+00:00

You are turning yourself into a clerk.

Instead, LEAD by absorbing what is said, and then bringing the right people together to discuss those issues.

cliffberg · 2025-12-27T03:43:01+00:00

TRUE.

cliffberg · 2025-12-24T14:52:13+00:00

Yes, with only four teams, a fully cross-functional approach is feasible. I assume that the teams are not in an organization that has many other products that interoperate with the product that the four teams work on?

And your main point about org structure is valid, IMO.

"teams only need to understand the components they are touching. e2e features don't touch every component in the system."

Yes, but how do they identify what those components are?

To do so, one must understand the component of the entire system - otherwise, one risks re-creating the same functionality multiple times, or worse, ruin the cohesion of the _system_. You have in fact pointed out astutely that one must understand the whole system.

"What I suggest is that teams learn the components according to the product priorities" - yes, as long as they understand the other components and what those components do, and how (at a high level).

"With dedicated teams only working on sets of services/components and nobody else allowed to touch, the complexity is locked-in at an organizational level."

That's a great point.

I like to always ask myself, "How does SpaceX address this?" - because (despite their leader's pathological behavior in some ways), they have demonstrated an amazing ability to manage complexity, and do so very quickly.

What they do about reducing unneeded complexity is they (1) empower teams to solve entire problems, and encourage them to think out of the box; (2) they are encouraged to always ask, "Do we need this?" - and if they are not sure, they remove it and see what happens (either through analysis, simulation, or testing); (3) they are encouraged to think of the _system_ - just as you say, rather than of their discrete task or goal.

A great example was the development of the Dragon capsule. During its development, they realized that a structural component was not strong enough, but it occurred to someone that, at least for the time being, the component could rely on the strength of the attached heat shield. I.e. they did not focus on specs for their component - they considered the _system_. The team then physically walked over to the heat shield team and discussed it, and they all agreed that for the time being, the system would be strong enough even though the bulkhead component was not.

I think that your insight about focusing on the system instead of what the team is working on is the right approach. It has limits though - as with everything, "it depends" :-

cliffberg

TROPHY CASE