Not light enough

[impredicative]

Kanban is IMHO sufficiently light. The addition of sprints is what complicates things and often leads to a burnout. The imposition of estimates as deadlines becomes a problem in sprints.

Sprints are more of a cult than anything else. They're in effect for producing throwaway work of little lasting value. The best work that I have done over the years has never been in sprints.

The developers must have a right to control a portion of the backlog as far as refactoring is concerned. Ideally this should be at least 50%, although it really should be left to the developer assuming they're experienced. The feeling of constant grind comes in part from always being told what to do with no breaks and no freedom of thought. I agree that Kanban is better for those who can manage themselves, and maybe less so for those fresh out of college.

I fell into a deep depression at last my job where Scrum was a religion and the grind was unrelenting. I got myself out of it, but at least three of five people won't.

[diffractometer]

I agree, it's restrictive to make a rule "one can remove but not add cards." Often times adding a card can be subtractive to the amount of work going into a sprint and make the effort more lean. Honestly most people conflate the idea of being obedient to the firm over personal productivity signaling.

[davebs]

I think Kanban is fine, but there are some ideas that fall under the umbrella of agile that I like. I think it's worth having an agile that's easy to implement and fits in a small document, as opposed to a book or workshop. I also see it as an opportunity to have a discussion around ways to mitigate burnout on teams, which I think is probably a bigger issue than the particular type of methodology you use.

It can be modified to suit your purposes. But if there's one differentiator to Agile Lite I'd like to point out, it's that we are explicitly saying, "Hey, agile teams are burning out just as much as other development methodologies, maybe we need to build explicit rules in to prevent overheating the engine that is the engineering team."

I think the relative restrictiveness of the system is addressed here.

[xspade]

In my experience, teams that use Kanban do burn out, although it's more of a slow-burn and depends heavily on the developer, team and the type of project that they're working on. I've noticed most of the Kanban-based issues on teams I've worked on are related to:

• The constant influx of work that never "ends", leading to the feeling of a constant grind.
• Developers working on a series of challenging cards, and even though they're pacing themselves, they feel overwhelmed after a few weeks.
• Developers not taking enough breaks and vacations, for months at a time, leading to longer burnouts.

Sprints aren't the perfect solution, but they at least get everyone on the same cadence. I'm not sure I agree with the week off to surf and paint, but taking a step back, improving test cases, refactoring, etc. gets your brain working in different ways and gives developers a sense of being "done" which is huge.

Even though I've seen problems with Kanban, I'm a fan and I think it's very useful for the right type of projects and teams. If the team is really experienced, they're better at managing themselves, and also if they're working on a project that's very familiar (i.e. no new learning or major technical challenges involved), then Kanban all the way.

The real question for AgileLite, in my opinion, is: Are sprints a requirement or only a recommendation? Can we come up with a system that's lite enough and gives us the flexibility to use either sprints or a continuous Kanban like flow?

[davebs]

I'm not sure I agree with the week off to surf and paint, but taking a step back, improving test cases, refactoring, etc. gets your brain working in different ways and gives developers a sense of being "done" which is huge.

It's funny how you can have one sentence that people seize on. I don't even surf or paint. I was using it as a hypothetical, as a placeholder for "take it easy". Now everyone thinks I'm taking my whole team surfing every month and closing down the office. No, not so much. But I definitely am saying "Take it easy" for that week and I think that's pretty manageable for most companies. And if you want to surf or paint? Go for it. Is everyone doing that every time? No, in all likelihood they are not. Is there a point when work isn't getting done? For sure, and then it's a problem. Maybe I need a line at the top of the text file that just says: Use common sense!

The real question for AgileLite, in my opinion, is: Are sprints a requirement or only a recommendation?

For me they're a requirement. I have always liked the concept and find them to be effective when used properly.

Can we come up with a system that's lite enough and gives us the flexibility to use either sprints or a continuous Kanban like flow?

You certainly can come up with such a system, but how does it combat burnout and prevent management overreach?

[xspade]

Good points, and for what it's worth, I'm a fan of a sprint/iteration based system.

It's funny how you can have one sentence that people seize on. I don't even surf or paint. I was using it as a hypothetical, as a placeholder for "take it easy".

