Canada, US, Europe (Canada HQ)

Lightweight, practical, works reasonably well. We used to have issues with large projects that didn't fit into a single project and needed an 'umbrella project' to keep track of the larger picture. That was fixed recently with a new GSD release and Vault upgrade introducing the 'Mission' concept that can contain multiple subprojects.

The 6 week cycle planning concept has been around for a while at Shopify and works okay, but still all lives in Google spreadsheets. Perhaps with tooling in the Vault this process could be less tedious and spot resourcing issues easier. Tools are never done :)

Every project is free to do standups, 'full' Scrum, or something else during the day to day. Whatever works. Project commitments are planned in cycles of 6 weeks. Non-senior ICs can lead projects too, if appropriate for the scope. The only requirement is that every project timeline, its progress updates, etc is tracked on an internal tool called 'The Vault'. This tool uses the GSD (Get Shit Done) framework which describes certain roles and expectations, project phases, rituals, and GSD creates a ubiquitous project management language across the company without introducing too much overhead. The ex-CTO created a demo after questions on Twitter here a year ago: https://vimeo.com/456735890

Pro: flexibility of planning and time for ‘other’ planned work such as code health, operational excellence. Allows for easy shuffle of resources within the team.
Con: goals can change mid-project, making some projects go off the table half-way through. Also planned work that just keeps on being pushed over, and never gets picked up

Clearer and more consistent high level goals

T-shirt sizing, which seem hard to do for DS/research tasks. Would prefer it if all work is done using priority queues.

US, Europe (US HQ)

There's a high cost to getting things wrong when managing people's data, so iterative up front design thinking builds confidence in doing the right thing the right way, plus communicates to downstream teams what changes are coming and allows input before the work is done.

Too much design creeps into the scope documents.

Short scope document (goals, non goals, risks, assumptions) signed off by product mgmt and eng mgmt chain, followed by design doc (spec/RFC), spec is decomposed to tickets, work the tickets, then ship. BUT, design is generally iterative with feedback from a design review team, coding often starts before the design is done, and the design is rarely locked. Teams have their own methodology for ticket scheduling; some teams demo completed work to stakeholders before everything is done (though this is rarely for feedback; more to show progress). Sometimes, a product description is provided by product mgmt to drive scope doc at the start. There is a project manager on teams that supports the lead in driving the process. Leads are often a role that mixes tech lead and first-level EM, but some projects have senior/staff engineers in the project lead role.

Best thing I can think of is the PO can explain the PM why the task should take more time. Worst thing some time they spend to much time discuss on schedule at the end the engineers need to work hard to match the schedule.

Levels of management, old tools and technologies, faster build process

I like that there are a push for projects that benefits business and developers from upper management. Projects pushed by upper management usually gets done.

I feel that this leads to a lack of cultivation for lower ranks engineers to propose and push their projects. This has resulted in senior and newcomer developers having many overlapped roles and too few promotions into principal engineers.

I would put more energy into grooming engineers to principal engineers/ software architect. Have them handle these projects and put someone who has gone through such projects to guide them. As they grow, I want to ensure they have the high level skills instead of mere implementation skills

Top down. Projects are usually proposed by upper management and engineers are to think about how to get it done. Only internal projects are proposed by engineers themselves. Internal projects are more focused on developer experience but sometimes are about scalability.

Most of our upper management engineering managers are engineers themselves so their proposed projects are doable. Sometimes they get involved in the architecture planning and all too.

They recommend Scrum or Kanban, but it's up to the team / PM.

Each team have 1 tech lead and 1 product manager. Sometimes PM presents new features and controls backlog, sometimes just presents the new feature and it's up to the team to control the backlog. There are no scrum masters or agile coaches anymore with the teams (I don't even know what they are doing right now...)

Biggest pain point requirements changing constantly and lack of visibility from the stakeholders

Get the actual problem drilled down before just running off to engineering team and start building

Get all stakeholders on same page

