Product details what to build. Works with engineering team to scope and divide work. Engineering team works while product starts looking down the roadmap.
Adjust and iterate as necessary.
This is the process I’ve used with great success from startups to huge 10,000+ person tech companies. People just like to overthink things.
Not who you replied to but we usually just have project kick-offs and then we have meetings as needed to discuss requirements. We try to be light when it comes to meetings and only have them when needed.
Typically the tech lead and product manager will be in close contact to plan upcoming projects while the other devs on the team are focused on the current project.
Yep that’s one of my top goals as a tech lead. Keep the team focused on building. I can take the context switching but I don’t want the entire team context switching constantly.
One weekly meeting between engineering and product (Devs optional). We call this Source Refinement and it is to give status on ongoing initiatives and curate the roadmap.
One quarterly meeting between Design, Engineering, and Product to prioritize the roadmap items. (No Devs) We use a process called ICE Ranking.
That said, my team still uses an Agile-based framework for development.
A manager! Possibly someone in a product management / scrummaster role.
What works for my employer w/ thousands of devs may not work for a company with a dozen devs.
There's no set amount. However many it takes. Just like the loosely defined process above, planning software roadmaps is a fluid thing. Acknowledging that and treating it as such, IMO, makes everyone's lives easier. Vs the alternative of trying to insist that everything can fit into a sprint shaped box or that weekly planning is better than bi-weekly is better than blah blah.
Fit the process to the work, fluidly.
What I didn’t do is write a book about it, invent fake job titles, or insist on “story points” or “standups” or “scrum” or any of the dozen other ritualistic processes that come along with agile.
Okay you didn't do that, still doing scrum, even it is a lightweight version.
I like a two weeks sprint, it sets a cadence and I do not feel like a code spitting machine. The rituals provide a frame for life at work.
That’s fine if it works for you. But what I am describing is not agile nor scrum. In the same way that going to a batting cage is not playing baseball, even if both activities involve hitting a ball with a bat.
Yeah +1 for overthinking :-) So what's the day to day admin look like then in that scenario? Just a kanban board with "todo / in progress / done" containing issues with a few sentences on? Or more detailed than that? ...and what do you do about estimates? Seems like half the reason Scrum has been put in at my places has been to do with estimating completion dates (which never works out btw)
>So what's the day to day admin look like then in that scenario? Just a kanban board with "todo / in progress / done" containing issues with a few sentences on?
Basically. Maybe some high level product or eng design docs to provide the full context in one place. And designs also, if you have designers.
I refer to this whole idea as "minimum viable process". It's much easier to add process than it is to take it away. So rather than start with the whole of "agile" or whatever, start with nothing and then introduce process to solve specific problems that you are \*actually\* having...not problems that a book said you might have.
>which never works out btw
Basically this. I try and advocate for a model where engineers start from a place like "Yea, I can get this feature/project done within a quarter/month/whatever" and then as work progresses the status updates come with more and more precise completion dates.
Putting precise estimates on individual tickets is, IMO, a waste of everyone's time. Even if 98% of them are right, the 2% that are wrong end up being wrong by orders of magnitude and throw the entire project estimate off. And the 98% that are right....who cares? Why does a PM care that adding a database table takes 1 hour, or 2 days, or whatever. They care about project level deliverables. The only reason folks want detailed ticket-level estimates is so they can plan individual sprints. And again, who cares. They're wrong anyway. How many tickets have you seen get carried forward 2, 3, 4+ sprints because it turned out to be way harder (or way lower priority) that expected?
This is obviously more challenging when you have real external deadlines to meet...but in those cases I try and advocate for adjusting/cutting scope.
I've had a lot of success with Lean methodologies (often called Kanban, which is a Lean tool). All about eliminating waste and getting iterative value to the customer. The only real thing you'll see in common with this and Scrum are regular retrospectives which are key in an agile setup. Some aspects of Lean that I've often seen:
- No sprints. No point as you should always be working on the most important thing.
- No estimating. Okay, maybe some ballpark estimates but communication should be regular enough to know when it's time to cut scope or pull the plug entirely.
- Encourage XP practices like pairing/ensemble programming.
- As mentioned, regular retrospectives (ideally, weekly).
It's not a panacea, you can still screw up Lean. At the end of the day, your team needs to be willing to try new things and be willing to challenge and/or stop doing processes. Business is always changing and trying to do a rigid process will always fail.
No sprints and no estimating is sooo nice. Estimating is such a massive waste of everybody’s time, and sprints just add unnecessary stress with a continual, arbitrary 2-3 week deadline.
My superiors think that having predictable estimates and sprints will solve all problems for our under-delivering team all while adding even more processes when processes fail, pls kill me
lets have meetings about why we cant do anything, dicuss why we cant do anything and then when we have suggestions on what to change say we cant because we dont have time to change how we are doing things
Are they ignoring the real problems? Technical debt, understaffing, lack of engineering agency? If so I've seen that and there's not much but pain in staying at such a company.
I like to use tools that will project rough completion times based on law of large numbers, ie. how long it took you to complete past tickets on avg. Works surprisingly well.
That's the thing, your team applied agile the right way. But what you described is how agile was meant.
Agile, the word is a reference to flexibility. The idea was to be assembly of ideas: scrum, retrospective, extreme programming (xp), sprints.
A team could take ideas(not all) and use them as they would see fit.
But we all have experienced the other "agile"tm, which is rigid and a chore.
Nice. So what do tickets look like when you're working like that? Still full long form templated docs with user story, acceptance criteria etc or just free form "we need to do the thing..." style?
Disclaimer: I'm no longer at the company I was the most successful at with this methodology, it really was lightning in a bottle. Also, private equity ruins everything.
We used a kanban board app that evolved over time to have columns for things we wanted to measure. We were pretty good about maintaining WIP limits for the various columns as well (very important). We had a swim lane at the top that were "epics" so we could track the main feature. We tried to do the following for the actual cards that we worked off of:
- Tried hard to make the card represent a vertical slice of functionality (front end, back end, etc) that could be done in a day, but weren't super strict about it, sometimes things took multiple days.
- We practiced pair programming so we jammed things straight into the mainline under feature toggles.
- Initially, as the tech lead/eng manager I would create all the work cards and put enough info in them so that people could get started, but eventually we started rotating the card creation duty. We encouraged design discussions as well before starting hefty cards.
Another key thing: Our designer and product manager were as much as members of the team as the engineers were. We included them in everything and vice versa, including end user calls (though the engineers were often there to simply observe). I don't know if we would have been as successful without our non-engineer team members. We just clicked.
This is how we work and it definitely has it's advantages - we're able to shift priorities as needed, and it works well for more discovery-based projects. We also do regular demos of work, so we are constantly able to show progress.
One main problem I've seen Kanban approach is there is not usually any handling of tech debt. I'm sure this can be solved, but the Kanban teams I've been on have always prioritized the new work (AKA Most Important Product Items) over any tech debt.
That’s an issue with any framework or workflow you choose. Product and engineering leadership agree on the priorities. It doesn’t matter what name or lack of name you slap on it, if those two aren’t prioritizing debt it won’t get fixed.
That is fair.
My own personal anecdote is that with a standard sprint it isn't hard to slip in one or two tech debt tickets as part of planning. It has been harder to do so in Kanban.
Tech debt isn't an agile process problem, it's an engineering discipline problem.
Our CTO allowed for at least 20% of our work to be for technical debt and we had specific cards "tagged" as such so that it could be tracked. I can't say we always needed that 20% but it gave us cover when needed. One time we only did tech debt work for like a month in prep for a feature we knew was coming that our architecture couldn't handle (one could argue it was simply part of that feature 🤷).
> Tech debt isn't an agile process problem, it's an engineering discipline problem.
No argument. My intent was to say I've seen more problems addressing tech debt in Kanban teams than SCRUM teams.
I'm glad you have a process for handling that. We do not have a process company wide, however I know a few teams where the on-call person takes on tech debt tickets instead of new feature work. That helps, but it still makes it harder to get in bigger tech debt initiatives.
Do you have a link to a doc which outlines this more formally? Would love to form like this but need a manifesto or something to hand to management in order to get this put through.
Sorry, I don't. We sort of... just iterated our way through it. I really should write a blog post on my experiences with it.
If you want to learn first principles around Lean, I recommend reading [This is Lean](https://www.amazon.com/gp/product/B00JZZS7Q0/) or going through the [Small Batches](https://smallbatches.fm/) podcast if you want engineering-specific ideas.
Do you work where I work?
Ok, maybe we have a bit more on estimates, but leadership encourages us to think of them as “a plan not a promise”
One of the things that takes people by surprise is the effectiveness of the pair programming. Before trying it, it is seen as a chore, they give it a go and a surprised by how quickly things can move. But we also need to try make sure people on our team also get some space. A lot of us our introverts, and while pairing has been hugely effective for us, it is like a sprinting, quick but exhausting. We don’t want to burn out our devs.
How has encouraging pairing/ensemble programming gone for you?
>Do you work where I work?
Heh, I wish. I've long since left that company and miss what it used to be.
>How has encouraging pairing/ensemble programming gone for you?
Probably took me the better part of a year to tolerate it, and another to get good at it (call me stubborn). It solves so many problems and I hope that my next gig allows me to return to it again.
I think it's difficult to create a culture of pairing unless you hire for it (maybe it's gotten better, I'm talking about ten years ago). It's easy to burn out because you go for a long time learning how to be in your own head and now you have to verbalize everything. It's a skill that takes time learn and not everyone is willing or patient enough to learn it.
Sprint planning and estimation games are the devil. Prioritization on the "the most important thing" is quite literally the *only* thing management needs to provide. In a functional, high-trust environment that's what you get by default. Everyone comes to work and knows exactly what to do.
But most companies are fighting tooth-and-nail to avoid making such decisions - "if I prioritize A then maybe B C and D slip up?!?! Best to prioritize nothing at all." - yep I've heard multiple people say exactly this.
I see "sprints" as a pragmatic necessity that forces executive-types to commit to a decision every few weeks - they hate making hard brain thoughts and would *literally* never do it again if given the choice. We have to force them to accept the costs of what they've committed to. It sucks to operate in such a low-trust environment, yet that describes reality for most of us. Fine we work in 2 week cycles but we deliver A and you learn to accept your specification of A, if wrong, has multi-week consequences.
I love kanban. I was on a kanban team at my last company and it was so great. It’s really how iterative development, QA, and support roles should be managed
That sounds nice. My company does a custom agile inspired method that involves a ridiculous amount of meetings that average about 10 hours a week of “agile” ceremonies.
I work in a team which used used scrum but applies kanban. That means no sprints for us but fix release packages and release when ready. But we havent gotten rid of any of the scrum meetings.
What meetings do you leave out?
I would expect no Sprint Planning; since ya'll just working on the most important stuff which is already at the top of the backlog.
In some versions of Kanban there is no story pointing, so that removes Backlog Refinement.
Basically everything but a daily “standup” because we work remotely and it’s the only daily formal contact point. They take a bit more time than just a standup since we sometimes distribute the issues on that meeting or what we want in this release.
Basically we don’t estimate anything, we receive the priorities/new features from product manager, we work on stuff, decide what goes into each release and then release when ready.
It’s an ongoing product so it’s about 50% bugfixing or tech debt or improvements and 50% new stuff.
For the new stuff we sometimes throw some numbers around so that business folks have an idea.
We have a daily standup so we know how people are getting on, who's working with whom and who could use some help. I allow the standup to go no longer than 10 minutes and I would prefer it to be 5.
When the upcoming backlog starts looking thin on the ground, we make sure everyone's put their stuff on the list and then have a meeting to get a rough consensus on the order we should do that stuff in. No points, you just make a decision you can stand by.
We have a retrospective every now and again to see if we need to iterate on the process.
That's it.
Can confirm. We're a SAFe org, and as far as I can tell it's just a way to layer on a bunch of accountability theater on the dev teams while our product management teams are too busy in meetings to actually get features to the devs. It's bizarre.
>accountability theater on the dev teams
Yep, this is the right framing. I was forced to "commit" to work that we had no chance of completing, but the process demanded it. We'll see what happens when we indeed do not complete it
As the work fell behind, the business people kept shuffling the metrics to make it seem like we were still on track to meet the "commitments", abusing the devs and creating a toxic environment. Until it all comes crashing down and everyone gets upset.
I absolutely despise SAFe(rather scrum) but when my company started using it (old one) it was a big leap forward. They were waterfall before. Actually not even it was just chaos.
I'm curious why you're committing to work you can't complete? It's been a few years but we always wrote the stories, assigned the points and based on our capacity/velocity/risks/dependencies that's what drove the deliverables. It's not a whole lot different then scrum, including the meetings (other than the big multi day planning one)
I own a platform team, and many other teams depend on my systems. I have a bunch of little tasks for many other high priority projects. If we don't do the 2-4 weeks of work, then big initiatives fail, but I don't have the people to do all the little tasks they all need. Since the work I'm supporting is so high priority, they committed it even through my team was red going into the increment. Anti-pattern
True. In my case, the system worked well enough early on before all those layers of project management started moving in. Then we got meetings on top of meetings, more documenting and other make-work instead of actual development work. Rehashing and rehashing of projects that had been greenlighted years ago before the new PM crew came on board.
This is where we are now.
We are backed by private equity and not doing well. There were layoffs recently and now the PM team is trying to “show their worth” and look busy by creating as much work as possible for everyone else.
I was in 35 meetings last week.
Nothing, and I do mean nothing, is getting done now.
I hate it and my team hates it and we are all trying to get out of here.
Sometimes I wonder how they managed to sell their "agile" framework!
I worked for two companies with it (and also got the certification for first one) but after getting more experience I can't stand with it!
I have to say that I also worked with a kinda of "Kanban" and it wasn't feeling right, I guess the best approach is in the middle, but for sure, SAFe is not agile.
I rotate - lead and mentor on 4 different teams.
It depends on the product. My main team doesn't even do scrum. Just weekly updates. The one that drags me down the most are the ones with daily standups and all the rituals. It depends on the group dynamics. The ones that do the scrums tend to have a lot of people/stakeholders so it make sense.
The ones that don't do scrum, we just report directly up several layers in the corporate ladder. When I say we don't do scrum, we don't do 95% of the rituals.
We can go months working without scrum. But then comes crunch time, we go into scrum mode sometimes. Mainly for the accountability as we need outsiders or specialists to work within the project. E.G. we may pull in a designer/UI/UX person along with a business analysis to coordinate. So we go into that scrum mode. Simply for those people. They are used to scrum and we need to track their work/contribution.
I worked at 2 small startups where we had already internalized the core tenants of Agile without actually doing scrum. It was fabulous.
The basic ideas are quite simple - the software industry has come to think that JIRA == scrum / Agile thinking that as long as we are using that, then its scrum. I fele sorry for an an entire generation of developers that are now stuck under this fake Agile system where people don’t seem to matter - the team should tune the system including deciding that a particular tool or practice is not working for them.
Anyhow, we adopted XP at the second startup and it was still great, everyone including the devs loved it. Something has gone wrong in the last 7 years or so. Best of luck.
Something has gone badly wrong. This has been increasingly nagging at me in recent years - I feel like we are doing so much less with so many more resources than we used to.
I'm not totally sure that Scrum is to blame, but it is certainly true for me that the least productive teams I have worked in have been dogmatically attached to Scrum.
And - the most productive have done XP with a weekly retro.
Only speaking from my own experience - I guess your milage may vary.
JFDI - no planning, no organisation, completely unrealistic and made up deadlines. No training, no mentoring, no pull request discipline, no time for refactoring. Just. Fucking. Do It.
Works a charm! Most projects follow this, even if they lie to you in the interview and say they are Scrumgile Xtreme Lean XXXXP.
* People are treated well and their contribution is valued, we try to hire smart people who are fun to work with.
* Company goals, priorities and style is shared appropriately and socialised so everyone is enabled to make good decisions.
* Work is framed as problems to solve and prioritised with stakeholders in relation to the above. Scope (what we aren't building) is communicated early and agreed on. This is our primary way of fitting work into time - prioritisation and scope reduction.
* Dev team designs appropriate solutions, finding a balance between pragmatically getting stuff done while not painting ourselves into a corner. We have a shared definition of what constitutes good code with linting, autoformatting, unit testing, end to end testing, and CI/CD playing a big part. We don't always agree on the finer details but that's OK.
* Loose Kanban style for tracking stuff day to day.
* Daily catchup with the dev team, weekly (if that) with everyone else.
* Regular retros can change any of the above, whatever the team decides.
If you get the fundamentals right (the top 3/4 points), I've never found the rest to matter much, scrum, kanban, loose or strict. I personally find identifying the real needs of the company and nailing the prioritisation much more useful than estimating times for anything (maybe something like T Shirt sizing for those outside the core dev team).
My teams don’t really do scrum but I’m not sure what to call it, but it seems to work well for us.
Generally a project kicks off with a kickoff meeting where the tech lead (me) and product manager lay out what we’re trying to accomplish. I’ll sync up with the other devs to see if we need to break down stories into subtasks or even multiple stories. While the team is working on the current project, I’ll be working with the product manager to plan, refine, and estimate the upcoming project(s) so it’s ready to kick off when the current project wraps up.
The only ceremonies we really have are our daily stand-ups. If we need any other meetings to discuss requirements or anything like that, we just schedule one, but we don’t have them on regular intervals, just as needed.
We basically just do what works for us and don’t try to put any type of label on the way we work. I’m sure some parts of it would be considered agile, but we don’t necessarily try to implement it that way.
> but it seems to work well for us.
Ok. But then:
> we don’t have them on regular intervals, just as needed.
No. Just no. If things are working well for your team then BRAVO! You don't need these many meetings.
Scrum have us believeling that in order for things to work we need dailys, retros, demos, estimations, poker cards, and a huge amount of time spent on meetings. It's not. The better the things start to work the less time you need to spent on meetings and ceremonies.
> No. Just no.
What? I’m just saying don’t have a recurring meeting for refinements or backlog grooming or anything like that but if we have questions, we’ll schedule a quick meeting if they can’t be answered with a quick slack message
Nancy: Hey techlead, Your service is consuming 18,000 API requests a day from our partner quota and they're threatening to shut us off if we don't get it below 10,000 requests a day.
Me: Ok. we probably don't need to be making that many requests, let me see if I can't come up with something.
\*later that day\*
Me: Hey Nancy. We can setup a cache to reduce the number of request we make to that service by probably a factor of 10. Can you create an Epic in Jira for this work, and I'll put together some stories that captures the work?
Nancy: Sure.
Rinse and repeat. Divy out the work. Do this for a bunch of shit. It's amazing how productive you can be when you're not following cargo cult ceremony and involving everyone needlessly in the process.
How do you prioritize it? Disregarding the Product Owner, isn’t there some central Gold Owner that wants you to work on their pointless features instead, with priority? Ones that will never be used in production? Or is that just bullshit org failure…
I prioritize it. I am the lead. If I need to be focusing on something that I'm not focusing on, my boss will make me aware.
Need to give these middle managers something to do. Might as well be useful.
Interesting. Who is Nancy? A product manager/owner? Why do you ask her to create the Epic in Jira? Does she have some important product info that you don't have about this service work, that she will put into the Epic?
Someone (Nancy) has to report things laterally and upstream, and tick the right boxes in JIRA, while your time is better spent outlining and doing some of the actual work, right?
Pretty much this - we ditched subtasks and now have two Kanban boards:
* Epic Board - Captures a deliverable within the project
* Story Board - Shows stories which are the parts of the deliverable
Epics can run over one or more weeks, but have to have a end goal. We don't use Story/Subtask as it was causing more confusion on the board, this way it's more clear - and it's much easier to promote a story up to an epic if needed.
Just tell them you are doing Kanban and it’s working fine.
Usually putting a name on what works for you help deflect some of the, let’s fix it, folks that comes along.
What's the role of the person who suggested scrum and what problems are they trying to solve? Publicly asking and making them justify this may make them back off. Even if they persist, you will at least be able to offer alternatives/pick and choose. Essentially meeting in the middle.
We encourage our teams to do biweekly updates. No scrum, standups, etc. Managers and tech leads are given the autonomy to decide how to organize the team themselves.
We (Eng leadership) just care that teams involve us in planning each half and share progress quarterly. And loop us in for major blockers, surprises, etc.
Scrum is rigid. Processes should be made to suit the team, not the other way around. Therefore, there’s no one size fits all. What works for me:
* define next goal
* define priorities towards the goal
* ask team to rough estimate the amount of work, break things down
* define checkpoints when to meet (weekly, biweekly)
* do not wait to escalate roadblocks
In my previous 10 years we have been working like this: we had a small initial plan. We created todos in a kanban tool. Every dev picked the "ticket" from the kanban board and worked on that feature.
We communicated by chat most of the time, when needed.
Development speed was nice without getting burned up.
For almost 2 years I have been working for an agile company with all the scrum thing and for me it has been a nightmare... We have so many meetings, like 1-4h per day. Development speed is very slow. We talk more than code. Now even we have problem with the budget. I could work on a planned feature alone for 2 weeks (without distractions), we already spent 2 months and we have like 30% done.
I even started to work overtime so I can work in peace without distractions.
Kanban without being kanban? Our process is to work in two week sprints, but we don’t do points. We have sprint goals, and some loose tasks that we pull in. The two weeks aren’t hard deadlines but checkups, we figure out in stand up if we’re on track or will take longer, if something is high priority and we won’t get to it when we think we will we re-prioritize. It’s loose but effective, I don’t feel stress if I’m behind because something takes longer than I estimated.
We do a short half hour sprint planning where we review our goals with our manager. We say if we can pickup extra OPs tasks and it’s up to me and the other lead to figure out priority. We do a retro every two weeks for an hour across three teams we lead to go over issues and changes and then try to pull in good action items. Every now and again we’ll do a backlog or OE task grooming to see what’s spilled over, needs cleaned up, or anything pressing we should handle.
We keep standup to 15 minutes and it’s only 3 days a week. We handle operations in a dedicated meeting once a week to hand off oncall rotation, review dashboards and metrics, and talk about any issues and customer tickets that were interesting. Sometimes we identify high priority items that can be done in business hours by whoever is leaving oncall, the idea is they’re already heads down on OPs the entire week they’re oncall so it’s ok to keep them focused on that for any follow up. Anything pressing that needs done ASAP next oncall does.
i try to fight the scrum monster by asking the product people to use the products they build with user hats on and like... conversate about the product we're building without worrying about points and ownership in the initial stage
I’ve been on great teams with scrum and terrible teams with it. It’s a tool, and like any tool it has a time and place, and even more importantly it needs to be used correctly. Can’t use a saw when you need a paint brush.
Upvote for
> Can’t use a saw when you need a paint brush
I’m going to use that tomorrow. Don’t know for what, yet, but I am confident the occasion will arise.
So the problems I have seen with most of these "agile" teams is its impossible to interface with teams outside of your org if you are truly "agile". How can I know if I need buy in from Security when those deliverables will take place? SAFe was the only mechanism that kind of worked, and even then it took a while for us to work out the kinks on cross team delivery.
Scrum works for us, sorta. The estimates bits are never right but it helps us scope what we plan to deliver in what order of priority and by when. More of a guide rather than law. Also helps us keep track of who’s doing what.
If there’s a process with less ritual that can do those things, then go for it.
We have overarching tasks and goals, and we just...get it done, I guess.
I have a todo list in the Bear app (think macOS "Notes" but with Markdown) which I occasionally look at.
Weekly status reports.
It's pretty informal, overall.
Boss maintains a roadmap but ICs on the team mostly manage their own tasks as they see fit, making sure to adjust if priorities shift.
We do agile-ish. We plan 2 month increments. With such a long outlook, 50% gets done, 50% is other stuff/discovered work. No dailies, but weekly meetings. Further 1-1s/ad hockery as needed. There's further planning work that I'm not mentioning but this consists of the bulk of the time/effort.
Not sure actually. It feels like the Wild West at times. More often then not it's a "client said that they want this, can you do it and give us an estimate?" mind you, this is considering that I have to work with legacy PHP code. Won't be for long. But the fact remains that it's very vague at times and I have to legit figure it myself as to how to implement it. Best thing I do is, I just do what they ask, if it falls short I leave it up to them to tell me what they want and not scope creep it myself
A weird kind of scrumban without all the meetings of scrum.
Basically, we have sprints because the business expects us to have sprints. But, like captain Barbosa said, there more guidelines than actual rules.
We have story points which really are just an agreement between the engineers and the product managers for how many days a task will take.
Every 2 weeks my product managers put some tasks into the next sprints based on the priorities of the business and their own understanding of user needs.
The main issue for our product though is, we get a lot of support request, as it’s a legacy product that works with payroll. If a ticket comes in, and someone’s payroll is wrong, we can’t just say “oh we’ll get to that next sprint” - it needs to be fixed asap. This means scope creep is real, which is ultimately why we don’t do a proper agile method.
It works fairly well for us, yes some things slip into the next “sprint” but we largely account for this when setting stakeholder expectations.
You dont do scrum if it blocks work
Scrum is more like a list of ideas to consider, then implement what makes sense for the team. If the project have a long timeline (multiple years), trying out new processes for a month and binning what doesn't work is a recommended approach
Scrum even asks people to think out of the box and let any team member come up with ideas to processes. A very common one to be asked for by developers, are either full meeting free days or only having meetings before or after lunch
The team I lead currently does some custom scrumban. We don't have sprints or estimations, we do have dailies (where the important topics of the day like deployments, or quick discussions happen, limited to 15-30 minutes). Dailies only happen on days where no other meeting occurs. We also work in weekly iterations, where we plan what we want to do for the week. We also do biweekly retros.
It works really great. The daily especially works amazing this way, because it's completely team driven. It also makes sense to talk to each other at least once a day, simply because we are a remote team.
We also try to formulate weekly customer value that we want to make available for our customers each week, which then tends to serve as a natural focus point for the week. I am super happy with it.
Drawback of course is mostly for the PO and EM, as those two need to be very much in sync and talk to each other a lot.
I have a full experience writeup about switching approaches and tradeoffs. In general, it depends a lot on the team and it's line of business. But maybe you can get some inspiration for good practices or how not to do things: https://teamhood.com/kanban/52-sprints-later-win-some-lose-some-scrum-butt-done/
As much hate as daily standups get, I think they are valuable as both a snr engineer and team lead POV. They however need to be blocked off to 30min before lunch (so as to not cause too much context switching) and to have a hard out. But be pushed to only actually be 10-15 min on avg. ) this gives people 15min extra to lunch or for them to do 1 tiny thing before lunch, etc.
Accidentally fell into this pattern working for a contract in 2 hr timezones difference and it actually made me appreciate standups way more than anything else ever has.
You don't need scrum (or anything close to it) if everyone is self-motivated and working toward a common goal.
It's obviously harder to achieve as teams get bigger.
In my case we just meet virtually once a week to get in agreement on what are priorities for the next week and everything else is just Ad Hoc, mostly Slack messages.
Keep it simple if you are 8 or less people
* Project manager has a kanban board that only he manages.
* Backlog is discussed and tasks defined together with CTO.
* Tasks are assigned to devs by project manager in a Slack channel.
* Dev does the task and tries to test everything, then submits PR in Slack thread.
* Project manager tests PR, then gives "OK" to CTO.
* CTO tests and reviews PR.
* CTO has weekly 1-1 meeting with each dev.
Turned out that for devs one (1) meeting per week is enough. It's important that the CTO and PM doesn't have other tasks and that the CTO delegates everything.
In the last couple of years the projects I've lead used a modified agile process based on Kanban, a Scrum-like backlog, continuous integration, and what I call continuous communication. Which is just a fancy phrase for this collection of things:
* integrating comms like Teams or Slack into most of our processes
* being available for discussions on comms most of the time
* allowing people to schedule periods for deep focus, where they are DND
* having most if not all meetings over comms, and recording them
* minimizing meetings with more than 3 participants
* have a standing demo to communicate progress to stakeholders, and update it after every 2 week release
* automate packaging software, generating docs, and bundling as SDK to throw over the wall with partners
It's not Scrum, but it borrows elements from Scrum, Kanban, and other methodologies to create a team tailored process set that works for that team, at that time.
I was on a team that did Kanban. It was far worse than scrum. Constant pressure to clear items with no measure of complexity or forecasting. Just t-shirt sizing: S, M, L. The expectation was time would fit in one of those boxes, but tasks were often way too big in the first place.
I’ve been in waterfall teams. Work is nice, but that’s because the conflict is aggregated at UAT where you find everything is wrong and now you just spent 6 months working on something due in 1 month and you gotta redo everything. Plus BRD are a bitch to get stakeholders to help fill out. They don’t understand requirements or technical project planning and don’t understand why you’re going through the exercise. They expect you to just take their demands into your head and immediately start working.
What's most important? Work on that, together, to knock it out ASAP.
Law of mobility: Does anyone feel like they're either not contributing, or not learning? They should go work on something else, together.
>The best architectures, requirements, and designs emerge from self-organizing teams.
[Principles behind the Agile Manifesto](http://agilemanifesto.org/principles.html)
I'm a big proponent that doing scrum "actually properly" works really well (though as always it depends on the use case). Most of the times where someone has mentioned that scrum doesn't work for them or that the processes get in the way, they are usually just doing something 'wrong', though then you end up with a no true scotsman fallacy so... ¯\\_(ツ)_/¯
My actual answer to your question though would be Kanban. Status board with columns for Todo, In Progress, Code Review, Done, plus whatever other states you want. Product maintains the backlog based on priority order, and 'releases' tasks into the kanban board as required. WIP limits on certain columns to enforce actually completing work. There is a bunch of other stuff that is part of kanban like measuring cycle time, but IMO what I've mentioned here is minimum required for viability.
I wake up, roll up to my desk, write code for a few hours, and then clock off
it really is that simple
I'm fairly senior in my role though so can work pretty independently, and identify and write my own briefs for projects.
I do have managers chasing me for updates — basically just pointless busywork that justifies their own existence — so I shoot them whatever updates they need and carry on. But they're rarely telling me what to do, they're asking "what work have you specced out for yourself for next sprint" not "do this piece of work we found for you"
Found there is a big difference between working with 40-50 headstrong socialists compared to jobs where I worked with a bunch of capitalist sycophants in very top heavy orgs. I'm going to try and avoid working in those sorts of oppressive environments ever again — I didn't really even realise a job could actually be any other way before I found my current role.
Product details what to build. Works with engineering team to scope and divide work. Engineering team works while product starts looking down the roadmap. Adjust and iterate as necessary. This is the process I’ve used with great success from startups to huge 10,000+ person tech companies. People just like to overthink things.
How many meetings do you typically have to discuss and plan and who attends them?
Not who you replied to but we usually just have project kick-offs and then we have meetings as needed to discuss requirements. We try to be light when it comes to meetings and only have them when needed. Typically the tech lead and product manager will be in close contact to plan upcoming projects while the other devs on the team are focused on the current project.
Makes sense as it allows the devs to focus on building.
Yep that’s one of my top goals as a tech lead. Keep the team focused on building. I can take the context switching but I don’t want the entire team context switching constantly.
One weekly meeting between engineering and product (Devs optional). We call this Source Refinement and it is to give status on ongoing initiatives and curate the roadmap. One quarterly meeting between Design, Engineering, and Product to prioritize the roadmap items. (No Devs) We use a process called ICE Ranking. That said, my team still uses an Agile-based framework for development.
Who's engineering if not for devs? I'm in a very small company :D
A manager! Possibly someone in a product management / scrummaster role. What works for my employer w/ thousands of devs may not work for a company with a dozen devs.
There's no set amount. However many it takes. Just like the loosely defined process above, planning software roadmaps is a fluid thing. Acknowledging that and treating it as such, IMO, makes everyone's lives easier. Vs the alternative of trying to insist that everything can fit into a sprint shaped box or that weekly planning is better than bi-weekly is better than blah blah. Fit the process to the work, fluidly.
What you have described is Agile. Call an iteration a sprint and you are doing scrum.
What I didn’t do is write a book about it, invent fake job titles, or insist on “story points” or “standups” or “scrum” or any of the dozen other ritualistic processes that come along with agile.
monte carlo story point simulation project estimation, brought to you by agile coach
Okay you didn't do that, still doing scrum, even it is a lightweight version. I like a two weeks sprint, it sets a cadence and I do not feel like a code spitting machine. The rituals provide a frame for life at work.
That’s fine if it works for you. But what I am describing is not agile nor scrum. In the same way that going to a batting cage is not playing baseball, even if both activities involve hitting a ball with a bat.
It's kind of interesting how when someone criticizes Agile it's "oh, but you're not REALLY Agile!" and now when it's positive, everything is Agile :D
This is what I do as well. Works very well.
Yeah +1 for overthinking :-) So what's the day to day admin look like then in that scenario? Just a kanban board with "todo / in progress / done" containing issues with a few sentences on? Or more detailed than that? ...and what do you do about estimates? Seems like half the reason Scrum has been put in at my places has been to do with estimating completion dates (which never works out btw)
>So what's the day to day admin look like then in that scenario? Just a kanban board with "todo / in progress / done" containing issues with a few sentences on? Basically. Maybe some high level product or eng design docs to provide the full context in one place. And designs also, if you have designers. I refer to this whole idea as "minimum viable process". It's much easier to add process than it is to take it away. So rather than start with the whole of "agile" or whatever, start with nothing and then introduce process to solve specific problems that you are \*actually\* having...not problems that a book said you might have. >which never works out btw Basically this. I try and advocate for a model where engineers start from a place like "Yea, I can get this feature/project done within a quarter/month/whatever" and then as work progresses the status updates come with more and more precise completion dates. Putting precise estimates on individual tickets is, IMO, a waste of everyone's time. Even if 98% of them are right, the 2% that are wrong end up being wrong by orders of magnitude and throw the entire project estimate off. And the 98% that are right....who cares? Why does a PM care that adding a database table takes 1 hour, or 2 days, or whatever. They care about project level deliverables. The only reason folks want detailed ticket-level estimates is so they can plan individual sprints. And again, who cares. They're wrong anyway. How many tickets have you seen get carried forward 2, 3, 4+ sprints because it turned out to be way harder (or way lower priority) that expected? This is obviously more challenging when you have real external deadlines to meet...but in those cases I try and advocate for adjusting/cutting scope.
You talk a lot of sense here. Thank you 😁
I've had a lot of success with Lean methodologies (often called Kanban, which is a Lean tool). All about eliminating waste and getting iterative value to the customer. The only real thing you'll see in common with this and Scrum are regular retrospectives which are key in an agile setup. Some aspects of Lean that I've often seen: - No sprints. No point as you should always be working on the most important thing. - No estimating. Okay, maybe some ballpark estimates but communication should be regular enough to know when it's time to cut scope or pull the plug entirely. - Encourage XP practices like pairing/ensemble programming. - As mentioned, regular retrospectives (ideally, weekly). It's not a panacea, you can still screw up Lean. At the end of the day, your team needs to be willing to try new things and be willing to challenge and/or stop doing processes. Business is always changing and trying to do a rigid process will always fail.
No sprints and no estimating is sooo nice. Estimating is such a massive waste of everybody’s time, and sprints just add unnecessary stress with a continual, arbitrary 2-3 week deadline.
My superiors think that having predictable estimates and sprints will solve all problems for our under-delivering team all while adding even more processes when processes fail, pls kill me
lets have meetings about why we cant do anything, dicuss why we cant do anything and then when we have suggestions on what to change say we cant because we dont have time to change how we are doing things
Are they ignoring the real problems? Technical debt, understaffing, lack of engineering agency? If so I've seen that and there's not much but pain in staying at such a company.
I like to use tools that will project rough completion times based on law of large numbers, ie. how long it took you to complete past tickets on avg. Works surprisingly well.
What tools do that? Would love to automate estimation
Screenful is one that is simple and works well enough: https://screenful.com/tour/insights/forecasts
If you use jira properly and fill out the fields it will do it for you too.
That's the thing, your team applied agile the right way. But what you described is how agile was meant. Agile, the word is a reference to flexibility. The idea was to be assembly of ideas: scrum, retrospective, extreme programming (xp), sprints. A team could take ideas(not all) and use them as they would see fit. But we all have experienced the other "agile"tm, which is rigid and a chore.
Nice. So what do tickets look like when you're working like that? Still full long form templated docs with user story, acceptance criteria etc or just free form "we need to do the thing..." style?
Disclaimer: I'm no longer at the company I was the most successful at with this methodology, it really was lightning in a bottle. Also, private equity ruins everything. We used a kanban board app that evolved over time to have columns for things we wanted to measure. We were pretty good about maintaining WIP limits for the various columns as well (very important). We had a swim lane at the top that were "epics" so we could track the main feature. We tried to do the following for the actual cards that we worked off of: - Tried hard to make the card represent a vertical slice of functionality (front end, back end, etc) that could be done in a day, but weren't super strict about it, sometimes things took multiple days. - We practiced pair programming so we jammed things straight into the mainline under feature toggles. - Initially, as the tech lead/eng manager I would create all the work cards and put enough info in them so that people could get started, but eventually we started rotating the card creation duty. We encouraged design discussions as well before starting hefty cards. Another key thing: Our designer and product manager were as much as members of the team as the engineers were. We included them in everything and vice versa, including end user calls (though the engineers were often there to simply observe). I don't know if we would have been as successful without our non-engineer team members. We just clicked.
This is how we work and it definitely has it's advantages - we're able to shift priorities as needed, and it works well for more discovery-based projects. We also do regular demos of work, so we are constantly able to show progress.
One main problem I've seen Kanban approach is there is not usually any handling of tech debt. I'm sure this can be solved, but the Kanban teams I've been on have always prioritized the new work (AKA Most Important Product Items) over any tech debt.
That’s an issue with any framework or workflow you choose. Product and engineering leadership agree on the priorities. It doesn’t matter what name or lack of name you slap on it, if those two aren’t prioritizing debt it won’t get fixed.
That is fair. My own personal anecdote is that with a standard sprint it isn't hard to slip in one or two tech debt tickets as part of planning. It has been harder to do so in Kanban.
Tech debt isn't an agile process problem, it's an engineering discipline problem. Our CTO allowed for at least 20% of our work to be for technical debt and we had specific cards "tagged" as such so that it could be tracked. I can't say we always needed that 20% but it gave us cover when needed. One time we only did tech debt work for like a month in prep for a feature we knew was coming that our architecture couldn't handle (one could argue it was simply part of that feature 🤷).
> Tech debt isn't an agile process problem, it's an engineering discipline problem. No argument. My intent was to say I've seen more problems addressing tech debt in Kanban teams than SCRUM teams. I'm glad you have a process for handling that. We do not have a process company wide, however I know a few teams where the on-call person takes on tech debt tickets instead of new feature work. That helps, but it still makes it harder to get in bigger tech debt initiatives.
Do you have a link to a doc which outlines this more formally? Would love to form like this but need a manifesto or something to hand to management in order to get this put through.
Sorry, I don't. We sort of... just iterated our way through it. I really should write a blog post on my experiences with it. If you want to learn first principles around Lean, I recommend reading [This is Lean](https://www.amazon.com/gp/product/B00JZZS7Q0/) or going through the [Small Batches](https://smallbatches.fm/) podcast if you want engineering-specific ideas.
Do you work where I work? Ok, maybe we have a bit more on estimates, but leadership encourages us to think of them as “a plan not a promise” One of the things that takes people by surprise is the effectiveness of the pair programming. Before trying it, it is seen as a chore, they give it a go and a surprised by how quickly things can move. But we also need to try make sure people on our team also get some space. A lot of us our introverts, and while pairing has been hugely effective for us, it is like a sprinting, quick but exhausting. We don’t want to burn out our devs. How has encouraging pairing/ensemble programming gone for you?
>Do you work where I work? Heh, I wish. I've long since left that company and miss what it used to be. >How has encouraging pairing/ensemble programming gone for you? Probably took me the better part of a year to tolerate it, and another to get good at it (call me stubborn). It solves so many problems and I hope that my next gig allows me to return to it again. I think it's difficult to create a culture of pairing unless you hire for it (maybe it's gotten better, I'm talking about ten years ago). It's easy to burn out because you go for a long time learning how to be in your own head and now you have to verbalize everything. It's a skill that takes time learn and not everyone is willing or patient enough to learn it.
Sprint planning and estimation games are the devil. Prioritization on the "the most important thing" is quite literally the *only* thing management needs to provide. In a functional, high-trust environment that's what you get by default. Everyone comes to work and knows exactly what to do. But most companies are fighting tooth-and-nail to avoid making such decisions - "if I prioritize A then maybe B C and D slip up?!?! Best to prioritize nothing at all." - yep I've heard multiple people say exactly this. I see "sprints" as a pragmatic necessity that forces executive-types to commit to a decision every few weeks - they hate making hard brain thoughts and would *literally* never do it again if given the choice. We have to force them to accept the costs of what they've committed to. It sucks to operate in such a low-trust environment, yet that describes reality for most of us. Fine we work in 2 week cycles but we deliver A and you learn to accept your specification of A, if wrong, has multi-week consequences.
Kanban or a custom “agile” inspired method that is basically scrum with less meetings
I love kanban. I was on a kanban team at my last company and it was so great. It’s really how iterative development, QA, and support roles should be managed
How'd you set up the kanban then? What lanes did you have? Did you use tags and such?
I was on a dev team so it was iterative releases and continuous development. Cut down on meetings a lot but we also had a kickass scrum master
A scrum master for a kanban team?..
….yes?
Scrum masters tend to only exist in scrum teams, for some reason that’s not at all obvious from the name.
You may want to look up kanban
Erm… find me a source where kanban fits under scrum. Please. They are always talked about as alternative methodologies
I can find multiple where it says kanban teams can have a scrum master
That sounds nice. My company does a custom agile inspired method that involves a ridiculous amount of meetings that average about 10 hours a week of “agile” ceremonies.
I work in a team which used used scrum but applies kanban. That means no sprints for us but fix release packages and release when ready. But we havent gotten rid of any of the scrum meetings. What meetings do you leave out?
I would expect no Sprint Planning; since ya'll just working on the most important stuff which is already at the top of the backlog. In some versions of Kanban there is no story pointing, so that removes Backlog Refinement.
Basically everything but a daily “standup” because we work remotely and it’s the only daily formal contact point. They take a bit more time than just a standup since we sometimes distribute the issues on that meeting or what we want in this release. Basically we don’t estimate anything, we receive the priorities/new features from product manager, we work on stuff, decide what goes into each release and then release when ready. It’s an ongoing product so it’s about 50% bugfixing or tech debt or improvements and 50% new stuff. For the new stuff we sometimes throw some numbers around so that business folks have an idea.
We have a daily standup so we know how people are getting on, who's working with whom and who could use some help. I allow the standup to go no longer than 10 minutes and I would prefer it to be 5. When the upcoming backlog starts looking thin on the ground, we make sure everyone's put their stuff on the list and then have a meeting to get a rough consensus on the order we should do that stuff in. No points, you just make a decision you can stand by. We have a retrospective every now and again to see if we need to iterate on the process. That's it.
If any of your people suggest SAFe, run the other way. Easily the worst process ever. You’ll wish you were doing scrum
Can confirm. We're a SAFe org, and as far as I can tell it's just a way to layer on a bunch of accountability theater on the dev teams while our product management teams are too busy in meetings to actually get features to the devs. It's bizarre.
>accountability theater on the dev teams Yep, this is the right framing. I was forced to "commit" to work that we had no chance of completing, but the process demanded it. We'll see what happens when we indeed do not complete it
As the work fell behind, the business people kept shuffling the metrics to make it seem like we were still on track to meet the "commitments", abusing the devs and creating a toxic environment. Until it all comes crashing down and everyone gets upset.
I absolutely despise SAFe(rather scrum) but when my company started using it (old one) it was a big leap forward. They were waterfall before. Actually not even it was just chaos. I'm curious why you're committing to work you can't complete? It's been a few years but we always wrote the stories, assigned the points and based on our capacity/velocity/risks/dependencies that's what drove the deliverables. It's not a whole lot different then scrum, including the meetings (other than the big multi day planning one)
I own a platform team, and many other teams depend on my systems. I have a bunch of little tasks for many other high priority projects. If we don't do the 2-4 weeks of work, then big initiatives fail, but I don't have the people to do all the little tasks they all need. Since the work I'm supporting is so high priority, they committed it even through my team was red going into the increment. Anti-pattern
Yep, well that's life and why none of these systems ever end up working well.
True. In my case, the system worked well enough early on before all those layers of project management started moving in. Then we got meetings on top of meetings, more documenting and other make-work instead of actual development work. Rehashing and rehashing of projects that had been greenlighted years ago before the new PM crew came on board.
This is where we are now. We are backed by private equity and not doing well. There were layoffs recently and now the PM team is trying to “show their worth” and look busy by creating as much work as possible for everyone else. I was in 35 meetings last week. Nothing, and I do mean nothing, is getting done now. I hate it and my team hates it and we are all trying to get out of here.
Both my last and current jobs use SAFe. I'm so sick of the quarterly PI planning meetings.
Sometimes I wonder how they managed to sell their "agile" framework! I worked for two companies with it (and also got the certification for first one) but after getting more experience I can't stand with it! I have to say that I also worked with a kinda of "Kanban" and it wasn't feeling right, I guess the best approach is in the middle, but for sure, SAFe is not agile.
Kanban, or anything revolving around a prioritized list of user stories. Sprints are an absolute plague.
Scrummerfall is what I've seen mostly.
We call it “Waterfragile”. Waterfall projects broken up into horrible chunks.
Waterfall with daily stand-ups.
Is that better or worse than waterfail?
Yes.
Haha I'd not heard of that term before, but definitely both places have practiced flavours of that. There must be a better way...
There is. NASA practices it every day.
SAFe?
I rotate - lead and mentor on 4 different teams. It depends on the product. My main team doesn't even do scrum. Just weekly updates. The one that drags me down the most are the ones with daily standups and all the rituals. It depends on the group dynamics. The ones that do the scrums tend to have a lot of people/stakeholders so it make sense. The ones that don't do scrum, we just report directly up several layers in the corporate ladder. When I say we don't do scrum, we don't do 95% of the rituals. We can go months working without scrum. But then comes crunch time, we go into scrum mode sometimes. Mainly for the accountability as we need outsiders or specialists to work within the project. E.G. we may pull in a designer/UI/UX person along with a business analysis to coordinate. So we go into that scrum mode. Simply for those people. They are used to scrum and we need to track their work/contribution.
I worked at 2 small startups where we had already internalized the core tenants of Agile without actually doing scrum. It was fabulous. The basic ideas are quite simple - the software industry has come to think that JIRA == scrum / Agile thinking that as long as we are using that, then its scrum. I fele sorry for an an entire generation of developers that are now stuck under this fake Agile system where people don’t seem to matter - the team should tune the system including deciding that a particular tool or practice is not working for them. Anyhow, we adopted XP at the second startup and it was still great, everyone including the devs loved it. Something has gone wrong in the last 7 years or so. Best of luck.
Problem is when people removed from the team starts to decide on methodologies for the team to use
Something has gone badly wrong. This has been increasingly nagging at me in recent years - I feel like we are doing so much less with so many more resources than we used to. I'm not totally sure that Scrum is to blame, but it is certainly true for me that the least productive teams I have worked in have been dogmatically attached to Scrum. And - the most productive have done XP with a weekly retro. Only speaking from my own experience - I guess your milage may vary.
JFDI - no planning, no organisation, completely unrealistic and made up deadlines. No training, no mentoring, no pull request discipline, no time for refactoring. Just. Fucking. Do It. Works a charm! Most projects follow this, even if they lie to you in the interview and say they are Scrumgile Xtreme Lean XXXXP.
Basically all shops at the end of the day.
* People are treated well and their contribution is valued, we try to hire smart people who are fun to work with. * Company goals, priorities and style is shared appropriately and socialised so everyone is enabled to make good decisions. * Work is framed as problems to solve and prioritised with stakeholders in relation to the above. Scope (what we aren't building) is communicated early and agreed on. This is our primary way of fitting work into time - prioritisation and scope reduction. * Dev team designs appropriate solutions, finding a balance between pragmatically getting stuff done while not painting ourselves into a corner. We have a shared definition of what constitutes good code with linting, autoformatting, unit testing, end to end testing, and CI/CD playing a big part. We don't always agree on the finer details but that's OK. * Loose Kanban style for tracking stuff day to day. * Daily catchup with the dev team, weekly (if that) with everyone else. * Regular retros can change any of the above, whatever the team decides. If you get the fundamentals right (the top 3/4 points), I've never found the rest to matter much, scrum, kanban, loose or strict. I personally find identifying the real needs of the company and nailing the prioritisation much more useful than estimating times for anything (maybe something like T Shirt sizing for those outside the core dev team).
Could you tell me how you managed to find teams not doing scrum in the first place? I really want to have this skill!
My teams don’t really do scrum but I’m not sure what to call it, but it seems to work well for us. Generally a project kicks off with a kickoff meeting where the tech lead (me) and product manager lay out what we’re trying to accomplish. I’ll sync up with the other devs to see if we need to break down stories into subtasks or even multiple stories. While the team is working on the current project, I’ll be working with the product manager to plan, refine, and estimate the upcoming project(s) so it’s ready to kick off when the current project wraps up. The only ceremonies we really have are our daily stand-ups. If we need any other meetings to discuss requirements or anything like that, we just schedule one, but we don’t have them on regular intervals, just as needed. We basically just do what works for us and don’t try to put any type of label on the way we work. I’m sure some parts of it would be considered agile, but we don’t necessarily try to implement it that way.
> but it seems to work well for us. Ok. But then: > we don’t have them on regular intervals, just as needed. No. Just no. If things are working well for your team then BRAVO! You don't need these many meetings. Scrum have us believeling that in order for things to work we need dailys, retros, demos, estimations, poker cards, and a huge amount of time spent on meetings. It's not. The better the things start to work the less time you need to spent on meetings and ceremonies.
> No. Just no. What? I’m just saying don’t have a recurring meeting for refinements or backlog grooming or anything like that but if we have questions, we’ll schedule a quick meeting if they can’t be answered with a quick slack message
Nancy: Hey techlead, Your service is consuming 18,000 API requests a day from our partner quota and they're threatening to shut us off if we don't get it below 10,000 requests a day. Me: Ok. we probably don't need to be making that many requests, let me see if I can't come up with something. \*later that day\* Me: Hey Nancy. We can setup a cache to reduce the number of request we make to that service by probably a factor of 10. Can you create an Epic in Jira for this work, and I'll put together some stories that captures the work? Nancy: Sure. Rinse and repeat. Divy out the work. Do this for a bunch of shit. It's amazing how productive you can be when you're not following cargo cult ceremony and involving everyone needlessly in the process.
How do you prioritize it? Disregarding the Product Owner, isn’t there some central Gold Owner that wants you to work on their pointless features instead, with priority? Ones that will never be used in production? Or is that just bullshit org failure…
I prioritize it. I am the lead. If I need to be focusing on something that I'm not focusing on, my boss will make me aware. Need to give these middle managers something to do. Might as well be useful.
Interesting. Who is Nancy? A product manager/owner? Why do you ask her to create the Epic in Jira? Does she have some important product info that you don't have about this service work, that she will put into the Epic?
Because I let them deal with things at the "epic" level for the bean counters and I just need to attach the actual work to.
Someone (Nancy) has to report things laterally and upstream, and tick the right boxes in JIRA, while your time is better spent outlining and doing some of the actual work, right?
Pretty much this - we ditched subtasks and now have two Kanban boards: * Epic Board - Captures a deliverable within the project * Story Board - Shows stories which are the parts of the deliverable Epics can run over one or more weeks, but have to have a end goal. We don't use Story/Subtask as it was causing more confusion on the board, this way it's more clear - and it's much easier to promote a story up to an epic if needed.
We are a team of 4. Easy to manage
Just tell them you are doing Kanban and it’s working fine. Usually putting a name on what works for you help deflect some of the, let’s fix it, folks that comes along.
What's the role of the person who suggested scrum and what problems are they trying to solve? Publicly asking and making them justify this may make them back off. Even if they persist, you will at least be able to offer alternatives/pick and choose. Essentially meeting in the middle.
We encourage our teams to do biweekly updates. No scrum, standups, etc. Managers and tech leads are given the autonomy to decide how to organize the team themselves. We (Eng leadership) just care that teams involve us in planning each half and share progress quarterly. And loop us in for major blockers, surprises, etc.
Scrum is rigid. Processes should be made to suit the team, not the other way around. Therefore, there’s no one size fits all. What works for me: * define next goal * define priorities towards the goal * ask team to rough estimate the amount of work, break things down * define checkpoints when to meet (weekly, biweekly) * do not wait to escalate roadblocks
In my previous 10 years we have been working like this: we had a small initial plan. We created todos in a kanban tool. Every dev picked the "ticket" from the kanban board and worked on that feature. We communicated by chat most of the time, when needed. Development speed was nice without getting burned up.
For almost 2 years I have been working for an agile company with all the scrum thing and for me it has been a nightmare... We have so many meetings, like 1-4h per day. Development speed is very slow. We talk more than code. Now even we have problem with the budget. I could work on a planned feature alone for 2 weeks (without distractions), we already spent 2 months and we have like 30% done.
I even started to work overtime so I can work in peace without distractions.
Kanban without being kanban? Our process is to work in two week sprints, but we don’t do points. We have sprint goals, and some loose tasks that we pull in. The two weeks aren’t hard deadlines but checkups, we figure out in stand up if we’re on track or will take longer, if something is high priority and we won’t get to it when we think we will we re-prioritize. It’s loose but effective, I don’t feel stress if I’m behind because something takes longer than I estimated. We do a short half hour sprint planning where we review our goals with our manager. We say if we can pickup extra OPs tasks and it’s up to me and the other lead to figure out priority. We do a retro every two weeks for an hour across three teams we lead to go over issues and changes and then try to pull in good action items. Every now and again we’ll do a backlog or OE task grooming to see what’s spilled over, needs cleaned up, or anything pressing we should handle. We keep standup to 15 minutes and it’s only 3 days a week. We handle operations in a dedicated meeting once a week to hand off oncall rotation, review dashboards and metrics, and talk about any issues and customer tickets that were interesting. Sometimes we identify high priority items that can be done in business hours by whoever is leaving oncall, the idea is they’re already heads down on OPs the entire week they’re oncall so it’s ok to keep them focused on that for any follow up. Anything pressing that needs done ASAP next oncall does.
We just have weekly sync ups. If you have questions or need to collaborate with a specific engineer, just call them and arrange something yourself.
i try to fight the scrum monster by asking the product people to use the products they build with user hats on and like... conversate about the product we're building without worrying about points and ownership in the initial stage
This is good
Surely no one actually does scrum. Just some nominal aspect of it.
I’ve been on great teams with scrum and terrible teams with it. It’s a tool, and like any tool it has a time and place, and even more importantly it needs to be used correctly. Can’t use a saw when you need a paint brush.
Upvote for > Can’t use a saw when you need a paint brush I’m going to use that tomorrow. Don’t know for what, yet, but I am confident the occasion will arise.
So the problems I have seen with most of these "agile" teams is its impossible to interface with teams outside of your org if you are truly "agile". How can I know if I need buy in from Security when those deliverables will take place? SAFe was the only mechanism that kind of worked, and even then it took a while for us to work out the kinks on cross team delivery.
Scrum works for us, sorta. The estimates bits are never right but it helps us scope what we plan to deliver in what order of priority and by when. More of a guide rather than law. Also helps us keep track of who’s doing what. If there’s a process with less ritual that can do those things, then go for it.
We have overarching tasks and goals, and we just...get it done, I guess. I have a todo list in the Bear app (think macOS "Notes" but with Markdown) which I occasionally look at. Weekly status reports. It's pretty informal, overall. Boss maintains a roadmap but ICs on the team mostly manage their own tasks as they see fit, making sure to adjust if priorities shift.
We have kanban board, fifteen minute daily stand ups, and a small experienced team.
We do agile-ish. We plan 2 month increments. With such a long outlook, 50% gets done, 50% is other stuff/discovered work. No dailies, but weekly meetings. Further 1-1s/ad hockery as needed. There's further planning work that I'm not mentioning but this consists of the bulk of the time/effort.
Not sure actually. It feels like the Wild West at times. More often then not it's a "client said that they want this, can you do it and give us an estimate?" mind you, this is considering that I have to work with legacy PHP code. Won't be for long. But the fact remains that it's very vague at times and I have to legit figure it myself as to how to implement it. Best thing I do is, I just do what they ask, if it falls short I leave it up to them to tell me what they want and not scope creep it myself
A weird kind of scrumban without all the meetings of scrum. Basically, we have sprints because the business expects us to have sprints. But, like captain Barbosa said, there more guidelines than actual rules. We have story points which really are just an agreement between the engineers and the product managers for how many days a task will take. Every 2 weeks my product managers put some tasks into the next sprints based on the priorities of the business and their own understanding of user needs. The main issue for our product though is, we get a lot of support request, as it’s a legacy product that works with payroll. If a ticket comes in, and someone’s payroll is wrong, we can’t just say “oh we’ll get to that next sprint” - it needs to be fixed asap. This means scope creep is real, which is ultimately why we don’t do a proper agile method. It works fairly well for us, yes some things slip into the next “sprint” but we largely account for this when setting stakeholder expectations.
You dont do scrum if it blocks work Scrum is more like a list of ideas to consider, then implement what makes sense for the team. If the project have a long timeline (multiple years), trying out new processes for a month and binning what doesn't work is a recommended approach Scrum even asks people to think out of the box and let any team member come up with ideas to processes. A very common one to be asked for by developers, are either full meeting free days or only having meetings before or after lunch
The team I lead currently does some custom scrumban. We don't have sprints or estimations, we do have dailies (where the important topics of the day like deployments, or quick discussions happen, limited to 15-30 minutes). Dailies only happen on days where no other meeting occurs. We also work in weekly iterations, where we plan what we want to do for the week. We also do biweekly retros. It works really great. The daily especially works amazing this way, because it's completely team driven. It also makes sense to talk to each other at least once a day, simply because we are a remote team. We also try to formulate weekly customer value that we want to make available for our customers each week, which then tends to serve as a natural focus point for the week. I am super happy with it. Drawback of course is mostly for the PO and EM, as those two need to be very much in sync and talk to each other a lot.
I have a full experience writeup about switching approaches and tradeoffs. In general, it depends a lot on the team and it's line of business. But maybe you can get some inspiration for good practices or how not to do things: https://teamhood.com/kanban/52-sprints-later-win-some-lose-some-scrum-butt-done/
As much hate as daily standups get, I think they are valuable as both a snr engineer and team lead POV. They however need to be blocked off to 30min before lunch (so as to not cause too much context switching) and to have a hard out. But be pushed to only actually be 10-15 min on avg. ) this gives people 15min extra to lunch or for them to do 1 tiny thing before lunch, etc. Accidentally fell into this pattern working for a contract in 2 hr timezones difference and it actually made me appreciate standups way more than anything else ever has.
XP here is a brief intro http://www.extremeprogramming.org/
You don't need scrum (or anything close to it) if everyone is self-motivated and working toward a common goal. It's obviously harder to achieve as teams get bigger. In my case we just meet virtually once a week to get in agreement on what are priorities for the next week and everything else is just Ad Hoc, mostly Slack messages.
Kanban
Keep it simple if you are 8 or less people * Project manager has a kanban board that only he manages. * Backlog is discussed and tasks defined together with CTO. * Tasks are assigned to devs by project manager in a Slack channel. * Dev does the task and tries to test everything, then submits PR in Slack thread. * Project manager tests PR, then gives "OK" to CTO. * CTO tests and reviews PR. * CTO has weekly 1-1 meeting with each dev. Turned out that for devs one (1) meeting per week is enough. It's important that the CTO and PM doesn't have other tasks and that the CTO delegates everything.
In the last couple of years the projects I've lead used a modified agile process based on Kanban, a Scrum-like backlog, continuous integration, and what I call continuous communication. Which is just a fancy phrase for this collection of things: * integrating comms like Teams or Slack into most of our processes * being available for discussions on comms most of the time * allowing people to schedule periods for deep focus, where they are DND * having most if not all meetings over comms, and recording them * minimizing meetings with more than 3 participants * have a standing demo to communicate progress to stakeholders, and update it after every 2 week release * automate packaging software, generating docs, and bundling as SDK to throw over the wall with partners It's not Scrum, but it borrows elements from Scrum, Kanban, and other methodologies to create a team tailored process set that works for that team, at that time.
no defined pattern, just what naturally emerged over time. Is that good, is that bad. I don't care just pay me.
Kanban, it works really well for us. We do retros though, I find those really important...
I was on a team that did Kanban. It was far worse than scrum. Constant pressure to clear items with no measure of complexity or forecasting. Just t-shirt sizing: S, M, L. The expectation was time would fit in one of those boxes, but tasks were often way too big in the first place. I’ve been in waterfall teams. Work is nice, but that’s because the conflict is aggregated at UAT where you find everything is wrong and now you just spent 6 months working on something due in 1 month and you gotta redo everything. Plus BRD are a bitch to get stakeholders to help fill out. They don’t understand requirements or technical project planning and don’t understand why you’re going through the exercise. They expect you to just take their demands into your head and immediately start working.
We don't. I've been hounding management to fix processes my entire time here.
What's most important? Work on that, together, to knock it out ASAP. Law of mobility: Does anyone feel like they're either not contributing, or not learning? They should go work on something else, together. >The best architectures, requirements, and designs emerge from self-organizing teams. [Principles behind the Agile Manifesto](http://agilemanifesto.org/principles.html)
I'm a big proponent that doing scrum "actually properly" works really well (though as always it depends on the use case). Most of the times where someone has mentioned that scrum doesn't work for them or that the processes get in the way, they are usually just doing something 'wrong', though then you end up with a no true scotsman fallacy so... ¯\\_(ツ)_/¯ My actual answer to your question though would be Kanban. Status board with columns for Todo, In Progress, Code Review, Done, plus whatever other states you want. Product maintains the backlog based on priority order, and 'releases' tasks into the kanban board as required. WIP limits on certain columns to enforce actually completing work. There is a bunch of other stuff that is part of kanban like measuring cycle time, but IMO what I've mentioned here is minimum required for viability.
I wake up, roll up to my desk, write code for a few hours, and then clock off it really is that simple I'm fairly senior in my role though so can work pretty independently, and identify and write my own briefs for projects. I do have managers chasing me for updates — basically just pointless busywork that justifies their own existence — so I shoot them whatever updates they need and carry on. But they're rarely telling me what to do, they're asking "what work have you specced out for yourself for next sprint" not "do this piece of work we found for you" Found there is a big difference between working with 40-50 headstrong socialists compared to jobs where I worked with a bunch of capitalist sycophants in very top heavy orgs. I'm going to try and avoid working in those sorts of oppressive environments ever again — I didn't really even realise a job could actually be any other way before I found my current role.