davebs / agilelite Goto Github PK

If so, could you show these examples and elaborate a bit on the results (if possible with comparison to the "overcomplicated" agile), as we're actually considering implementation of it as a workflow for a team working on one of the products?

Hello @lazaruslarue and @davebs , please make a Spanish branch to mix the translation into Spanish that is here https://github.com/adrian011494/AgileLite/tree/spanish

Could you elaborate on why 3 weeks is a good time? What would happen if teams increased or decreased the time period. In my experience 3 weeks to far too long and leads to staled issues and extra stress near the end.

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.

Hi,
awesome project :)

I was thinking that it might be better to change the name sprint to iteration as that gives even more focus on the "without the burnout". It is not a hectic sprint, it is simply an iteration.

Cheers,
Johan

I get it. You want to prevent burn out. That's fine! But unfortunately your assumptions are wrong! It's not the framework that causes burn out! It's in most cases the somehow understandable desire of the business to get as much done as possible in as little time as possible. Often it's not understood from management that you will pay a high price for keep doing that over a long period of time. How does your "agile light" approach prevent that in any way? You told me earlier in another ticket that unfortunately the classic agile frameworks are often implemented in a wrong way. You are right! But how does your approach prevent being implemented wrongly?

As far a I understood so far, your "agile light" tries to protect the developers against any kind of organisational meeting culture. The don't need to attend the sprint planning. There is no need for Stand Ups and you also said no Retrospectives needed. So what does it mean? Management is planning the sprint for you! You will have more on your plate as you can solve! No Retrospective means you won't even have a platform to adress this! No Standups? No way of telling everyone involved including the PO that there is too much in the sprint! Great idea!

So, basically your "agile light" in a bad environment makes the situation even worse!

What would be a way of preventing burn out you ask?

Staying in a dialog with the business side of the company! Constantly negotiate the technical needs of your code against the business needs. Being involved in every single Sprint planning session! Try to convince the management that the code will need constant refactoring if it should still work in a few years! And be very clear about what the team can achieve! And if the management still thinks it needs overtime and work on weekends get the hell out of there as quick as you can! No framework will ever improve that environment!

First, thank you for this, this is spurring so many conversations that need to happen.

I am on the same page about ditching the conventional standup.

Wonder if there is a place for mentioning some alternatives to standups which are friendly to asynchronous and distributed teams. For example Range, https://www.range.co/ . (Note, I have no affiliation with Range.)

Another tool on this point is Twist (by Doist) (again, no affiliation). It's an attempt to obviate (as much as possible) both Slack and Email and the problems each have. It can support a pretty astounding change in a team's culture and daily habits. Some Slack->Twist glue with Zapier can even help a team move or rebel gradually.

I know you are skirting mentioning specific tools -- but where do you draw the line between 'standup' (a process facilitated by tools) and a thoughtfully designed tool (which can create/nurture a process that may not be feasible without it)? Also many people just don't know (yet) that there are really viable alternatives like Range and Twist.

It's not simply a matter of convenience of telling the tools up-front. It can be formative to team decisions.

I can't tell you how many times I've been in interviews, where there was discussion of views and intentions very similar to Agile Lite. Teams that would have been good fits. But then they think

The only way we can stay agile is face-to-face, using stickies!

They might be right to get rid of JIRA etc but we lose a lot of opportunity if the team winds up geo-constrained just because we don't know there are supportive tools.

Thoughts?

It is not super clear what an "off week" is. Do you mean totally off? Or something more along the lines of "people work in lighter tasks such as documentation, contributing to open-source projects, and others"?

One thing that bug me is this statement :

Once a sprint has begun, Issues may not be added to the sprint, but they can be removed. This reduces context switching and that is a good thing.

According to scrum.org you have this about the sprint :

• No changes are made that would endanger the Sprint Goal;
• Quality goals do not decrease; and,
• Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.

If you have launched your sprint and after a while you realize you have defined an issue not relevant to meet your sprint goal and instead, you have to do another one, you have to dismiss the former and pick the latter, otherwise you would fail to reach your sprint goal, not doing so could not be qualified as agile.

I'm trying to understand how this is a strategy and not an alternative rambling from someone who feels overworked or over tasked.

• Why 3 week sprints?

• Why an entire week off for a 45 minute meeting

• Why are tickets that are not complete in a sprint then backlogged instead of being completed in the week off? Surely if a sprint is well planned then developers are not burnt out when they still have incomplete items?

How has this ramble got 900 stars already?