Nothing to like. Tech teams cornered with the requirement to gather quarterly and estimate how much they can commit to deliver within the next three month.

I'd let teams decide how and what they need to do to achieve the goals with whatever cadence of releasing value increments.

Venture-Funded Scaleups (Series B & Above)

We call it iterations in our team, is a variation of Scrum, but we intentionally don't want to associate to an existing agile framework.

I am in charge, and we change it to fit the team's needs. We have intense retrospectives.

Since our work (Machine Learning/Data) has a high level of uncertainty and we're working in platform team (not a product) we can adopt Kanban because we're more concerned about flow (throughput, mean time to recover, limits in WIP) than in sprints or metrics like velocity, burn charts.

I would revisit all projects and adapt some parts of Kanban to replace the product-centric + team based approach to a model Fit-to-Purpose + Service/Platform approach in terms of management.

A Team Lead, typically a senior engineer with strong interpersonal skills. Tech Leads can also be on the team, but that's not a given. They are usually even more senior, but prefer focussing on the actual project at hand over management tasks, like Hiring Management, performance reviews & designing rituals.

Autonomy, each team has different domain and/or style engineers so a different flow can sometimes work better. The big problem is syncing best practices / learnings in based on rituals.

Get learnings from each team, and provide a handbook of clearly explained setups to pick from.

Each team has complete autonomy on how they run their rituals. OKRs are defined on the company level. Streams define OKRs based on that. Team define OKRs on those Stream OKRs.

The company follows the "every team is a startup" model. Quote:

"Everyone at {Company} is part of a team of between four and eight people. That’s big enough to make things happen, but small enough to keep the startup magic alive and keep {Company} moving forward.

Of course, all our teams are part of {Company}, and have to stay aligned with our company’s purpose, values, and standards. But they are autonomous and free to make their own decisions, experiment and get results however works best.

Each {Company} team operates like a mini company with its own vision, its own targets, goals and P&L, and its members acting like startup founders. Teams are fully accountable for creating and delivering value to their customers – internal or external – and to {Company}."

"There are three key roles at {Company}. The most common is Team Member: the people who deliver results by doing a great job driving the business forward. There are also Competence Leads (CL): responsible for ensuring their competence reports develop professionally and deliver high–quality work. The third is Accountable Leads (AL): The team leaders that drive daily work, push the teams forward and are responsible for overall delivery.

Your Accountable Lead is the person you report to about your team’s day-to-day work. They’re where you go for feedback or to ask questions about your assignment. Your Competence Lead is your go-to-person to develop your skills. Competence Leads ensures high–quality work, and supports you if you need training or skill development, and they help you in your professional development."

"A group of teams can form a Domain working on similar topics like Consumer App, Merchant Foundations or Financial Steering. It’s best if each Domain works in the same location – and even when Domains are split between different locations there should be at least four teams from the same Domain sitting together to bounce ideas, share problems and find new solutions. There’s no obligation to form a Domain if your problem space is small.

Every Domain is responsible for part of {Company}'s overall strategy and vision. It has a Domain Lead who is responsible for all its teams, and who coordinates the Domain’s Accountable Leads.

Large and complex Domains have dedicated Domain Support teams. They exist to perform consistent, specific tasks or solve problems that are not covered by the Domain’s teams."

Depends on the team. In my group I make sure that we rotate this role around per project and support people with clear expectations

Add some starter kits for new teams to pick and adapt

Teams can choose their processes. We value iterative collaboration between product, engineering and design, and have a good bar for product docs, design explorations, and peer-reviewed engineering design docs to align people and de-risk big projects before we start building. We balance long term vision with getting there incrementally, pragmatism, knowing when incrementalism won’t cut to make big bets, and so on. Engineers typically run projects, with PMs helping keep them honest.

Series E, Commercial Real Estate + Tech

Best: eng get full end-to-end ownership of large projects, contribute to product decisions, relatively little "project management" work has to happen bc most projects are owned by one person
Pain points: requires most people to have expertise across the stack; people sometimes want to work more closely with others than this permits