I figured as much, and this makes it more clear. For me, the hold up was agile is a way to get work done, and surfing and painting are recreational... having those as examples made me think it was implying giving your team a week of vacation after every sprint. Taking it easy, still doing work, but not sprint-related makes sense.

[davebs]

@impredicative Sorry to hear about you falling into a deep depression, I've been there, it really sucks. I was initially attracted to scrum when I learned about it, but turned off by people's religious adherence to aspects of it that I didn't see making a difference. So "Agile Lite" is very much a reaction to that.

As far as sprints, I think sprints are a useful way to break up work and update priorities in a rapidly changing environment, and it makes sense to fit them into months mostly because there's a naturalness to organizing work that way. I get that the concept of a sprint itself could become oppressive in the wrong hands, but I think it's just a word used to describe a block of time with some allocated issues and I generally prefer organizing around them.

[muzzah]

I think it's worth having an agile that's easy to implement ....

I don't think you understand what the term agile is in the context of software development. You don't have agile. You become agile as a team. The whole point of having an agile software development methodology is to become responsive to change. You are meant to have people interacting over processes and tools. You are meant to increase collaboration in an ongoing effort to deliver working software quickly and iteratively. What you propose here goes fundamentally against that when your core people are taking it easy for a week rather than being involved in influencing what they should be working on. Working on a pre-planned backlog for 3 weeks means you have little room for responding to change that a business needs to make. And your sentence above saying that you should have agile that is easy to implement shows how little you actually understand. I recommend you read the agile manifesto and Martin Fowlers article about what agile has become to gain a better understanding.

[davebs]

@muzzah No dude, I don't think you understand what the term agile is in the context of software development. All your sentences about how hard agile should be to implement show how little you actually understand. I recommend you read my article about Agile Lite, it's a new system that's super awesome and will surely solve all the problems you have and answer all your questions and wash your car but you have to follow it exactly otherwise it doesn't work.

[muzzah]

You either didn't read my sentences or are just being sarcastic. I didn't propose anything. You are the one proposing a process. Your attitude and passive agressive tone responding to people trying to create a discussion shows a lot about the person you are. But I will leave it up to you to have an agile rather than actually read about what core founders who actually came up with the concept wanted people to understand.

[davebs]

@muzzah you lead with "I don't think you know what you're talking about blah blah blah" and expect a real response? If you have a link to share or some information, that's great, just say that.

[muzzah]

It is clear by your responses to other people and me that you do not really care about other information presented to you that doesn't align with your thoughts, your Agile lite concept and how you want to have an agile. If you cannot take criticism here, then any information presented to you is a waste of time. Hope your agile lite works out for you.

[xspade]

I agree with @muzzah. He didn't even lead with:

I don't think you know what you're talking about
I don't think you understand what the term agile is in the context of software development.

Big difference between the two. Agile has a really specific meaning, and it's being subverted. Here's a really nice article by one of the OG's who signed the original manifesto and talks about this exact same topic: https://pragdave.me/blog/2014/03/04/time-to-kill-agile.html

[davebs]

Hey, fair enough. I'm going to take a break and see where the conversation goes.

[xspade]

In all fairness, @davebs, I think you explained it pretty clearly when you said that AgileLite is a reaction to people who follow a process too religiously. I feel like it's a misunderstanding over the meaning of a word, but I do think there is a bigger problem that needs to be solved: Coming up with a light-weight agile process that's concise, open, easy to learn and understand, and rigid enough to follow that actually works.

[floer32]

wanted to note for posterity that I empathize with OP @impredicative but that I've had the same issues described in other "light" processes like Kanban. so +1 to @xspade 's explanation of this, the slow-burn.

more generally "lightness" itself is not a silver bullet. (same as how it doesn't help to blindly throw more process at the problem.)

"light" should just be taken to mean "adaptable" and "just enough for the context(s)" (team, business, time).

instead of thinking of "light vs not" as a single axis, I'd recommend thinking in more tactile or physical metaphors (malleable substances, things that can be disassembled and reassembled quickly, rooms where the furniture can be moved around and so on.)