Please provide an ounce of justification and/or proof to these timeframes.

As discussed partly in #3 and #1, the rule to disallow new working being added is problematic:

• It's possible "work can be removed but not added" will lead to the unintended consequence of over-filling the sprint. If there are too few items, the development team could end up with nothing to do, whereas if there are too many, they can simply remove the ones they don't get to.
  • From a manager/PO/company point of view: there is a large negative to underestimating (missed productivity) and almost no negative to over-estimating (at worst, the developers complain a bit)
• It's fairly common to come across bugs in existing code while working on the code. Sometimes these are even impediments to the work being done. It should be possible to create a distinct ticket (to make tracking, release notes, etc simpler) and fix the bug, without having to go through the ceremony and delay of putting it in the next sprint.
• Critical in-production bugs can be discovered that are worthy of diverting attention -- customers should not have to wait for up to 8 weeks (end of the following sprint) for a fix.

There could be rules around adding work, such as (not mutually exclusive):

• only developers are allowed to pull in work
• an item of equal size must be removed for any new item to be added (unless everything is done already)
• any added item gets a size inflation penalty (eg, additional points / hours / larger t-shirt size / etc) to account for the context switch it imposes

These could just be suggestions (for team-specific rules), but I think the broader concept of never allowing items to be added is just overall totally impractical.

People have mentioned that calling this project "Agile Lite" is an affront to the original intent of Agile. Is that true yes/no? And if so, what's a better name?

Sorry to throw this in here, but I have to....

To me this reads like a typical "I'm a conference speaker and tell you how to work without getting stressed". Reading this, I was asking myself whether you have actually ever worked in a real company. Sorry, I do not want to sound harsh here, but honestly, having a 3 week sprint without any issues/bugtickets that can be created? How would this ever be possible?

It's software. Software is broken by nature and if there're no bugs, it means you are not progressing. So if you disallow creating bugtickets/issues and therefor force ppl to wait for fixes for 3 weeks (worst case) you probably don't have much customers anymore after a few of your sprints. Even Kanban has "silver bullets".

I like the fact tho to avoid sidetracks, but there are some very big differences between what you wrote here and what is actually realistic.

Again, this is completely my own opinion and neither reflects my employer's nor anyone else's opinion :D

I'd like to translate this to Persian.
Is there any guideline or structure for making translations?

Does your simplified process include a team retrospective at the end of the month? This is a vital part of most agile team workflows, no?

The whole approach really sounds more to me like a waterfall workflow. I am pretty much convinced that you can avoid burnouts by implementing existing agile workflows in the right way.

Do you really think you would need a whole week to decide on which tickets should be in the next sprint? And why shouldn't be the developers included in that process? Don't you think you would need the feedback of the developers to plan a sprint properly?

I generally doubt that this approach is less timeconsuming then regular backlog refinement sessions with the team.

What would that look like?

I have a strong opinion on assigning task to developers. Basically you shouldn't do that at all! The team should refine its work and then decide on their own who should work on which task.

There are 52 weeks in a year not 48.

From your faq:

> Why 3 week sprints?

Because development work plus recovery time then fits into 12 slots per year. 

First off I love this, short, simple, easy to follow.

As a long time developer, I just want to suggest a small change.

An Issue is any unit of work that should take 4-8 hours of engineering effort. An Issue is either in the current sprint or in the backlog.

The previous bullet point mentions reducing context switching. If a developer does an issue every 4-8 hours over the course of 15 work days ( 3 weeks ). That is roughly 20 issues in the ideal sprint.

My suggestion is similar to what basecamp has published as how they work here: https://m.signalvnoise.com/how-we-structure-our-work-and-teams-at-basecamp/

Rather than filling the sprint in 4-8 hour tasks I would propose organizing issues as fully complete "deliverable" features. That is instead of breaking down the login system into small tasks. I would recommend simply making one issue that encompasses the whole system. If it takes more than 3 weeks it can be broken up. However, I would keep from breaking issues too small.

This way each developer can focus on 1 or maybe 2 issues a sprint.

I would also like to add that the end of the issue should be that it is released into production for all users. Currently, on my team, we have the issue where the work may be done, but deployments are still on hold which causes lots more issues and requires we contain that context for sometimes weeks.

So my rough draft change could be something like...

An Issue is any unit of work that is delivered to all users that can be completed within the sprint. An Issue is either in the current sprint or in the backlog.

Note that this would be changed in both the developer and manager pages it was referenced in.

Let me know if you have any questions or comments. Thank you.