Like: High flexibility to define our own milestones and projects can be executed independently.

Pain: no standard way to measure of we are doing good or bad in terms of shipping cadence

Use kanban all the way, sinc its more flexible

US, Europe, Australia

The lean approach is imho the best. Biggest pain point is to follow by metrics our development

I would remove quarterly commitments, which may not allow faster changes.

I like that is facilitates deep thinking on every single project, and doing most of the thinking within a design doc leads to better designs than going straight into the code, or splitting the work into "tickets" too quickly.

It also really helps when working remotely and across timezones. Collaborators can work together within the design doc itself, which reduces the need for meetings or "syncs" to get everyone onto the same page. The thinking is not ephemeral, lost in a Zoom call or Slack thread, is it preserved somewhat permanently in the design doc.

The main downside I can think of is that everyone on your team needs to enjoy reading docs, and needs to be a fast typist. If someone is implementing code from a design doc and misses key details because they only skim read it, that can be frustrating.

At the foundation of each project is a design doc. These are not huge documents intended to persuade a committee towards a course of action (which is what "design doc" seems to mean at larger tech companies), but a single place to collect all the thoughts and context for a particular project. Engineers will reference the design doc while working, and modify it as needed. Once the project is over, the design doc stays behind as s reference for anyone who is curious about a past decision.

Design docs live in a document collaboration tool (we use Quip), and are visible to everyone at the company.

The top of the design doc is usually written by the PM. This section describes the root goal of the project, and usually includes an argument for why this project is important to the company (including screenshots of graphs/metrics). Then there is a section for the technical design, in which the engineer who owns the project (could be the tech lead or someone else), writes out the irreversible design decisions that are being taken as part of the implementation (e.g. are we adding any new database columns, any new infra, modifying an external API etc.). The technical design is reviewed by another senior engineer before the coding starts.

Sometimes design docs have todo lists in them which helps engineers keep track of their work, and others keep track of how much progress has been made on the project, and how much is remaining.

it gives the rythm and prodtects the team from ad-hoc requests from stakeholder. The biggest pain point is planing - not all the things fit into the sprint naturally

Some product managers don't have the necessary technical knowledge and think too short term.

I would like to have some kind of product owner/user representative embedded within a team. Only being contacted when stuff breaks is a bit annoying.

I’d spend less time moving boxes around and more time figuring out the most important things to build first; more time talking to clients and less time on administrivia.

Collectively drive, but mostly Technical Project Managers who are think they are leading by tracking status of Jira tickets

Sound Technical practices will eliminate many problems we keep trying to solve with “project management”. I’m talking about the absence of a 15 minute loop for most of our services. No unit tests no system tests no intermediary tests. With git flow and coupled distributed systems. No amount of project management can resolve the dysfunction. And of course give teams problems to solve and let them organize not shove down project management processes and features to build.

Sound Technical practices will eliminate many problems we keep trying to solve with “project management”. I’m talking about the absence of a 15 minute loop for most of our services. No unit tests no system tests no intermediary tests. With git flow and coupled distributed systems. No amount of project management can resolve the dysfunction. And of course give teams problems to solve and let them organize not shove down project management processes and features to build.

It's highly effective and once the team adapts to it it's super efficient. Haven't found a pain point yet tbh

Tend to not require much management, but I (CEO) is the default lead in practice.

Probably closest to Michael Seibels development cycles

We should probably get better at prioritizing bugs vs new development.

We don’t consider anything we do as projects. But we have overarching topics that we focus on that usually takes weeks to months. Every week starts with discussing what we are going to learn about and ship this week. We have a retro every Friday. Each deliverable is an item on a board.

