> everyone meeting
I think it's emblematic of a few things about the founder/cofounder/lead: 1) they are an egomaniac and just needs to see everyone reporting in, 2) they don't trust their teams because they need to have daily all-hands status updates, 3) they're not connected to their teams' work; there is no visibility into what's getting shipped, 4) there's a strong correlation with micromanagement.
Learned this through a few mistakes joining teams where the founder/lead insisted on frequent all-hands standups (sometimes lasting 45-60 minutes to get through all of the teams reporting in).
It was literally a stand-up, that is, everyone stood in a circle. Everyone was expected to utter exactly two sentences: what has been done yesterday, and what are the plans for today. It usually took 10-30 seconds per person, so the entire meeting was under 10 minutes.
It was pretty efficient: you almost instantly knew who are you going to talk to later in the day, if need be, or what changes to look at.
Very few people care about "what did you do yesterday?". It's already over, by that point. There's a lot of benefit to removing that one.
In my team we do it like this:
- how are the nightly tests? (we've actually dropped this in recent months)
- what's in the Test column, and does it still need manual testing? (we have automated unit and integration tests but also, sometimes, do manual testing just so a 2nd pair of eyes has seen a thing work. We're not strict about it)
- what's in the code review column? Are any of them stuck/unreviewed/etc? (to remind people to do reviews)
- what's in the progress column that needs help/pairing or some kind of management support?
- any other business
With these three rules:
- save the details for other, more focused meetings or Teams. Anyone call time on any discussion.
- strict max 15 minutes time-limit
- jokes are fine
Works well enough that the next time I work in a team that doesn't do it this way I'll do all I can to move them to this format.
...except the people for whom what you have accomplished is a dependency in their work. It can be a direct code change you'd have to merge into your current branch, or something you might want to start using (or finally stop using). It may be even something you have to contemplate on, and it may affect your work much later.
Work of people in a team is inevitably interconnected, and so is work of people in sister teams.
My current team is essentially front-end only and it's rare that we divide work up such that one person is waiting on another in the same team. If that's a possibility, we tend to pair instead.
Eventually we wrote a real-time web chat, just because it was a fun project for someone. But it did not replace the standup, until I left in 2011.
I've also seen teams update wikis for their daily standup.
Some things are not very enjoyable, but still necessary.
Also, if your boss tells you to read the emails, and you don't, then you can get fired. You can't get fired from your job for not exercising. If you can ignore the emails and not get fired, that's proof in itself that the emails are not important, at least not to your boss.
The boss has no easy way to tell if you read the emails or not. The consequences of lack of information are often hidden / long term.
In many countries, it's pretty much impossible to fire employees for forgetting to read an email.
> If you can ignore the emails and not get fired, that's proof in itself that the emails are not important, at least not to your boss.
I'll try a proof in a similar style - if Scrum was so wildly inefficient, the companies practicing it would be a long time out of business since companies with no meetings would easily outcompete them by offering better products/services for lower costs. Yet Scrum (or similar methodologies) are used in many successful companies all over the world, that's a proof that Scrum works.
How do you like them now, these oversimplistic "proofs"?
What about "forgetting" to attend a 10 minute meeting?
> I'll try a proof in a similar style
It wasn't a similar style.
The instances of people not attending standups I've seen were just symptoms of a larger problem, and such people did not last long in the company.
Standups are one of these in my honest opionion.
The main point of stand-up/daily scrum is to set up collaborations and coordination. It's where you invite pairs, inform POs of blockers and discoveries that will lead to longer timelines etc.
If you're doing all that anyway, keep going and don't worry about stand-up.
It was even worse than this: The Scrum operators wanted an engineer from every team they interacted with to also join their meetings.
So if a project made an API request to another project, they'd insist on pulling an engineer from that team into their weekly or daily meetings.
I had daily meetings with 10 people, half of whom might be engineers from other teams who didn't need to be there.
Meetings became so useless that everyone stopped listening until their name was called so they could work through meetings. Then every time someone's name was called, we had to spend 5 minutes recovering the last 5 minutes of the meeting to bring them up to speed.
The inefficiency was out of control, but the worst part was that some people thrived on this level of inefficiency: Lack of progress meant the empire builders could argue for more headcount, too many meetings meant the Program Management department could hire more program managers. It was like a case study in adverse incentives.
The agile manifesto was too abstract in it's original state, and folks who needed a rigid framework created capital A agile in order to adapt it to their cog in the machine role.
For my team of 6 in a ~20-25 person (remote) startup, we have a 30 minute dev meeting in the morning, and a 15 minute full team meeting where the agenda rotates daily around departments. I quite like it honestly, remote can be lonely and isolating otherwise.
Generally I think it's important to structure team responsibility around who ultimately needs to make the decision (although they need to consult others and get team buy-in). And hire people you trust to make the decisions. Then the meetings become about problem solving and getting through the work, rather than performance art and politics.
It should be a literal standing meeting. You dont get to sit and drone on. There is one in every bunch and when they make their peers stand for 10 mins. The team will self correct the person into not being that way.
That meeting is a check point. What is every one up to, and everyone else gets to hear. It's a way to get a team to gel (and many aren't)... If someone surfaces a problem in there (and they should be) then there should be some other team member offering to help out - there should be dialog if some dependency is going to get bumped by others being distracted.
These meetings are effective up to about 10 people. They work well with cross functional teams, or teams where the members have varying levels of experience.
Also no managers are allowed during our daily meetings. This is something important that enables more candid communication.
Something I've seen for the first time at my current project is instead of a daily standup, there's a daily thread to report what you've been doing in Slack instead. And then as long as there's nothing people want to go over, the actual standup meeting is skipped. We sometimes go a 2-3 weeks without an actual stand up call. It's pretty nice. Even if not, the calls are only scheduled twice a week anyway.
Much better than the 20 person in-person daily standups in the conference room, better get there early if you want to have a chair, at 8:15am every day, like a previous job.
I found it stressful to write the summary of what I did yesterday in the morning because I’d been thinking about other things in the interim. I discovered the “life hack” of filling out my report in the afternoon at quitting time which makes me, from the viewpoint of everyone else, the first to report. I find it really easy to do and when I get in the morning I have a plan in front of me which helps me carry forward my momentum from the previous day.
I once mysteriously turned into "not a culture fit" after several rounds of interviews with excellent feedback up to that point and I'm fairly sure asking a couple of similar routine questions about their dev process was what got me tagged with that label. I do consider that one a bullet dodged - if your process is so bad that you're worried about a candidate asking about it or you think they're being awkward for doing so then that says everything really - and I still ask similar questions of anyone I might work directly with/for today. But if there's a place you really want to work it's worth keeping in mind that some people apparently get rubbed the wrong way by this kind of question.
What I've seen pretty much my entire career (early 80's) for projects is just a straightforward process of up some front planning, phased design+dev, management of tasks through a regular (weekly or twice weekly) low overhead process (what's ready for next step, where are challenges), etc.
The key is having an experienced technical leader to guide the process. Typically, PM's don't have enough detailed technical experience to really understand how to make this stuff work.
These morons know nothing and bark out orders based on their agile bonafides which is nothing more than snake oil. A magical cure all irrespective of the problem you are trying to solve.
I'll add that kanban means much less time filling a backlog, to the point that an individual can own that, and you're eliminating that meeting.
I've only ever been on projects where the backlog was filled by a PM and or lead engineer and then reviewed collectively and maybe some amount of re-shuffling would take place. Are you saying you've been in meetings where the backlog started empty and it was populate with the entire team in the room?
> I've never seen an empty backlog
How about a backlog with stuff near the top that's no longer relevant or has drastically dropped in importance?
If the top of your backlog is uselessly stale, you're spending too much time writing tickets in the distant past and not enough recently (or maybe congrats on your velocity?). A ticket that's so old it needs to be overhauled to be worked on was written prematurely. This is one of the things kanban is good at.
Edit to add: a team that's heavily reliant on a PM might not be a great fit for kanban? It's not for all teams, and is a natural fit for some
The answer might be simple for small teams, but a lot more complex for larger teams, where the result might look eerily close to Scrum. One difference would be that meetings will take place infrequently and only "as needed", where I wouldn't trust most teams to recognize their needs.
I'm really curious about this question, are you thinking that not having Scrum makes it's harder to refine features?
I'm trying to understand what assumptions you are making, because I've never worked in a Scrum environment, but have always refined features as part of the natural flow.
"natural" as in "law of nature"? Or is it just a process which crystallized in the course of your career as something which makes sense to do?
Scrum, and other methodologies are mostly a collection of such processes which proved to be useful, are somewhat standardized for learning and communication.
One can reinvent many of the Scrum processes independently, but I kinda don't see the point. Just like I'd rather use a finished library / framework rather than try to hack together my own.
The "no true scrumsman" fallacy at work.
Overall "is that really agile though?" is such a fantastic thought stopper. It's can be thrown out to derail any sort of proceeding. It moves all focus from what's practical and applicable and relevant to the situation at hand, and moves it to an endless discussion about philsophical alignment.
Whether it is or isn't depends on your feelings on scrum, but it's not a fallacy to try to defend the initial definition before it was co-opted by anyone with an Agile cert.
"Hammers suck at driving nails." "You're holding a rubber mallet." "No true Scotsman!"
If you have managers/PMs/TMs/HMs/BDFLs that can't see the forest from the trees and a corporate mandate to use Scrum (or Agile generally) then of course they'll pervert it to suit their own ends. Slow-moving organizations with complex incentive structures like the government and Fortune 500s are especially good at this. If you want to be upset with somebody then blame them. I've worked on teams where stand-ups were less than ten minutes long, we delivered every two weeks, and we had properly-specified Scrum Master and Product Manager roles and it worked swimmingly because we _actually did Scrum_, not "Scrum, but...".
Scrum is a prescribed process. It is not the performative act of dragging work items into Sprints in JIRA then using various Scrum terms for 5-hour-long weekly meetings.
Every bad Scrum/Agile situation I've been in has orchestrated by people who were convinced they were doing it "the right way"
Every defense I've read has been from other people who weren't there who insist that it must be "the wrong way".
If you define the "right way" such that it can only be good, then you conveniently dismiss all of the negative criticisms at once. Yet in the real world, there appear to be a lot of us stuck in companies who think they're doing it by the book but it's still not working out.
It became really difficult to push back on or change anything because the Program Managers would band together and brandish their Scrum certifications, Scrum books, Scrum podcasts, and other credentials to show that we couldn't argue with them. Unfortunately, it worked with management.
Wipe all of that away and let all of us work together toward a methodology that worked for everyone without Product Managers playing the Scrum card at every disagreement and I have no doubt it would have been better.
In fact, I have some proof: There were a few pockets of small teams that got to operate outside of the Scrum madness either because their tasks were thought to be too small or temporary, or because they existed in islands of the org chart that were free from the reaches of the Scrum people. These small teams ran circles around everyone else, but that would come grinding to a halt as soon as their projects got assimilated into the Scrum catastrophe.
In my opinion, retrospectives give the power to the team to improve their own process. Without self-organizing teams, you have no agile. So without retrospectives, you have no agile. So I always wonder if and what they do during these retrospectives.
Agile has been plastered over certifications, podcasts, books, conferences, trainings, and everything else for years. The people I referred to above had been through it all and brandished it like a weapon. You can tell me all day that it's not true agile but it didn't make an iota of difference to how things play out.
Judging by the comments, my experience is not unique.
"Individuals and interactions over processes and tools."
Processes and tools (i.e. Jira, sprint planning, retrospectives, etc.) dominate all implementations of Scrum I've seen.
What happened instead were impromptu "ghost" meetings and a ton of stuff done sloppily over chat instead, where I think the hope was that people would try to become "more efficient" with their meeting time.
Required meeting attendees should consist of the Rs... and only the Rs. As and Cs can be optional, but meetings can conclude without them.
Everyone not in the meeting can be updated out of band.
"What action is this person taking in this meeting?" should be a brutally honest question. If the answer is only "listening", then it's a waste of their time.
And also, related point: what is the termination condition of this meeting? And has that been decided and communicated beforehand? I.e. What outcome are we seeking, that when done everyone agrees the meeting is over?
I can't stand agenda-less, "we're meeting to move something forward in some undefined way" meetings.
Is the purpose of the meeting to inform, decide, workshop, or persuade?
If it's to inform, it should be an email, but some people do not read them, so you need to sometimes read the email to them in a meeting.
If it's to decide, do you have the people that will decide called out in the agenda? Do they have the necessary information or have they done the necessary work to make a decision in the meeting?
If it's a workshop, do you have the invitees pared-down to those that will be actively participating? Is there work they need to complete before the meeting, so they can be active participants?
If it's to persuade, these should be in smaller formats. Preferably 1-1 to start, so objections and resistance are raised in low(er) stakes meetings.
Meetings should end with a summary of decisions, next steps, or some other call to action. Preferably these are recorded somewhere and distributed to the rest of the attendees or a wider audience if needed.
Luckily I was in a position to change things and consolidated a lot of the ceremonies. I kept more of the process in place for our offshore partner team because the communication burden was higher.
So I guess my two take aways are that time in meetings needs to be evaluated with how meetings are grouped to avoid too much context switching and allow for folks to get into a flow. The other is that how strictly you adhere to “textbook” scrum really depends on the composition of the team. More junior teams or teams that are insolated from the larger business context benefit more from more process imho.
CTO was fired, I came in and evaluated everything, slashed the consulting teams down to the ones clearly performing, and slashed the processes down to boot. Within a month the team velocity was way up and we were releasing to a nice cadence without fear.
And this was not because I’m a super man. I’m not. Any competent tech lead or manager could have done the same. The only difficult part was dragging the product folks along, they kicked and screamed the whole way, predicting doom, and were amazed when the sky didn’t fall.
Like, the burndown chart has to be nice and steadely go to zero. There is no way to do that without decoupling reported hours and estimated hours from actual hours. Or points. It doesn't matter which.
Changing 95 files because someone didn't want to centralize some value in a method call last year (YAGNI!) is now high effort, even if low complexity.
Then... "that's too many files in a PR! break it up! no one can review that many files!" It's the same two line change in each file - this shouldn't take that long to 'review'.
I've often spent more time arguing about points/effort/estimates than doing the low effort work. But if we don't record it properly, you won't get 'credit' for the work!
Slow-paced insanity when taken anywhere near close to its logical conclusions.
As a rule of thumb, if the work is estimated to be a day then is should take me 1/4 day to estimate. If two days then half a day to estimate. If 4 weeks then 1 week to estimate.
We normally continue with guesses that are meaningless.
1/4 seems reasonable for a day or two, but I dunno… it seems like there must be some constant factor?
We don't create 1 point stories, you need to roll this up with another story! Hey we don't do 13 point stories, you need to break that one up! 8 points? you sure that isn't a 5? 2 points, 3 points.. what's the difference just mark it as a 2.
OK so basically we just have 2s & 5s then? Amazing.
So all that gets remembered is .. this guy always argues in the scrum meetings, AND his estimates are always high, smdh!
In every team I’ve tracked, the task count burndown velocity was impressively linear, whether looking at weeks, months, or years of data. I think we can thank the Law of Large Numbers, with shorter than average and longer than average tasks balancing each other over time. (We never bothered with story points, so I can’t compare.)
A single deliverable is now 3-5 different tickets that might get split across sprints. It now becomes harder to express when a piece of atomic functionality will be delivered because you need to track with dependencies across the tickets, etc.
So it feels like contortions to make reality fit into Agile which negatively effect reality.
Let's say we are using Agile in the kitchen and we have 3 tickets - 1) research recipe, 2) collect ingredients, 3) bake cake. These are logical and understandable to a stakeholder. You can assign them different story points / sizes / durations / whatever. It's relatively easy to express the dependency and also keep it in your mental model. Each has a deliverable - 1) recipe & ingredient list 2) the ingredients 3) the cake.
However Big Agile Coach argues that really it should be 1a) research recipe, 1b) collate ingredients required, 2a) research pricing on ingredients 2b) create per-vendor ingredient lists 2c1) buy ingredients at vendor 1, 2c2) buy ingredients at vendor 2, 3a) clean kitchen 3b) prepare cake batter 3c) bake cake 3d) cake frosting/finishing
OK which of these 9 tickets depend on which / which can be parallelized / which are best to keep with a single dev, which should be done within a single sprint vs split across? Etc.
This realy grinds my gears. I had a recent experience with a scrum master (technically a delivery lead but in practice a scrum master). Really nice guy, smart, easy going. We had many discussions about the value of estimates, and the whole "it's complexity, not time" trope would come up. So I asked what the estimates were used for. Turns out they're used to forecast cadence / velocity. Of course, knowing that we were going to be asked why a small story was taking two weeks to complete, we'd start sizing based on time. After all, we're humans, biased and flawed.
Now you tell me, how do you want a measure of complexity to be a predictor for cadence when these 2 things are at best orthogonal?
I was already adding time to my work like an extra point or two here and there
But then in the grooming session the whole team would guesstimate even more story points! I was dumbfounded! This was beyond all of my levels of tolerance and rationality but it kept happening every sprint until something that was a 0.5 for me was a 5 point and I would have two 5 point tickets for the whole sprint that I would submit to QA one day before the sprint ended, 9-10 business days later
and actually doing that made me a star performer, what the hell!?
When you point a "0.5" and your team points a "5", stop and discuss the discrepancy until an alignment can me found. Keep doing that, every task, until you a collective meaning of "a point" is found.
Personally:
* Less than 1 - These are a smell and should not exist. These misalign incentives and encourage "bike shedding".
* 1 point tasks - no task that requires 2 people (dev and qa) is a 1-pointer, so this is something that needn't be QA'd. 1 point tasks should be rare items that can't be a subtask of a "real" task.
* 3 point tasks - These can be done in a day (depending on the team's opinion, this might be multiple people and still be 3 points). Virtually every task should be a 3.
* 5 point tasks - These are tasks that cannot be broken down to be done in a reasonable amount of time. These are generally things that have minor external dependencies. ("not hard but I'll have to get a server spun up by the unix admins.")
* 8 point tasks - These are rough tasks that haven't been fully dissected by the team and are the scrum version of a "code smell". The team should break these down and dissect them.
* 13 point tasks - "There be dragons here" tasks. Large unknowns and these tasks should not be added to a sprint until they're broken down further.
It's a one-time conversation (per new team configuration) that makes every conversation thereafter fast.
My team's pointing sessions are lightning.
Even when you do have a new team member that wants to discuss a "0.5-vs-5" point disparity, you explain the above in less time it took to read it and get back to work.
Isn't 5 points less than 2 days then?
For the record, in my team we don't use story points or measure velocity. I just had a frustrating discussion with a peer team that didn't plan an important task because "its 5 points and does not fit into a sprint".
At the round-table people would report their retired points, and I'd add them to a running tally I kept on a piece of paper next to me. "2+1+0+5+2+2+8+0+1." Then I'd record the velocity for the week for the whole team, and we'd move on.
I don't think it's helpful in any discussion to try and pre-emptively dismiss people who might disagree. People have been doing that for the decade or so scrum has been mainstream and it just dumbs the discussion down to he-said she-said.
That being said, agile as it was originally described in the manifesto was not prescriptive, and scrum, while it was intended to follow in its footsteps, has been a victim of its own success. It's now firmly in the domain of other highly-prescriptive management frameworks thanks to the effort of consultants and managers who adhere strictly to the letter of scrum without paying thought to the essence of it.
Most people I know who were fans of scrum back in the day have distanced themselves from it because it's not agile any more. Certainly not with consultants selling SAFe as an agile methodology.
But that's exactly what the people I'm talking about are doing:
They define scrum as something that works, thereby preemptively dismissing any complaints from situations where it didn't work.
I've been in a couple places where I did know 'everything', or... near enough. The more I got to learn outside my own specific dept, the more cynical and frustrated I became (usually). You start to notice that entire groups of people are often just sitting around for days doing absolutely nothing because they're waiting for one person who's out for the week, etc. Or you learn that people just spent 4 months working on something that was rejected in a meeting 4 months earlier, but... the original team still wanted to do it anyway, and therefore couldn't help your group over the past 4 months.
Never have I ever heard about any story about agile making things better.
Sometimes the process worked better, sometimes worse. It depends a lot on the company culture and people. The company I'm currently at has a very good process (SAFe).
(I'm an engineer to clarify)
From what I've heard before my time, a lot of traditional organizations had a non-flat hierarchy and a set of 'bosses' - people in charge of personnel, planning, requirements, and technical decisions.
In 'modern' orgs this has been replaced by a 'matrix' structure with each team having a dedicated product owner, scrum master, line manager, requirements engineer, architect etc.
While the traditional org structure had some shortcomings, mainly having to do with the fact that if said boss didn't perform, then the team had no chance, and that so much institutional knowledge was locked up in said boss, that they were nigh-impossible to replace.
Modern management techniques are about replacing potential excellence with guaranteed mediocrity.
- the team was made up of primarily junior engineers with a small handful of intermediate and seniors
- the company's work was split between a product and N consulting projects
- the company had standardized on a specific "default" architecture (Spring Boot + Angular) with a bunch of pre-existing components that teams could use to accelerate their projects
- the projects (product and consulting) were generally managed by the intermediate engineers with a handful of juniors on each project doing most of the day-to-day work
- the seniors were mostly on the product side but had latitude to go help on any of the consulting projects if anyone was stuck
Scrum with the daily standups and bi-weekly retros worked great here. The seniors went to all of them. If someone was getting ready to start on something and they weren't aware of existing components that were either available from the library or available to libraryize from a different project, we'd help facilitate that. If someone was getting stuck on either a tricky debugging problem (of which Spring Boot was good at making) or a complex design problem, one of us would stick around and just get it solved with whoever had the problem right away. And on the other side of it, we were sufficiently looped into the various projects that we could use that as input for larger-picture architecture decisions etc.
(Ah, too late. Guess I should have refreshed)
Basically, agile is an adjective. Anyone using it as a noun is selling snake oil. Yes, it is that bad - a whole industry built from the ground up to monetize a simple concept by enshittifying it into its very opposite.
https://youtu.be/a-BOSpxYJ9M?si=tCvDcHYv7F77XbZ9
I also like Basecamp’s shape up process which seems to follow the spirit of the manifesto.
Let me start by saying, if you intend to adopt ShapeUp, spend a great deal of time reading and buying into their structure of teams. Aside from SIP/QA & KTLO work, they flatten the “Core Product team” and build ad-hoc teams for a pitch that has won at the betting table - for that cycle. Trying to maintain standing teams with domains of ownership is a very challenging way to adopt this process.
In my experience, unless the entire org is drinking the kool-aid - hard - you end up with 6w cycles of waterfall. Pitches morph quickly from “present your idea that we bet against” to “write up a detailed design doc, along with an Epic, backlog and all projected work” - then the org will just do the work they want (betting or no). Now your team is committed to delivering on your pitch - any other work just gets dumped on the wayside - unless you’re on-call of course.
As with any other incantation of an agile process, you can bastardize it to confusion, thinking you’re smarter, or “we’re adapting this to fit our org”.
Folks, this stuff is a discipline. You have to buy in, you have to learn the principles, you have to practice them - as described - until you attain some degree of mastery that you can adapt. This is not an individuals game, this is at the org level. The individuals must commit with the org to gaining mastery before customizing to your liking.
In spirit - there’s nothing fundamentally broken with Scrum or Kanban or ShapeUp or whatever. It’s really how you hold it - and yes you can shoot yourself and others in the face by holding it wrong.
Agile probably would have ended a lot better if it had been as designed... plus a requirement that you had to hire an agile specialist to sit in a closet.
The agile specialist doesn't do anything but sit in the closet.
... but on the plus side, the agile specialist doesn't do anything but sit in the closet.
Engineering management, in my experience, has an allergy to agility. They can and do take any methodology, turn it into a process with a rigor (they love that) and strip agility from the mix. They are addicted to well defined requirements, some degree of estimation and being able to predict/project things like delivery, velocity, contributor performance, etc.
We engineers love the principles of agility, so engineering management tries over and over to find that happy medium where they have a well defined process that gives them what they want but imposes the least friction against the agility your engineers crave.
Custom solutions win the day. I have lived through all of the above. I remember when Agile was introduced, do you? Do you recall how violently reactive engineering managers were to this concept? It goes against everything they are supposed to do - manage. Agility inherently means they lose some degree of management ability. It means they lose their precious waterfall where things are meticulously (ridiculously, inaccurately, elegantly, uselessly) pre-planned on paper.
IMHO this is why we see every methodology that supports being Agile - bastardized to the point of confusion, academic arguments based on (not having actually learned, practiced, or gotten good at anything) gut feelings of “how we should do it here”.
Leading, managing work, organizing resources and getting shit done is a skillset that encompassing multiple disciplines. All are documented and practicable - we apparently don’t have the discipline to actually read and practice. We’re like a bunch of yokels on YouTube commenting on who’s a better MMA fighter, telling Joe Rogan he’s wrong - but only a select handful of us actually speak from authority. Only a small handful will actually take on the RISK of trying to understand the literature and practice a methodology like a beginner - without questioning the teacher or the teachings.
All that said. I have seen both Kanban and Scrum be wildly successful. The key ingredient in each of these was a shared humility and curiosity between engineers and managers and an environment that celebrated learnings and put no penalty on getting it wrong. The lack of hubris was absolutely the ticket to an agile environment where shit just got done, engineers had a GOOD TIME, we built meaningful product and we weren’t worried about blasting time in meetings because it never impeded our ability to get shit done. Once the engineering org can demonstrate its key metric (getting shit done) the battles with product cease!!! Product can trust that engineering will get shit done - without handwringing on “when” - and they can properly focus on “what” shit to get done.
When engineering is flailing around on their methodology, process or agility - they lose trust. That’s when product starts thrashing. That’s when you start to see initiatives/projects start and never finish, along with shifting priorities.
ShapeUp does an excellent job of giving product a tool to direct what work we’re doing - hopefully making sure we’re working on the right thing. However, if you’re trying to bastardize ShapeUp to fit your engineering org structure - it’s VERY difficult to demonstrate and project “well get this done”. Further, if you think you’re gonna keep your teams intact and do pitches per team - you’re already broken, committing to more than the org can deliver, creating conflict between teams on how to do the work, leading you right back to waterfall. Rather than building the right team of resources for the pitch/cycle - you now force all your teams to produce design docs, plans, backlogs - which have to go through review, get picked apart by other engineers, only to find your assumptions were wrong and the deliverable looks quite different than the design (shocker!!)
I’ll conclude to say we’re likely all doing some degree of waterfall++, branded as some form of “agile” methodology.
If you wish to see that change, encourage your peers and your managers to start with your team, pick a methodology, go exactly by the book, get “good” at it with practice over an extended period, collectively enjoy and DOCUMENT the many “aha!” moments along the way, the proliferate that out to the rest of the org. High performing teams are hard to ignore and at some point the org will ask why - simply be prepared with HOW you adopted and your learnings.
Good luck out there
If the aggregate of the sprint planning, backlog refinement, retro and dailies is more than 10% of the total time (eg 1 full day out of a 10 day sprint) for most of the team then something bizarre is going on. If the everyone is losing 50% of their time to agile things then your process is impressively broken.
My team has been an overlay team for years. We provide services to many teams. Since the glorious transition to agile and product focus, we had to sacrifice someone to be the product owner, so their 'whole job' is overhead management, which they hate. Now, every team wants someone from my team in every standup ("but we'll be blocked if a question for your team comes up and no one is standing in the corner patiently waiting to answer it") and definitely wants someone in every sprint planning. 8-ish person team, dozens of projects, and time disappears very, very fast. I've managed to push back on the 'every standup' nonsense so we don't spend 100% of our time in meetings, and in return the agile folks are using their 'metrics' to basically tut-tut and say we don't do any work.
I can see where if your whole job is on a single project where there workstream can be easily decomposed into 'sprint-size' chunks, agile and the rest are probably useful. But that's not every job, and maybe not most jobs, and it sure as hell isn't my job. But like so many other have concurred, and as I see on a routine basis, there will be someone with 'Agile' or 'Coach' or 'Product' in their job title will have an expansive explanation why I'm Doing It WRONG. Capital One seems to have figured it out...maybe there's hope[1].
[1] https://www.reuters.com/technology/capital-one-scraps-1100-t...
In agile you're supposed to know what's going into your sprint, and each ticket should meet your "definition of ready". Teams shouldn't need someone on hand because they should already have refined and unblocked issues before the ticket was added to the sprint.
Whatever it is you're doing it isn't agile.
We were tracking that per employee.
Everything was fine for a few months and then I added a "total" column next to each row and it became apparent that we were spending close to 60% of our sprint on non-development related tasks. On 45 work-days per sprint we had something like 19 days for features.
Needless to say it shocked my manager. He's not against change thankfully but we're still evaluating what could be better alternatives.
Say you plan to start the "add Foo button to Bar page" in week 7, do you actually do that? That would require some really strong estimation skills and a remarkably stable product and business environment. What's the point in the sprint where you're doing more unplanned work than planned? Or how much carry over work do you have?
Because if I was trying to plan nine weeks of work, I'd get it drastically wrong, and waste tons of time planning stuff we weren't gonna do.
I would make the next few sprints 4 week ones and plan to get down to 2 week sprints after the shorter pace starts to show it's strengths.
Or maybe you have 9 people doing 1 week sprints and that's how you got 45 days. In which case, whoops! I have no suggestions!
So: Do you do estimation in Kanban and if so, how?
If sales and marketing need to do planning, then they need to tell what they want to push back to the backlog so that the feature they want are on time.
1. They have an imaginary reality based on what it once was. 2. They don’t accept the evidence. 3. They have incentives to build systems of people to increase their salaries.
see also "hire fast fire faster"
Same. Even worse, spread out in between meetings. Some days I'd have barely started understanding the work to be done and it was time for the next meeting. Rinse and repeat for each "non-meeting" slot throughout the day and the whole day is a write-off.
I will say that the part of scrum that I like (and I think most people like) are qualities that it's easy for like minded people to recognize. But if someone doesn't get...why it's good to summarize your progress for the team or break things up or understand what a task does for multiple stakeholders...scrum does not communicate that to them effectively. Imo it feels like a system you can use to teach people how to work effectively, but in general those who haven't seen most of it themselves often get buried under an avalanche of terminology and procedure.
Did you worded it like this on purpose, or you wanted to say the opposite? :-)
Of course, that's with Scrum done well. If you're having 30 minute daily meetings, you have a point.
So it seems to me that the main reason why "true Scrum has never been tried" is that most companies never intended to actually try it. They just wanted the buzzword.
Scrum is actually a cultural change. The methodology is just the surface stuff, like the buzzword.
It also doesn't actually happen at the company level, unless the company is quite small. It happens at the group level. I just thought of this: The Scrum that can be named, is not the true Scrum.
"Practicing" Scrum by following dictums in a book is sort of like practicing marriage by following dictums in a book. Those are just guidelines, and the reality is at a deeper level.
EDIT: Come to think of it, that can also be interpreted as: Therefore Scrum is broken as a methodology. It cannot be "followed" at scale. (Much as communism is broken as an economic system.)
Occasionally our Scrum Master will put an actual scrum meeting on the calendar, but then talks about whatever he wants, and it never moves the ball forward from an organizational point of view. A retrospective would go a long way; we’ve never had one of those. I bring that up often, as the 1 meeting we should have, if we only have 1 meeting.
I tracked my time meticulously for several years, and when I used it to point out how horrible the current environment is, I was told I was doing too much and should be much my lazy about the tracking, to the point where it becomes meaningless.
I’m a team lead (not manager) and I get over 50% if my time is builder time and I haven’t measured but I’d guess my teammates are around 80%.
3-4 hours per day? That seems like a lot to me! Looking at my calendar, I’m lucky if I get that many hours per week. (It’s not all scrum shit, but let’s just say between sync-ups, status reports, daily standups for multiple projects I’m involved in, architecture reviews, breakouts, etc etc etc, I’m lucky if I get a full work-day’s worth of coding done in a week.)
Self-organizing teams is at the core of agile. So I hate to say it, but if you don't self-organize as a team, you're doing it wrong.
The fact that you have to go to your VP to present hours says it all, your team is not empowered.
I presented the number of hours (meetings multiplied by engineering participants) to our VP and he insisted I must be wrong. He insisted there was no possible way we could be spending that much time doing Scrum things and that I must be exaggerating or lying. He then fell back to a lecture about how Scrum is an industry standard and how it's more efficient than alternatives.
Really opened my eyes to the disconnect between Scrum mythology and Scrum in practice. The amount of time lost to doing Scrum things was so out of control that some people had fewer than 3-4 hours per day to actually work.
Of course, the Scrum proponents will rush in and tell me that we were doing it wrong or that it's not truly Scrum if it's helping more than hurting, but these people were highly trained in the ways of Scrum and Agile and pointed to various Scrum and Agile books and certifications to defend their ways.
OTOH, I have been on very small teams where Scrum was implemented with low overhead, but those teams were filled with efficient people who would have been productive without formal methodologies either way.