Officially every team uses scrum (the company is big on conformity), but my team just tries to do what works for us and make it look like enough like scrum that nobody meddles (wouldn't be surprised if other teams do the same, although from what I can see it really does look like more typical scrum)

Pros:
- Good communication, so that everybody basically knows what everybody else in the project is doing, without needing to rely heavily on tools/Jira. Makes it feel as though we're working together (which everybody on the team likes), makes the project more resilient to people going on leave / getting sick, and generally just shares knowledge around the team.
- Opportunities to do "bits-and-pieces" work, because otherwise there would rarely be a chance for folks to work on what *they* think is important (there's a very deep rabbit hole here...).
- Nobody telling everybody exactly which task to work on (unless they actually need guidance), which gives people a smidgen of autonomy and ownership
- Dynamic nature of the process means it's quite adaptable.
- Gives other folks on the team chances to lead projects, and get a taste of technical leadership and project management.

Cons:
- Don't really have any product manager closely integrated into the day-to-day work. At the moment the C-suite are effectively the PMs, and they're not involved in the day-to-day at all.
- Have a less of a top-down feature treadmill (churn out as many sexy features as we can, as requested by the top), with more of the translation from user problem into feature happening closer to the ground

- Product is highly technical, and C-suite are experts in the field but have zero software / product / business experience.
- TL gets some type of high level feature request from C-suite. Size-wise, there's a big range, but typically these projects will take between 1 week and 2 months.
- TL works with eng team to figure out who will "lead" the project (often this is the TL, but sometimes somebody else is keen for the opportunity)
- We make a new Slack channel for the project to discuss all day-to-day work
- Nominated lead runs a video discussion with the whole eng team to figure out what specifically we'll build, and determine a set of milestones that we need to hit to call the feature "done". We always try to take the smallest possible step that will satisfy the requirements. These milestones aren't set in stone, we'll adapt them mid-project if we learn something new.
- Depending on what the rest of the team is working on and the specifics of the project, the sub-team for the project will end up being anywhere between about 2-5 people. Other people on the team might join the project later if their other work finishes up.
- Through discussion on Slack / ad-hoc video meetings we produce a bunch of Jira tickets for the work to be done for the project.
- Work work work, with lots of discussion on Slack and in ad-hoc meetings when necessary.
- Throughout this process the TL + project lead will try to nudge people back on course if they seem to be going down rabbit holes, and the TL will give regular status updates to the C-suite about how things are going.
- Fortnightly "sprint planning" meeting (related to the fake scrum I mentioned above), where we really just check in amongst the whole team about how the different projects are going
- Ship throughout: if there are intermediate steps at which it makes sense to release something, we'll release it straight away.
- As we approach the end and work dries up, so that we have more people than we can fit on the available work, people will either move onto a different project that's at a different stage of this lifecycle, or occasionally pick up "bits-and-pieces" work that they think is important to improve the product.
- When the team is at a point where there are too few ongoing projects for the number of people, we'll kick off the process again with the next feature (which, again, comes from the C-suite)

There’s no “best practice” dogma and we can tailor to fit our company. No overhead managing sprints or estimating story sizes.

As a tool, Basecamp isn’t ideal for managing tasks and doesn’t give great visibility into the progress of a project. We’re always open to changing processes when needed, typically 1-2/year—another benefit of not being wedded to dogma

Vague question but they’re managed through Basecamp task lists typically with two devs working on it, collaborating with a designer, and one dev designated as the champion for reporting progress. There are weekly checkins, and the champion provides an estimated ship date and confidence %. No deadlines

The loose framework allows us to fit our approach to each project and we generally lean towards using the minimum amount of process to keep things organized, which I like. I think the biggest pain point is that some poor designs make it through because our process can be loose and we only occasionally have dedicated review of the Architectural Plans.

I dont know that I would change much; maybe more deliberate reviews of Architectural Plans but there can be a context problem with that so there's diminishing returns.

Our general approach to projects is Think it -> Build it -> Ship it -> Tweak it or essentially Plan, Build, Ship. Anyone on the team can 'own' or lead projects and often they are owned by the entire team if the project is large or complex. The Think it stage generally results in an Architectural Plan, which has no required format across teams. A project will usually be divided into phases and may have several ships per phase. We try to avoid large ships if possible.

There's definitely clarity about what you want to build: the design. It doesn't plan time for or room for creativity though. It also feels quite a bit like waterfall, as there's a lot of informal pressure against demoing anything other than the exact design provided so by the time you have that pixel perfect, it's time to ship it.

I'd have better scoping and have it done by engineers, create a culture of demoing early and often so we can focus on the best UX rather than focusing on matching the initial design, and in doing both have more time in the plan for creativity instead of planning just enough time to implement the design (which is usually estimated short as no eng scoping means dependencies are never properly accounted for).

Something between agile and waterfall – very little planning upfront, build the design, review and edit with product manager + designer, ship something pretty close to the original design

Being able to link tickets is great over Trello. Easily being able to filter for sprints/assigned to me/unassigned is nice too

Goo cadence, even if it feels artificially. Biggest pain point: no good framework combining UX and Scrum.

I would really think about standardatized framework which covers discovery and delivery.

Nothing.
No vision for the company. Complete lack of transparency. Radical priority changes. A complicated priority one task is often completely forgotten right after delivery, because product and design shifts focus, and the rushed work is not utilized in the end. No formal or informal intro on how to communicate with the teams.

Really hard to finish a bigger or more technical project, there is no transparency on what we are going to work on the next day, or next hour, even when we're knee deep in yesterday's "priority one" task. I would sort out priorities, and would keep at it. I would let people finsh their task before throwing more tasks at them.
There is no real product roadmap, I would share a high level plan with the teams.
Promoting an engineer to a technical management role without any leadership experience or help is counterproductive, an experienced PM is often better. I would hire better.

Non-Venture Funded Tech Companies

Team lead of the team in question; engineering manager for projects spanning multiple teams

Engineers are empowered to create their own plan + their own timing estimates, managers can only influence the plan, not directly control it. Teams can reject unreasonable asks from the business. Plans are made every 3 months, which gives teams + managers predictability, but freedom to innovate within the plans too. It sounds very bureaucratic and over the top, but I find that it really isn't. The only pain point is that once a quarter you have 3 intense days of planning.

It's very flexible and allows fast shipping. The biggest pain point is that deadlines can not be estimated very accurately, so we always miss the planned dates by some amount.

I like it's flexibility but this also means that sometimes the focus can be completely shifted and we lose momentum

To learn the tech, how things work, to use KISS approach, and improve development techniques to provide metrics, logs useful for production

I am in charge, but if I could change anything, it would be to have some members of the team understand that this isn't designed to take away their creativity; but to provide guard rails so they can't injury the company/harm their own careers.

Digital Recruitment Solutions Company

Scrum was chosen by the team. It's useful for its well-understood terms and ceremonies. But can be clunky, e.g. trying to have a shared sprint goal in a cross-functional team.

I am actually in charge(!) but regularly check in with my team on methodology. They are free to change process. I'm not a fan of Jira but strangely team like it!

Be more product vision driven, less "customer feature request-driven"

By a product team, led by a product manager with a tech lead and 2-4 developers. Larger (new) initiatives are coordinated by the VP of product and CTO, but apart from that the PMs run their teams autonomously.

For big project > 250 days we have a senior tech lead/architect/product manager leading the project accross all teams and following it in detail and reporting to management.

Have a all team collaborating to finish the project on time (we always have a team not really interested by any project)

It gets things done relatively well but there is a lack of consistency between the different teams. (In terms both of process and documentation)

I would enforce more consistency for all team in terms of process and methodology

It has been working well in teams where the Tech lead has good organization skills/PM skills. In others teams it’s very messy, planning/sprint/backlog does not reflect the actual work happening, some task drag for long, developers keep jumping around leaving unfinished work behind.

Better alignment of the project management, cross team priorities are not well defined, many times priority 1 on team A depends heavily on work from team B, and that work can be a very low priority item for team B.

Shared responsibility between product manager, project manager, and tech lead

Agile doesn't work well in what is essentially waterfall driven timelines. Product plans according to a wishlist, doesn't involve tech for realistic timelines.

Let tech properly plan execution time and set expectations accordingly. Acknowledge that while dev may operate in scrum, in reality external dependencies (e.g. deadlines with partners, new services) dictate a waterfall framework around that.

We don't have a single "lead" - product tells us what to do, we as a team decide "how"

Nothing really, only that its changing and everyone sees its flaws. Biggest pain point - top-down approach

All the team needs to get involved in goal setting, direction etc, otherwise you've got no buy-in and people feel desingaged.

Top-down. Product agrees with the customer on what's needed to get done. Then they tell developers... We are required to estimate a project thats going to take a year at least - in advance. No surprise that that estimation does not quite work, as we don't know all the details. Luckily nobody blames us for that here, and the situation is improving, so we can have more say.

Medium-Sized Business (Startup, acquired by Big Tech, then bought back)

Hate: micromanagement, daily standups, feeling that I have no control in what I work on, little motivation, timelines always underestimated; Love: a bit of planning is good, sometimes this approach helps get an overview over topics

Scrap big daily standups in favor of weekly ones in smaller teams, scrap hourly project tracking, just have big goals for timeframe and track if goal was achieved.

It is utterly dysfunctional.
“Sprints” are performative productivity theater.
No meaningful engineering changes are allowed beyond incremental work in the same direction as exists.
Shadow projects are prevalent and the only way anything useful gets done.
The majority of good engineers have left for better companies.

- Allow all teams complete authority to self-organize how they track and deliver work.

- Empower Engineers with full and complete context about business impact and priorities including real time usage and revenue data.

- Have engineers talk directly to customers.

- Bring in outside consultants that know REAL agile to teach how small slices of code, continuously deployed to production accelerates engineering velocity and reduces risk.

- Totally revamp culture to demand psychological safety, by aligning management bonuses with anonymous surveys of IC’s on freedom and safety to experiment and fail.

Every quarter strategic direction changes and there’s a new critical project that all work is dropped for. Projects always have absolute deadlines that are imposed with zero engineering input. Inevitably the deadlines are completely blown past, there’s never any discussion or understanding of what should be done differently next time.

Retrospectives are held as performative theater, they are run by a project manager and input on any true changes is unwelcome.

Critical software systems are ossified, decaying, and break frequently. They are unable to be changed as it’s never part of that quarters emergency business priority project. Also most core systems were built by a select few engineers who oppose any changes.

Large, Non-Tech Companies (Non Venture-Funded)

Cloud-Based Knowldege Management

We communicate with customers and think about the problems instead of just slapping a solution at the first thing that comes from a customer's mouth. Lots of discovery and research. By the time we are done with research, etc. the implmentation itself is often very simple because we've boiled all the decisions down already.

Going well so far - nothing to change yet.

Based on what makes sense as next steps for the product: are our large clients requesting the same feature? Then build it. And we struggling to sell due to a missing feature? Figure out what that feature provides and solve the underlying issue.

Still to understand the bigger picture

Internal "Startup" within Athletic Wear Company

The biggest benefit of our scrum process in my opinion is that all teams work off of a two week sprint. This allows us to coordinate efforts on shared timelines.

That said - scrum feels very forced. Planning and standup meetings are awkward when the project doesn't fit the current process - for example if we're working on a large MVP that would benefit from a waterfall approach, or maybe we don't have direction from the business and can't fill a sprint with work properly.

The main issue isn't really the day to day process, but rather how team direction is decided. Engineers wait on product managers to tell them what to do, but product managers either aren't aligned or don't have enough ownership to make quick decisions. I think part of this may be the way our teams are aligned to parts of the product - this is something we've been working to correct.

Additionally, we have a lot of trouble balancing tech debt / maintenance work vs new product work. Engineering has to fight to get technical work prioritized and big projects like replacing an entire system never get started.

If I was in charge, I would align product to teams in a way that gives them real ownership over a specific domain. I would also formalize a process for prioritizing sprint work that forces a balance between new work and tech debt work.

The business has two ways of working - that of the digital organization which is Agile (mostly scrum with some kanban) and a more process heavy workflow that non tech organizations follow (I'm less familiar with this). I'll focus on the scrum process the digital organization uses, without considering the larger part of the business. Additionally, the digital org uses something called "scrum of scrums" which is a team made up of leaders from each of the teams that syncs weekly - we use this to coordinate work between teams.

Involvement of our customers in the scrum process, currently we only have proxies for them on our side and this middleman role looses clarity on what's really important for the customer as well as being horribly inefficient.

The project phase is great and a lot of good people collaborate. However the long term commitment is missing and a lot of the compromises that are made, are never revisited.

Get rid of scrum for all the teams. Define clear kPIs and let the teams continuously improve these KPIs

Large scale projects typically get a lead developer bundles with a product person. They are shaping the project and cutting stories for the dev team. Afterwards most of these projects are incorporated in longer running SCRUM teams

Hard to answer. PO/PdM prioritizes work, typically the scrum team leads w from there and works w PO. SM facilitates.

No clear lines of accountability for SM. Teams have been burned by "bad" SM who act more like PM than coach. Some teams expect a PM and are dependent on a SM/PM hybrid to guide them through all the org/architecture dysfunction and dependency.

True cross functional teams with Product Owner, Agile coach, and all dev + QA skillets required on the team. Try it and continuously improve from there.

Scrum as a base, reality bends it usually towards longer release cycle and various feedback loops not following exact sprint cadence etc

Finding the right approach to the given context is always hard. When business stakeholders are not very open, then it's even harder.

Use ideas from Cynefin and Wardley maps to use appropriate methods for different stages of product or component development.

Not enough Product Management

Empore the Single Teams, give them own resources

Not much I like about it. It's very fragmented, and makes incentives really hard to parse. The people who are often in charge of leading projects have zero ability to actually provide any leadership to bring it to fruitition, where we should be aiming for much more collaborative approaches. Projects the properly have that collaboration exceedingly outperform other organizations and teams.

I do really like Kanban, but oftentimes is actually determining the scope and goals of the work that is lost, thus the Kanban board isn't representative of what the best customer outcomes are. Teams that perform the best with it have really clear shared vision and outcomes, and use Kanban to help organize their journey towards those metrics/KPIs if they exist, almost with a JIT mentality.

Heavily business led, small number of tech leads who manage implementation with difficulty in having involvement in core product decisions depending on the level of external influence to the project.

Publishing indusry (a popular newspaper)

Teams generally own quality and can write for quality (e.g. with unit/integration tests, & CI/CD pipelines). The problems are the rigid ways of working and little input into the process

Give teams more autonomy to choose their process. Reducing the amount of meetings that engineers are involved in and allow them to focus

Pretty much all bad points, the people building a project aren’t on the line for running it, or paying for it or building for scalability. Fixed deadlines should lead to MVP thinking but this is slow

Reform around product teams who have skin in the game for run.

At the moment as scoped discrete projects wither waterfall or “agile” but teams are formed around a requirement, delivered and then (if very lucky) handed over to service.

Plus: Kanban is visible and collaborative. Pain: Lack of time boxing/ time tracking and as a result no ability to estimate.

Implement common methodology and a scaling framwork like SAFe. At present there is no or mixed methods (no consistency) and Kanban is not really a method - its just a tool!

Kanban (JIRA) to coordinate effort and capture requirements. Larger items fall under PMO - where a BA/ PM is applied. Smaller BAU items are run by the Dev Lead - who coordinates resources.

I would introduce cross-team collaboration and feedback loops. silos and "agilefall" are a problem.

Large Digital Travel Sector Company

Trio of RTE (SAFe Release Train Engineer), Product Manager, and Architect

Provide flexibility to the teams as to what methodology to use. SAFe is very rigid and reogs are difficult when scope and priorities change (which happens often)

Large SAFe trains, led by a trio of RTE/PM/Architect. Some projects are run in Scrum, led by a Scrum Master, or even more rarely at the discretion of a line manager, run by the line manager or an engineer in the team.

A product owner (that in reality acts like a non-technical team lead)

SaFe and agile are used as buzzwords, but in reality is just plain old waterfall that makes everything worse

Implement real agile, increase headcount, provide confidence in technical people, stop micromanaging

Europe (Germany)

Like: I have high autonomy how to work with and structure my team. When the task a reaching us we do some workflow based of Scrum but is highly influenced and changed by the team. The team is giving a lot feedback how this process is working for them. We write a lot of our tickets our selves or get wireframes and tickets from our product managers. Those PMs are different from those I wrote above and are basically part of the team and know a lot about (mobile) development.
As crazy as it sounds the step that projects need to be approved by the board is leading to better results and less projects that aren’t worth it. But that is just a small bandage on a larger problem with the org and culture. In a working env you wouldn’t need this step.
Dislike: All the above how we run projects. Every project starts with an end date even without asking IT. Tight control over projects and deadline leading to more changes and meetings. I have a lot of free room around this stuff, but only because we deliver.

I would change a ton as you might assume from my answers so far, but this would mean a total culture change from everyone starting from the top in a large corp and I don’t believe this will happen. If I can change one thing I would remove the project leads/managers and let the teams work together instead isolating their work.

With such a large corporation there are many different ways how projects are run and I tend to run smaller projects in my department different from the company standard. The company standard is that a department first needs to get their projects/feature approved. For this they fill out a more or less detailed questionnaire and get it through an approval meeting with the board (CEO, CTO, CFO etc.). If they get the project approved it will be taken on by a large team of project managers and analyst. Please keep in mind that we claim to be agile (Scrum)…
They will arrange (large) meetings with all the necessary team leads to get this feature build. This process will lead to more documentation (BSDs) what to do, everyone giving an estimation and timing.
For the engineering team leads this often means you have several of those project meetings a week with totally different project managers you need to explain the same and everything has prio 1.
If everything goes well engineering understands what we need to do and it is doable. Often the project ideas are so detached from the real world that further discussions are needed.
Engineering or their own Product Managers (or POs) start to create tickets (Storys in Jira, but not in the style of a user story).
Backend plans their tickets to implement it, often stretched between different backend teams like SAP, API etc. Frontend is waiting for backend and often gets handed the final API without review. After it was build frontend explains why the API isn’t working for them and creates changes. After it works, Frontend can plan to build the feature. Depending on project size and team tickets will be tested in the team or go trough a medium sized test department.
After several rounds of fixing and changing the requirements a projects usually goes life between 6-24 months. As I sad we are agile ;) This was the short version, there are many more steps and people like agile coaches involved etc.

Completely disliked the approach. Felt like I had no decision on anything. The estimations were also absurd.

It changes every re-org. Usually a non-technical EM or a PM. Leads to some pretty interesting requirements ¯\_(ツ)_/¯

Dislike: Tracking metrics (burn down, capacity, etc) seems to mean more to management than delivering value to customers

Give teams freedom to create a process or approach that works for them

Let teams decide how they want to work. Less hierarchy(PO/PM is a gatekeeper between customers and developers)

I very much like this approach because it allows me to focus on programming and continuously deliver.

On my current project, we do not have much ability to contribute to requirements or impact the feature list. But the graphic design team (which is a different company) obviously does impact this significantly. There are times when earlier or better communication of features would lead to better planning on the development team.

Loosely Agile, with 1 week sprints managed in Jira. Each project has a project manager, and on my current project, there are 4 product teams (of about 4 people per), each working on the same product for different hardware platforms.

There is one project manager that creates tickets and manages workload (though developers can also create tickets and are encouraged to do so).